How to go from coder to consultant
As a consultant, I'm reluctant to do this; every time the focus has shifted away from the client to me, things start to get odd. On top of that, advice-about-advice always reads a bit "meta" for my taste and can sometimes make the giver of such advice come off like a snake oil salesman.
When the people at Software Testing Conference Atlanta asked me to do a talk on “From box-checker to trusted advisor,” I finally relented, and decided to pull the curtain back a bit, talk about the difference between the two roles, how to change your perception in the workplace and, yes, a bit of my story.
If you were trying to run a company in 1900, you might try to break the work down into easily described pieces that require less skill. That makes the work predictable, the workers cheap and keeps the unions at bay. McDonalds, Walmart, and Ford Motor Company are famous for having great success with this idea of "separating the worker from the work," which originated from Frederick Winslow Taylor’s famous turn-of-the-century treatise The Principles of Scientific Management. The basic concept is to make an assembly line out of the work, using terms like stable, predictable and repeatable, and removing the need for skill, expertise or experience.
Except we know that IT doesn't work that way. It doesn't even appear to work that way on the surface. Most companies hire by pursuing resumes of the perfect candidate, with, for instance, exactly 3-5 years of Ruby on Rails experience using PostGres, with specific lists of JavaScript libraries on a particular flavor on Linux. It’s as if expertise can only exist for hard, technical skills. The more senior you are, the less likely you are to fit in just the right checkboxes, making changing jobs harder.
There are other kinds of expertise.
Clean code, design patterns and awareness of technical debt – these things apply to every programming language. There is also context. If you take a team of maintenance programmers and put them on a new product, they'll be more likely to fail. Conversely, a team that’s never had to maintain a codebase can make a maintenance project a mess. The awareness of the difference – of what good code looks like – requires a kind of expertise. It’s a kind of knowledge that defies a simple list. It doesn’t show up in simple programming exercises like FizzBuzz and certainly isn't in the HR manual. Yet this kind of expertise, of how to do the job well, makes all the difference in human performance. Alistair Cockburn’s article, “Characterizing people as non-linear, first-order components in software development,“ may have a fancy title, but what it says is correct: Passionate, learning/growing, competent people do exponentially better than mediocre yet qualified staff.
[Related: What to look for when hiring an IT consultant]
If you've noticed this, if you know who to push what way, if you've seen things unclear in the requirements, problems pushed through the cracks – then you’re probably ready for the next step.
For me, the next step happened about 10 years ago, when a manager at the insurance company I was working for wrote "Know Your Role – Be Your Role!" in block letters on a whiteboard with a red marker. I wasn't there when he wrote it, so I’m not sure what point he was trying to make. I did pick up the pen, and, in very small letters below, wrote "OR: Figure out what the project needs to have done. Do that."
What that team needed was a grown-up. Someone with these skills, to see what was falling through the cracks, and to fill in the gaps. I started to study consulting as an employee.
Gerald Weinberg's fantastic book “Secrets of Consulting: A Guide to Giving and Getting Advice Successfully” drops a hint in its subtitle. It’s getting your advice used that makes the difference, or at least often enough to make the fee worth it. The saying "you can lead a client to a solution but you can't make them implement" is true, but it’s very hard to remain in the field long-term if no one does what you suggest.
To have a consulting assignment, you probably need the company to want to improve something. When I was at the insurance company, it was repeatability: getting more projects in closer to the deadline with no surprises. At my next job it was reducing uncertainty through better testing, preferably in less time. This was internal consulting, so I had a day job – project management in the first, test lead in the second. Many evaluation systems have a "goals" section that is separate from the day-to-day work, so I took advantage of it, using those goals as mini-consulting projects. Suddenly I was meeting with my manager to discuss the scope, agreeing on the boundaries and expectations, and keeping management informed as I did the work.
One classic consulting assignment is the gap analysis, which is easy enough to do as an employee – just wait for something to change.
Say there’s a re-organization, and you get a new manager. That manager will want to demonstrate that he’s done something at the first annual review, if not sooner. So offer to conduct a gap analysis. Figure out his long-term vision, look at how the team operates now, find the gaps and recommend how to fix them. At this point in time, your manager has strong incentive to listen and, more importantly, nothing to lose. If you say things are bad, he'll say he made them better!
Or do this when you transfer departments. You can scope this so there isn’t a great loss of face. Say, for example, you’re transferring from the Unix Admin team to the Windows team. Everyone respects you as smart, and they recognize you have things to learn. Instead of trying to learn a lot, ask to conduct a task analysis of the job as it exists, and compare that to the existing documentation. You'll come up with gaps that are what employees need to do to learn the job. That doesn't mean the manager or the employees are doing a bad job – just that they haven’t documented how to do the work. Once you've completed that analysis, take that approach to other areas. Don't just follow the process: challenge it, point out areas to improve it.
You can do the same type of work when you start a new job. Point out the advantage of a fresh set of eyes, ask for the long-term vision for the team, then do an analysis on what to improve next.
Let's go back to that gap analysis.
It starts with figuring out the goal, the end state, which means asking where the company wants to be. From there, examine the current state to find the gaps. I'd typically create a report which lists the gaps along with recommendations to improve. When we create these at my consulting company, Excelon Development, we try to make sure there are a few things the client can do themselves, without our help. We also provide a menu of services we think might help the company accomplish the objective.
We also do this in a way that the company could take that menu across the street to our competitors, which is fine. We find clients don't do this often, and those that do probably won't make the best clients. Sometimes, as in a recent project with a mid-Michigan software firm, we genuinely believe that a Pillar or a Leandog (rival consulting companies) might perform a certain service better than we can. You have to know when you’re out of your element, and it makes the client trust you more.
As an internal consultant, you can do all the same things, and you're much more likely to win the job to fix the gaps.
[Related: CIOs must become technology consultants]
One tool to conduct a gap report is the SWOT analysis, which lists the Strengths, Weaknesses, Opportunities and Threats to any given project. Strengths and Weaknesses are internal; Opportunities and Threats are external. The assessment doesn't need to be done at the team level. We've done test assessments, for example, where the opportunities and threats were outside of the test but within the organization, along with listing outside-organization industry trends.
Other consulting roles include helping to work on the product roadmap, the portfolio process, a specific function (development, test, analysis) or even developing a plan for a new line of business or expansion. The two most dangerous traps I've found in these types of assignments were in either taking very specific direction (turning into an over-priced contractor), or worse, doing the work in a corner. A brilliant plan in a fancy three-ring binder that never gets read or used does not creating long-term value. It might make for great billables today, but isn't the kind of thing you can build a career on.
For me, the three years leading up to going independent were fantastic. First, I was working for Socialtext, a social, web-based company…so being involved in online communities was part of the job. Employees at Socialtext were treated as internal consultants; we were given a responsibility and expected to own it. As a venture-capital funded startup, every three months we had a quarterly earnings update, which could mean either layoffs or champagne toasts. The company did a good job of keeping us aware of what was going on, but still, the beginning of each quarter was nail-biting time.
Working for Socialtext allowed me to develop a tolerance for uncertainty and risk. That was fantastic preparation for being a consultant. My friend Adam Yuret, who consults mostly in Portfolio Management and Strategy, told me a similar story: that his three years on a boat in the Pacific allowed him to understand how to live for an extended time on very little income, which was good preparation for the consultant life.
One last lesson I learned as an employee: Focus on the client.
It's easy enough to get carried away, thinking of yourself as special, outside of the work itself, creating reports and analysis for other people. You start to talk at lunch about yourself and what you’re working on. It's flattering.
It is also a trap.
The job of the consultant is to improve the client's condition. It's not about you. If it becomes about you, strange things start to happen in conversations. You start to "miss." Worse, change doesn't happen. The client’s condition is not improved. People start to ask what it is you do all day – talk Really Is that the job, talking and writing reports
So find out what the client (your manager, your project team, your peers) would like to do, and help them be awesome. You know you've done the job well when you walk away and feel bad – they become awesome, but you didn't get the credit! That’s an amazing thing. It’s truly great. Give yourself a pat on the back, and recognize that you were actually a real consultant. Your advice was used. Keep doing that enough, build a reputation for it, and the work will come find you. Best of all, you can pick and choose between the work that is most interesting to you and the clients you enjoy the most, who are most apt to listen and take you seriously.
Sometimes you’ll be faced with telling the client things they don't want to hear. You will be tempted to temper your words, to provide other options, to take the work that is offered instead of the work that you think needs to be done. True consultants have the option of declining work, or reframing scope as "I'm really interested in solving the time from test-to-production problem, less than a specific way to implement it." Sometimes that means you don't get the assignment.
As an internal consultant, you might appear to have no choice. Yet there are ways to assertively say that something is not acceptable to you. You might risk your job or a relationship – but learning to not accept situations passively is the first step toward professional growth. Richard Bach wrote in his book Illusions that "If it's never our fault, we can't take responsibility for it. If we can't take responsibility for it, we'll always be its victim."
Step one is taking ownership of our work process. From there, giving advice is only a second step away. Once people think of you as an internal consultant, you are one. No title change is required.
I also want to point out a third way, beyond heads-down technical staff and line management. You might call it a player/coach, or "contractor plus." My friends in compensation analysis tend to call it a coordinator, administrator or "internal consultant." Either way, there is a role for someone to study the whole, provide insights, advise about tradeoffs and often, stick around to see the ideas made real. You can do it while keeping your title and day job, more than working in the process, it is working on the process.
If you'd like to add a bit of that to your day job, well, start with the next change and lead the way. Give it a shot. If you have more ambitious goals, and want to transform the world of work to make everyone function as a team member plus consultant, I admire that, too, and wish you the best. Being internal balances job risk, but it also creates a perception risk – it can be hard to influence change when people have existing preconceptions of you. If you want to go external – well, we'll talk about that in my next column.
For now four simple questions: What does your project need right now What are you going to do How did that go And, finally, what’s next