Here’s a pep talk that I give to myself when thinking about not writing about something

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!

I think people should create a formal model of their knowledge portfolio and use this model to actively manage their knowledge and skill acquisition. This applies both to organizations and individuals. I could see this looking similar to the Thoughtworks technology radar. The skill model would have a list of skills and interests and how much knowledge one has in these. Experience could range from:

• 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?

It seems like the most devastating career risk people face is getting stuck doing one thing for too long without branching out. As a result, they become unemployed or underemployed, doing work that is not challenging, poorly paid, or nearing obsolescence. To this end, I have a framework that I currently use to think about the next few years of career development and being proactive about learning. I think about it mostly from the software contracting and business consulting perspectives, although it could be applied to other disciplines. I think the big differentiator is how quickly the field changes and how much one feels a need to hedge their career options.

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!

If you have worked on Agile teams, I was wondering if I could get your help on a small project I am starting.

I am working with Jason Yip to better understand how people think about solving problems. Specifically we are interested in the differences between “experts” and less expert people in a methodology.

For this first step, we are looking to collect challenging Agile scenarios. These should be the hairiest, most difficult, most challenging Agile situations you’ve found yourself in. The preference is for scenarios that you have directly experienced yourself rather than hearsay or hypothetical scenarios. It’s not important whether you were successful in meeting the challenge; it might even be better if the scenario is one where you failed. We’ll then pose these scenarios to different people and see how they think about solving the problem.

We are doing this to try to improve everyones’s understanding of how mindsets change with experience and potentially to help people gain mastery faster in the future. Also, it could help with debugging mental models, which would be useful in other contexts (lean/agile adoption, lean startups, etc.)

Here are the three specific things that I am asking. I am hoping that it will take ten minutes or less. Thank you!

(Having problems seeing the form? Click here.)

The method to the madness can be seen here.

How many times have you said: “Oh yeah, I forgot about that requirement…” or “I think we talked about that a couple of weeks ago, but nobody added it to the project tracker?”

Here are some indicators that there is work that you need to do that is not captured in your current project management system. They should work well with almost any agile project management system. It’s a good way of finding and capturing latent stories for people on the project to see.

Patterns to watch for

“We need to revisit this in October.” or “We should probably do this at some point.”

Create a story for this item. Regardless of when you revisit the item, it’s nice to visualize the work that you believe you should do at some point. This can be effectively prioritized against the other work. You capture that you have something to do and can plan around it. This is useful in capturing work expansion as it happens.

“This isn’t perfect, but it works for now.”

Add a task to refine whatever the item is. I’m a big fan of progressive enhancement for stories. Get the basic thing done, and then you can add polish later.

“Hmm, that’s a bug, but I don’t want to fix it right now since I’m trying to finish something else.”

You can quickly add this. Put a quick description of where you were, what you did, what you saw and what you expected to see instead. If you want, speculate on what might have caused the problem. Then you can move on knowing it will be taken care of soon.

“I have this crazy idea that I haven’t discussed with the team”

Don’t add this as a story, yet. You’re only cluttering up the backlog, making it less valuable. First discuss it with the team, and if it is something that you plan on getting to soon, you can add it.

A long discussion in the group chat room or an important email

If there are things that pertain to the story that you are working on or will be working on, copy and paste the direct text or a public link to the text that is relevant. If there are other documents or relevant images, link these as well. Especially with the chat room, you are already having these conversations and making decisions, so you might as well put these somewhere so that everyone will see the conversation when in the right context. No need to have the same conversation twice or need to hunt through a long series of emails to get to the relevant information.

Other thoughts

I think that this technique should be coupled with good backlog management to ensure that the highest priority items are being done and obsolete stories are being culled. If your backlog is too big, you will waste time and energy just managing it. Consider trimming it aggressively. Any truly important things will keep coming back.

I find that cultivating this practice ensures that the team communicates well and everyone knows about how much important work remains to be done. There’s much less “oh yeah, I forgot to include you on that conversation.” It makes the ephemeral more concrete, and leads to people trusting that what is in the system is very close to what actually needs to be done.

When do you add something to your list of things to do? When do you wait to add something?