Won’t using lean startup techniques reduce my commitment to an idea? If I can just walk away from something because I have not invested much in it, how do I know that I won’t give up too early?

I had a bit of cognitive dissonance about the question. At first, I thought the line of thinking was silly. After all, the whole reason I was there was to ensure that I didn’t go “all-in” on an idea with no validation. I responded intelligently at the time, but the question kind of gnawed at me.

As I thought about it the next day, there seemed to be logic to what he was saying. In ancient times, didn’t conquestors burn the boats at the shore to improve their troops’ desire to win the battle ahead? With no easy way to retreat, the thought goes, they can focus all of their energy on the task at hand. And what about pushing through the dip or other aphorisms for getting going when the going gets tough? What if you quit right before the finish line because some metric said to do so?

I think my arguments for validating the idea are:

One of the advantages is that you are not all-in. You can be more impartial about your particular implementation of a solution when you know that you have ways to learn about what a better solution is. If you don’t have a way of repeatably learning, you’re stuck in no-entrepreneur’s-land.

Personally, getting feedback and having early adopters is very empowering and motivating. I think that value is a multiplier of idea quality and execution. I’d rather be pretty sure that the idea itself was pretty good and ensure that I’m excited to work on it, thereby increasing the execution component. If you think ideas are cheap, then there’s an opportunity cost of pursuing one over another, because the cost is in the execution and there are always more ideas.

If the validation turns out cold, find another idea and find a better one to be committed to. Then commit.

Not sure there’s much more for me to say here, so I’ll leave it at that for now. What do you think? Is it better to go all-in?

Original article: Do Lean Startups Reduce Personal Commitment?

RailsThemes is a project that I’m working on with Eliza Brock and Luke Flener. It is like WordPress themes, but for Ruby on Rails applications. Basically you purchase a theme on our website, and then you can install it on the command-line and have a site that is easy on the eyes in a matter of minutes. Traditionally, you would have to spend a lot of time and money to get a good looking theme.

What day of the week is it again?

Eliza lives in Nashville. I live in Indianapolis. Yet we were able to spend about two weeks together in the same location working on the project over the course of a couple of months due to some creative scheduling.

The benefits of working in close physical proximity are fairly well documented (see Peopleware). For me it is speed of getting feedback, better design sessions, and general morale boosts.

When the project first started, we talked on the phone and I said that I needed to find a weekend to come down there so we could work together. Eliza reminded me that I can work whenever I want to, so I could come down for a few days in the middle of the week and that would work. I said that made sense, and then five minutes later, said, “OK, well I’ll find a weekend that works and then I’ll come down,” and then immediately re-realized that I could come down on a weekday. Old habits die hard I guess.

So I picked a Monday through Wednesday trip and drove down and back while listening to audio books (a good use of the dead time.) Later iterations of the “work weekend” as we came to call them had me riding on the Megabus to free up time to work on things or read or relax. We would get a lot of work done during those periods, so it was worth the cost of traveling. I went down to TN, she came up here for a week or so, we met in the middle in a Kentucky state park and used a MiFi to get internet, and I went down there again right before RailsConf to finish up some things. So overall, a pretty productive way to get things done. We could also work on things outside of these blocks, but they were very effective in staying on task and ensuring that the time was used well. The opportunity cost of traveling made it really unappealing to waste time.

Scheduling things like this does take its toll. At some point in the last month, I tried to order the Wednesday lunch special and after a puzzled look by the waitress, was informed that it was Friday…

The installer

The installer is what I’ve most been working on for this project. I also worked heavily on the payment gateway and backend tools to help us create and manage themes. We came up with the idea of a command-line installer to allow devs to quickly get up and running with installing a new theme (full source and history here). The idea is that the installer does most of the heavy lifting of looking at your project and determining what files you want, and then asks the server for the right set of files and installs them correctly.

I researched how to make a gem, and used Bundler to generate the scaffolding. Then went through and developed it using (mostly) test-first development. Sometimes there were issues that were easier to track down by running the installer on my machine, and then I could make the appropriate changes to the tests afterward. I think this is a good example of “spike and stabilize”.

One cool thing that I ended up using was fakefs. This allows you to stub out file system calls and thereby test things without needing to actually touch the file system. This makes for more repeatable tests, reduces the need for cleanup, and possibly speeds up the specs as well. Before using it, I had functions that I was invoking that would operate on the filesystem, and then would mock those calls. However, fakefs works by setting up a fake filesystem (hence the name!) that you can run your tests on and then make assertions about the state of the filesystem. Overall a much cleaner solution.

Progress update: Early-access beta

We still have a few kinks to work out, but we have themes and people are starting to help us test them out. If you work with Rails projects and you haven’t signed up yet, check out RailsThemes and we’ll let you know when things are rolling.

We are planning on coming out with a new theme every month, and some extensions like themes for emails that you end up sending out through your app.

General thoughts

It’s too early to say whether RailsThemes will be a financial success or not. I think the next couple of months will shed some light on this. However, I’m glad that I worked on it so far. I had been wanting to work with Eliza on a side project of some sort for a few years. I think we made an ambitious but achievable schedule and really executed on it. My confidence to be able to do projects has gone up. I better understand how hard it can be to make something.

I think regardless that we are creating value, and that good Rails themes is something that I wanted to have in the world. If things don’t work out, I also think it will be a good data point for me to refine future business ideas.

Original article: What I’ve Learned From RailsThemes So Far

You can’t teach an old dog new tricks (well you can, but it’s hard)

Neuroplasticity is the brain’s way of reprogramming itself based on what it does. Your brain actually changes structure with new experiences. Brains also change based on what you think about. So giving energy to the kinds of thoughts you want to have, makes them form more easily the next time. This is one of the advantages of writing (it’s a form of caching thoughts).

Someone who starts playing piano for one year at age seven will likely be much better than someone who starts playing piano at age seventy for one year. Generally, The younger someone is, the less hard-wired and the more open to change their brain is. The seventy-year-old might have a better strategy for learning or more discipline, but learning is going to be harder. Neurons die every day, and they are the things gray matter is made of.

Useful versus true beliefs

There are several kinds of beliefs:

• those that are true and useful,
• those that are true and not useful
• those that are false and not useful
• those that are false but actually still useful

I think the first and last are particularly interesting. My standard contrast is the following:

A belief that is true and useful is someone telling you: “Look both ways before crossing the street or you might get hit by a car.” An example of a belief that is false but still useful is someone telling you: “Look both ways before crossing the street or a demon will steal your soul.” The latter is clearly not true, but may be useful in the sense that while the underlying premise is not valid, the effects of looking both ways might be enough to get someone to have enough awareness to avoid getting hit by a car. All things considered, I’d take the true and useful belief over the false and useful, but at least the latter is still useful. Really most ideas are somewhere on the spectrum, and a belief that is useful or true at one level of thinking or experience might be not useful or true at another.

Back to the topic at hand

The belief that “today is the best day to learn something” is useful even if it’s not true.

There are several components to why this is the case. First, and probably most importantly, it promotes acting the only time it matters: right now. It inspires action, and often after learning something, I realize that it wasn’t all that hard to begin with. It gets the ball rolling when I might have never done it at all. It’s a really optimistic view to hold.

Second, I save time. What took me four years to learn in college might have taken me five years when I as twice as old. If I want to start surfing, today is the very best day to get out on the board, because every minute I spend flailing in the water is perhaps 1.1 minutes in a couple of years. This is because the body and mind tend toward stasis, and getting them out of that takes energy.

Next, I think it leads to a more interesting life. If I see the current day as being the best day I will ever have to learn, it’s likely that I will want to explore more interesting opportunities. Why wait until later when it will be harder to do something? It’s a major opportunity cost to lose the best day ever. I think that people who want to do software should start as young as possible to get their brains wired up in a way that promotes future analytical thinking. I think most of the really good developers that I know started messing around on their own, many times in high school or before.

Another nice thing is that it makes me better going forward. If I put off learning something useful for a couple of years, that is a couple of years that I don’t get to leverage whatever it is that I put off learning. At some point, people give up learning new things because the time and energy needed to change seem too high relative to the benefit. Why learn to use a computer, I’ve gotten along just fine and I only have an uncertain number of years left. Holding the belief that today is the best day to learn something might overcome that pattern.

Last, I find that I worry less about what other people have accomplished or what skills they have when I remember this. I can still get better at whatever it is that I want to get better at, and today is the very best time to do this. No need to compare.

Caveats

Don’t get hung up on the fact that last week was a better day to learn than today. Why cry over spilled milk? It’s pretty clear that I will not be an NBA player, because I haven’t been playing basketball enough and from an early enough age. Even if I set out today with the intention to join the league, it would probably take too long to get good enough before my playing days were over. Just remember that today is going to be a better day than tomorrow, so don’t waste it.

The technicality police have been thinking things like: “well what if you’re sick or you have something ‘important’ to do?” Fine, you’re right (in a sense.) But in general, I think it’s useful in the long run. Obviously this whole idea isn’t a knock against older people. They should have a lot of useful experience by now.

Your thoughts

What do you think about this idea? True, useful, neither? Are there any equations you know for the amount of time it takes someone later in life to learn something new? Leave a comment below!

Original article: Why Today Is Scientifically The Best Day to Learn Something

Current projects and interests:

• RailsThemes.com (new project!)
• consulting/contracting
• Awesome Controller
• Desperately Seeking Validation
• office hours
• Hamming Lunches

RailsThemes.com

A new project!

I had been putting together various websites using purchasable themes from sites like ThemeForest, and it took at least a couple of hours each to translate the HTML and CSS to a format that Rails is happy with that looks like the theme is intended to look. I explained my solution idea to Eliza—basically a themes site for Rails apps—and she started running full speed with it. She called me up the next day and was like, “so I figured out the launch schedule for this.” I was like, “whoa, whoa, I don’t remember signing up for this officially.”

Anyway, I drove to Tennessee Tuesday and we worked until noon on Thursday on ramping up the project. We have a great designer, Luke Flener, for the initial templates and site design, I’m working on the development back-end side of things, and Eliza is heading up the marketing and user-facing development. There’s still quite a bit of work to do before our launch in April. Over the course of the last couple of days, we worked on

If you’re interested in project updates or to eventually purchase a design for your Rails project, check out RailsThemes.com. Also, if you are interested in contributing designs, we are interested in talking with you about it. Thanks!

Consulting/Contracting

I got pretty lucky meeting Jared Brown in person at the April 2011 Indy Startup Weekend, and he reached out to me to work on some very steady billable work. By having that, I have some stability as far as income goes, and I am in a position to pursue more speculative projects or ask for a higher rate for other projects. I’ve worked on a couple of other billable projects since last summer, working with Eliza Brock and some other badasses.

Soapbox: I think there is a fine line between consulting and contracting. I think that consulting is people paying you for your advice and/or experience, preferably by a function of the value provided, not a time-based rate. Contracting is saying, I get paid based on how much I work on the project. See Weiss’s Value-Based Fees for an excellent explanation of this. I was planning on making this point a whole post at some point, so I’ll leave the expansion out. I think consulting is slightly preferable, for reasons that I’ll state then.

Based on my current project lineup, I’d say I’ve been in the contracting side of things. Not many people are using lean and lean startup principles in Indianapolis and the value seems high, so this seems like a good area to be in going forward. Sure, a development firm can help you get your v1.0 out the door, but what then? Who are your customers, how have you been learning while you have been heads-down developing for six months? So I think this is an interesting area.

Awesome Controller

Awesome Controller is a product that takes your old game systems and enables you use your modern wireless controllers to operate them. Awesome Controller has been steadily progressing since winning Indy’s Startup Weekend in the middle of November. We have been working on it a couple of days per month, with a solid three day hack session around the holidays. We currently have the NES, SNES, and N64 basically working with wired PS3 controllers and Wii controllers. Next steps include better wireless hardware support, multiplayer, and business things like taking pre-orders.

We’re aiming to take pre-orders for Arduino shields (a shield is basically a chip that we create whose pins connect to an existing Arduino board, kind of like Legos). We also want to create some pre-assembled units. We recently filed for an LLC and EIN, mostly so we can get a bank account, and thereby take pre-orders. At this point, there has been a fair amount of interest. We applied to Kickstarter, and they said that it looks like the project is a legitimate project. Will need to figure out how this fits into the grand plan, might be a viable way to increase our visability. We’ve done little to no marketing at this point, just having Adwords as a way of getting people to find the site and sign up for our exclusive mailing list.

Overall I’ve learned a lot and have enjoyed working with (in no particular order) Wes Winham, Kyle Shipley, Alex Toumey, and Kail Keusch on this project.

Desperately Seeking Validation

This is the group that a few of us started to practice lean startup techniques. I would say that it has been very helpful in understanding the process of taking ideas and getting some initial validation. I think we’ve done a bit more introspection than true [in]validation the last couple of meetings, so hoping to get out of the building a little more going forward. It seems like we definitely have enough ideas at this point, just need to get them going through the pipeline. If you’re in Indianapolis and this seems interesting, you should check out what we’ve done and contact one of us to get on the mailing list for doing something with your weekends.

Office Hours

I announced how to sign up for my office hours a few months ago, and they have been pretty useful so far. I met people that I probably wouldn’t have otherwise, and reconnected with some former coworkers as well. Overall, I think this is a very high value use of my time. I took a break for the holidays, and things haven’t gone quite as well since then. I attribute this somewhat to my marketing/positioning of the “product”. I think that I need to more clearly define what people will get out of meeting, and what I want to get out of it as well. Thanks to everyone who attended so far!

Hamming lunches

About every other Friday, a few of us get together and talk about the answers to these questions

1. What are the most important problems in your field?
2. What are you working on?
3. If you’re not working on these problems, why not?

It’s inspired by the lunches that Richard Hamming talked about in his speech “You And Your Research”, so we call them Hamming Lunches. We’ve mostly focused on business, technology, science, and economic/political problems. I’ve found it pretty useful in ensuring that I don’t get stuck solving too small of problems. We’ve talked about neuroscience, transparency in business, the future of countries, space travel, transhumanism, and the like. I like that it’s not all theoretical though, as we ask, “how can we implement this?” or “why aren’t we currently working on this?” to most of the topics.

Wrapping up

Alright, well that was a long update post, but a lot has changed in the past eight months. Some of these updates could be posts of their own, and others gave me some ideas for things that I need to write up. Thanks for reading, looking forward to rocking out the next few months!

Original article: What Large Amounts of Caffeine Can Accomplish

(Having trouble seeing the slides? Try here.)

Original article: RR for Test Doubles Presentation

Many people seem to interpret MVP as the first iteration of their product. Once they build that version, they can add more features, and users of the product will be even happier than before. Businesspeople sometimes talk about needing to build an MVP so they can launch and raise more funding.

If you are building out a half of a product as your first stab, you might as well just call it version one or iteration zero or something like that. No sense in polluting the MVP term.

In this article, I will argue that most so-called “MVPs” are not really MVPs because they are not focused on the process of learning, and as a result, wasteful. I think that there is a lot of value in not trying to build too much. This low-hanging fruit likely accounts for the proliferation of the term. But I think that a lot of the value of an MVP is testing the risky assumptions every startup has.

Definition of minimum viable product

Well, what is a minimum viable product, anyway?

A Minimum Viable Product has just those features that allow the product to be deployed, and no more. The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. It is a strategy targeted at avoiding building products that customers do not want, that seeks to maximize the information learned about the customer per dollar spent. “The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” The definition’s use of the words maximum and minimum means it is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense.

A MVP is not a minimal product, it is a strategy and process directed toward making and selling a product to customers. It is an iterative process of idea generation, prototyping, presentation, data collection, analysis and learning. One seeks to minimize the total time spent on an iteration. The process is iterated until a desirable product-market fit is obtained, or until the product is deemed to be non-viable.

Wikipedia on MVPs, all emphasis mine

The reason landing pages are so popular as a form of MVP is not because they are the easiest thing to build. Often times they are very easy to build, but that is not the whole reason. The reason is that they often give a good bang for the buck (or time spent, ROI, etc.) for your current assumptions. With a landing page, you can test whether people understand the idea you have, collect metrics on the best ways to attract users, and whether anyone at all will sign up.

Yes, at certain points, your MVP might actually be a landing page with a value proposition and a way of learning from it. It might be going to a bus stop and convincing people to get in your car to test a new carpool web app idea. Sometimes it’s a super-limited version of your product, meant to test a set of assumptions. It could be a paper prototype that you show to earlyvangelists to talk about your value proposition. It might be you just pretending to be a magical algorithm that solves your supposed customer needs.

You should start with the riskiest assumptions that you can test and try to make them fail. Here is why you should start at the bottom of the risk validation pyramid.

What do you want to learn?

Here are my concerns when the term MVP is used loosely:

• there is little emphasis on what assumptions the MVP seeks to [in]validate,
• there are no clear success or failure criteria, and
• there might be an easier way to learn as a result.

Here’s how Eric Ries frames this anti-pattern:

Most entrepreneurs approach a question like ["how many customers will sign up for a free trial given what we believe is enough information?"] by building the product and then checking to see how customers react to it. I consider this to be exactly backward because it can lead to a lot of waste. First, if it turns out that we’re building something nobody wants, the whole exercise will be an avoidable expense of time an money. If customers won’t sign up for the free trial, they’ll never get to experience the amazing features that await them. Even if they do sign up, there are many other opportunities for waste. For example, how many features do we really need to include to appeal to early adopters? Every extra feature is a form of waste, and if we delay the test for these extra features, it comes with a tremendous potential cost in terms of learning and cycle time. The lesson of the MVP is that any additional work beyond what was required to start learning is waste, no matter how important it might have seemed at the time.

Eric Ries, The Lean Startup pages 96-97

Let’s pretend you have an idea for a software product. You think through all of the different features and what you think people would most like, and select what you consider to be the most valuable, easy to make, and coherent subset of those features to build in a month. Then you build those features. You launch the product, and no one seems to be interested. What do you do?

If you create something and don’t have a good way of learning from what you are doing, your options boil down to:

1. Retry: Change the product in some way and try again. Maybe it was that non-essential feature that you left out of the last release.
2. Travel: Pivoting (another often imprecisely used term) is moving in a slightly different direction with one foot grounded in learning. Traveling is heading in some direction with the product or feature without having validated your hypothesis.
3. Fail: Quit without having learned much. Try another idea.

(I originally thought of this in terms of abort, retry, fail, but as the failure of that error message centered around the confusing nature of the words, decided to make it a bit clearer instead.)

All of these are outcomes are undesirable due to the amount of waste involved (some sum of human energy, money, and time spent without much learning.) Again, this probably stems from not testing some risky hypotheses at a small scale.

Poorly defined expectations lead to fuzziness at the time you most need clarity. When done with an experiment, you should have a clear sense of “is this the outcome that I wanted to see or not?” If the answer is a clear no, you can think about what you might need to do to get a different outcome. If the answer is yes, or better than you expected, then you can continue with confidence. If you don’t say up-front what customer actions you expect from a certain action, you’re left with lukewarm results that anyone can interpret in any way.

The overhead of learning

MVP, despite the name, is not about creating minimal products. If your goal is simply to scratch a clear itch or build something for a quick flip, you really don’t need the MVP. In fact, MVP is quite annoying, because it imposes extra overhead. We have to manage to learn something from our first product iteration. In a lot of cases, this requires a lot of energy invested in talking to customers or metrics and analytics.

Eric Ries on MVPs

I like this quote because it introduces the idea that thinking about what we want to learn is critical when we build. The build-measure-learn (BML) loop is how things play out in time. However, we should first focus on what we want to learn, and then how we are going to measure it to dictate how we should build what we are going to build. The BML loop should be thought through in reverse to ensure that the experiment results in learning. The quicker we can get through that cycle, the faster our startup moves. Without learning, we aren’t really going through the cycle, and as such, are cutting out the feedback portion of the feedback loop.

The key questions

So here are my new questions for MVPs. If someone says they intend to “build an MVP” (the build part itself might be a tell), I am going to ask:

• What are you trying to learn with this particular MVP?
• What data are you collecting about your experiment?
• What determines the success or failure of the experiment?

Original article: Signs You Aren’t Really Building a Minimum Viable Product

(Having trouble seeing the slides? Try here.)

Original article: Making Recommendations with Apache Mahout Presentation

The talk

You have a reasonably well founded position, you almost certainly have enough to write about. You have arguments and counterarguments for the major things people are going to say. You have experiences that no one else has. So just write them out. Who can argue with what you have experienced? You’ve already done the hard work of thinking about this problem, why not get the benefits of writing it out? If anything, this will help clarify the thoughts that you have.

The specific phrases don’t matter, as long as you are getting out the main thoughts. You can always refine it over time—the great is the enemy of the good here. That’s what the edit functionality is for. I know you would love to include a beautiful graph or venn diagram to illustrate something, but just say it now and add it later if you must.

There is this nagging thought that says, “what if someone on the internet thinks I’m WRONG??“. That’s a vestigial fear coming out, like being worried about tigers or alpha male chimpanzees. The more rational concern, and the one you should focus on, is “does anyone even know that I exist?” The only way to solve this is to write.

You’re worried about being controversial? That is a good problem to have, it means someone cares enough to write a reply. And if you are wrong? Well, you learned a lot quicker than you would have if you kept it to yourself. Seems like a good deal.

Just ship it.

Just ship. Other people might want to read it. That publish button is scary? Just schedule it for two days from now or next week and keep on writing in the meantime. You’ll have forgotten all about it when it publishes and be surprised when someone asks you about the new post. “Which post?”

Writing might be the single best way of spreading knowledge that you have. It just makes everyone better off, including you. Instead of rehashing the same stories and thought patterns in your mind and with others, just write about it and refer them to the article.

Don’t have much time to write? Put down a nugget of inspiration for later. Just put the minimum intelligible sentence, and maybe instinct will take over. Just write it up real quick while you are thinking about it. You can surely find thirty minutes to just write what you’ve been thinking about or reading about. Could it be considered productive work if you are publishing something that will help your business grow?

Lastly, it might help someone else out a lot. It doesn’t take all that much time and you will feel better having done it. When you look back on this year, the posts that you have written are going to stand out in your mind as a high note. You will get better at writing and the next post will be even easier.

Wrap-up

Meta-reservation: I was worried about publishing this post. Then I scheduled it for a week and a half away.

Phew, that was quite a pep talk.

If you ever want something to write about, let me know and I’ll try to help out!

Original article: How to Write Without Reservations

• hearing about something
• reading a book about it
• knowing a similar technology
• writing a Hello World program
• doing a small project in an area
• having years of experience doing something

I think there could also be a weighting as to how much the person feels like they know a particular area. Maybe they “read” a book but didn’t feel like it really sunk in. Perhaps they don’t know a particular technology, but have two good friends who are well versed in that technology and can help in a pinch or introduce them to people in that space. In this way, an overall view of what a person has done and may be capable of can be more easily assessed. Take for instance someone has not done much C# but has done a lot of Java development. By understanding that these technologies are similar, someone outside of the development field can understand that this person has a higher capability for C# than in, say, embedded development.

The model might best be represented by a visualization. It could be shown as graph sized by relative experience. A large bubble means more experience, and smaller bubbles represent less experience. I could see using software to make this visualization dynamic to visualize progress over time and enable different views and drilldowns. There could be a weakening aspect for experiences that were a long time ago to show knowledge decay or obsolescence. Imagine that you could see what someone’s knowledge in a subject has been for the past five years. If I have knowledge years ago in a technology that is moving super-fast, it might not be all that useful. However, many years of experience in a slow-moving environment is a good thing to know about. I feel like some sweet images would be really helpful to illustrate this, but I’m going to punt for now.

Seems like there should be something out there like this, but I haven’t seen much. I have seen nice views of resumes (mostly by designers) but nothing for the average person. Perhaps this is a tangent, but I think it would be cool.

This portfolio model helps people see what they should strategically target to move to where they want to be. When someone notices a difference between the experience they have and what they would like to do, they can choose to bone up in the space that they want to be more active in and more actively try to pursue projects in that area. Seeing a disconnect promotes a mindset change. Also, it helps people view their own competence objectively, and leverage that knowledge going forward. Hence, this model and accompanying visualization has value whether it is show in private or public. It could just be a strategic planning tool, but could also be a new way to understand what people are good at and trying to do.

It could be useful for consulting/contracting organizations to get a feel for what their levels of expertise are and how to most actively manage them. If more competence in an area is desired, specific steps can be taken to increase that area.

Could you see using something like this for your resume or for evaluating working with others?

Original article: Formal Skill Modeling

It’s useful to note that all of the following stages are generally in play at any given time. If you focus only on the future, you might starve. If you focus only on the present, you might become short-sighted and hurt long term results. The idea is that one should have:

• a list of skills that have general value today,
• a list of skills that are becoming obsolete, and
• a list of skills that just might become very useful in the near future.

Essentially, it’s skill diversification, much like people diversify stock holdings.

The Cash Cow

This is something that you are very good at and is currently in hot demand. It differs from a core competency because this is something that you can make money doing for the near foreseeable future. This is web programming (and others) in the late 1990s. This is probably Ruby (and others) today. It might be something else tomorrow. Hopefully you will have learned enough about tomorrow’s cash cow in the second phase (small bets) to be good at it when it changes.

There are different kinds of cows. It could be that COBOL programming is the thing you are best at and can easily find a variety of work for. This would fit the criteria that I laid out. You might have some that are solid, and some that are getting to be less profitable.

If you follow this general process, you will eventually have multiple focused competencies that can be used in the future. This helps ensure losses in one area can be absorbed in another. For example, if for some reason the technology that you are working in suddenly comes into huge legal problems, you are alright because you have other skills that are useful.

It helps to have some competencies be similar so that you can leverage what you know, but it also helps to diversify. In either case, being able to quickly shift what you know and learn something new is going to be a benefit. If dinosaurs could adapt to changing climates, they would have been in much better shape.

Small bets for the future

The race is not always to the swift, nor the battle to the strong, but that’s the way to bet.
- Damon Runyon

It’s hard to predict the future. If you had a time machine, it would be pretty easy to beat the stock market (see Back to the Future: Part II.) What people commonly do today is to spread their investments out with the expectation that while any one of them might not do well, when all of the investments are taken into account they will be better off than if they held the investment money under their mattress. They also take on less risk than putting all of their money into one investment.

Likewise, the point of this phase is to place small bets on skills that you think will be big at least in the next few years. This satisfies the need to explore and contribute to new initiatives, while limiting the downside that new things may bring. For example, putting all of your investment in learning a proprietary technology and doing projects with it might be a good choice if it takes off. However, if it doesn’t take off, you might be out of a lot of time invested. Generally I’d rather invest than not invest because you end up learning something you can use later, but there is an opportunity cost to consider. Maybe you could have gotten a little better at something that would be more useful.

Later, when the future is clearer, you can double-down on the things that worked well. You gain information due to being an early adopter, and win out by having more experience in a given area. This could be working with Rails in 2006, or maybe some HTML5 + Coffeescript experimentation today.

Investors might be successful if they just diversify, but some do analysis as well to try to pick better stocks. With limited capital (time, attention, energy), it pays to think about what technologies might gain wide adoption in the future. Also, there is the added consideration of: “what skills do I want to have?” If mobile development does not appeal to you, it makes less sense to learn more about it than another hot technology.

A good example of some analysis in this regard is the Thoughtworks technology radar. They give an in-depth look at what technology choices to stick with, adopt, and move away from. You might agree or disagree with their choices, but if you are at least aware that a choice exists, you can potentially make an investment.

The earlier you invest in a technology the more likely that that investment will pay out over time. Instead of four good years, you might get six. Although on the flip side, you get more information as the technology gains adoption. However, as I previously wrote, being first in the mind is enough benefit to risk trying a few technologies publicly, even if they fail. Some of the time things don’t pan out, but the rest of the time it looks like you can predict the future.

Branching out

At the same time, it is possible to learn more about surrounding fields and seemingly completely tangential ones. This is the longest view possible and also has larger potential gains. It takes a long time to become an expert in one field, and it’s helpful to understand other fields to try to be at least oriented in a certain field. Again, this branching out takes into consideration that short term and medium term needs also need to be fulfilled for success.

If I am a specialist in software development, it helps to branch out to related fields, like project management and gaining experience with running a business. These are clear wins. If I am interested in using some newer software techniques, I might want to learn more about bioinformatics to make the most of the tools that already exist, or more about the hard sciences to see what the open problems are so I can contribute to them. Basically wherever it makes sense to steal concepts or work with a certain industry.

These are likely long-term studies. One does not become better at them without sustained effort. But half an hour a day for five years adds up (about 900 hours if you take some holidays off.) For some, this might be continued formal education, for others, self study. Regardless, it adds up to more interesting work and increased options.

The nice thing about studying something mostly new is that the return on investment is significantly higher than learning a little more about something you’re already an expert at. If a professional programmer spends twenty hours reading a programming book, will she even move the needle on their professional skills? However, if this same hypothetical and clearly stereotyped-as-introverted programmer reads about how to interact better with others, this has a potentially huge benefit.

Synthesis

I’ve been trying to work the career calculus link in all post, but failed thus far. Now I feel better. This one is all about learning every day.

I think the overall goal is to maximize long-term value creation and ensure cash flow stays at an adequate level. I think opportunities should be evaluated for their lifetime value and short term impact. Value could come in terms of financial compensation, contacts, experience, work environment, and more. If someone wants a Fortran programmer and I’d like to move away from that technology, the other aspects of the project had better be good enough to justify having more knowledge about Fortran and not being able to do something else.

I’ll have more to say on formal skill models on Thursday.

How do you think about opportunities and skill acquisition? What did I miss or overgeneralize? Thank you for reading and leave a comment with your thoughts!

Original article: How to Look Like You Can Accurately Predict the Future of Technology