Posted by: Matt Heusser
career, careers, contractors, economy, staffing, technology
At least, that is one of the major themes in Malcolm Gladwell’s book Outliers, and it makes sense to me.
It doesn’t really matter what you are working; it could be on MySQL clustering, writing mobile applications (or testing them!). It might be your golf swing or your knowledge of University of Michigan football.
Today, I’m going to talk a bit about how to know when you’ve ‘arrived’, and what to do with that knowledge.
The first problem with becoming an expert is that you have few people to turn with your problems!
Let me explain.
There’s an old H.L. Menken quote that goes something like this: “For every complex problem there is an answer that is clear, simple, and wrong.”
That means that, as an expert, when you come to people with problems, they will come up with simple solutions you have rejected. In some cases, they won’t even be able to recognize the problem as a problem.
And yes, as an expert, you will have problems. Another way to recognize expertise is by this — experts tend to have many small problems, where neophytes have one or two. (Once you break down the couple of big problems in front of you, the small problems are usually questions of tradeoffs, or worse, looking for that big breakthrough.)
It’s probably time for an example.
Pretend for a moment that you are line manager for software development in 1971. Computers are a new technology; personal computers are unheard of. Unless you work for IBM, it is unlikely that you started out as a programmer, or even saw a computer, until you transferred into the data processing department. The dominant thinking about software is the waterfall model, which makes sense to you.
Your company is forward-thinking, at least enough to send a programmer to a conference called IEEE Wescon. He comes back raving about this paper by a guy named Winston Royce. Leaping through the paper, you latch on to figure two:
Simple, straightforward, makes sense, right?
You keep reading and it starts to get more and more complex.
In the end, the author recommends this process:
Be honest. It’s 1970. You’ve never seen a computer before this assignment. What do you really think of this diagram?
You’re probably scared. It looks like a lot of extra work at best, and uncontrolled chaos at worst. It is likely that you go back to figure 2, mimeograph it, and say “we are doing this!”
I suspect that Winston Royce was an expert.
What We Can Learn From This
If you’ve ever tried to explain something to the boss, and seen the eyes glaze over, and the response “but couldn’t you use (thing you know won’t work)”, then you’ll know what I am talking about. The bad news is, even if you have a better idea, it is unlikely that the powers that be will understand what you are getting that, or even understand the problem.
Which explains, at least in part, why, so often, when we propose ideas that just make sense to change the process, the answer that comes back is ‘no.’
The classic answer here is to describe the outcome in terms of business results, and it’s a fine one. The problem is that large organizations will succeed at least short-term, even if you make no changes. Asking for an investment (time or money) will likely lead to a thought like this in the mind of the boss: “… and now I have to go ask the director for time and money. And if this guy succeeds, he’ll take the credit.”
So my advice is a little different: Do it anyway.
If you are an expert, your boss doesn’t understand the nuances of what you do. Oh, perhaps you have artifacts and things, documents, and templates, you may be audited on following a process — but for the majority of readers on this site, the company trusts you to do something; you own the process. Just do it, then talk about how you did it when you are successful.
There are alternatives; you can make it clear on the job, from the outset, that you are the expert, that your job is to define the process. You can think of IT outsourcing this way — the outsourcer says “just give me a check this size per month and I will run your servers.” The outsourcer gets to use his own process and the customer focuses on price and outcome. Not a bad deal, really.
I’ve got more to say here. I haven’t described exactly how to implement “just do it.” Nor have I covered the cost of expertise, and when it just might be okay to not pursue excellence — yet we are at the end of a reasonably long blog post.
More to come.