The Consultant’s Craft: Becoming More than a Programmer

As developers, we all like to believe we’re more than just “code monkeys”—those interchangeable, expendable cogs in the software-making machine.

But to be more, we have to bring more. We must contribute more than code—even code that’s bug free, on time, and on budget. We must become consultants, helping our clients make smart decisions and getting the maximum value out of every hour we invest.

The Consultant Mindset

A consultant is someone who provides expert advice. So a software consultant gives advice not just about code, but about the software product as a whole. They help the client turn their budget into the most value, long-lasting, user-pleasing application possible.

To put it another way, good developers excel at solving problems that are defined by constraints. But good consultants can help their clients redefine those constraints, solving bigger problems and avoiding wasted effort. Having the skills of both a developer and a consultant is an extremely powerful and valuable combination. The combination allows you—and your clients—to get maximum leverage out of your considerable smarts.

I’m going to outline three scenarios that juxtapose a “consultant mindset” with a stereotypical “programmer mindset”. The “programmer mindset” responses are purposefully exaggerated.

Scenario 1: Answering a Difficult Question

Your business stakeholder, Jill, just sent you an email. She’s been in talks with a new potential customer for the product that you’ve been developing. She’s believes that if your current solution could interface with the hot new technology Y she could make another sale. She wants to understand the schedule impact of integrating technology Y. You don’t fully understand technology Y.

Programmer Response

After you read the email you realize that it’s going to take a bit of time to figure out how technology Y works. Moreover, integrating it into your codebase is going to most likely cause a spaghetti mess without a major refactoring. You start by archiving the mail and spending the next hour reading the API docs for technology Y. You then spend the rest of the afternoon identifying the integration points in your application. The next day, you continue your evaluation of technology Y and its suitability for your application. That afternoon, you remember that you promised that you’d have the reporting module complete by the end of the iteration. For the next few days you focus on the reporting module, but due to your delay investigating technology Y you are unable to finish. During the iteration meeting you express that you need more time to both finish the reporting module and continue investigating technology Y.

Possible negative outcomes:

• Jill is frustrated because she didn’t hear from you for a long time, and she still doesn’t have an answer.
• Jill gets the false impression that you are unreliable or potentially a slow developer because you didn’t deliver on your promise to complete the reporting module.
• Jill feels pressure from the potential new client during the week, and either A) over commits the team’s ability to deliver, or B) appears ignorant to the prospect and turns them off.
• Jill didn’t really need detailed information, or the opportunity wasn’t fully formed yet. You wasted your time and are now behind.

Consultant Response

After you read the email, you realize that it’s going to take a bit of time to figure out how technology Y works. You reflect on Jill’s message and realize that a timely response is warranted. You also realize that you technically understand the product offering at a much deeper level than Jill, and that she would appreciate your council. You immediately send Jill a follow-up email, saying that the answer she is looking for will take a few days of dedicated time to determine. You also offer an immediate call to discuss. During the call you ask the following questions.

• What is the need of the potential new client? – Perhaps they don’t need technology Y at all, or you can help Jill address their concerns in another way.
• Does Jill anticipate other new clients requiring technology Y? – This might impact your integration effort.
• At what cost point does this not make sense? – This helps identify the order of magnitude of the effort (e.g. 1 day of effort, 1 week of effort, 1 month of effort, 1 year of effort).
• What level of confidence and fidelity does Jill need about the schedule impact?
• Is there anything that you can do to help Jill win the sale?
• When does Jill need answers by?

Scenario 2: Dealing with a Looming Problem

You’ve been working on a new product for a few months. It’s a complex system that interfaces with custom hardware that’s being developed by another vendor. You have an upcoming trade show deadline, followed by a planned product release. Unfortunately, the custom hardware is behind schedule and buggy. You’re worried that the trade show will be a mess and that the product release will be a disaster.

Programmer Response

For the past month, you’ve had a pit in your stomach. However, you’ve been able to avoid facing the music because of the large backlog of software tasks that you’ve been able to implement in isolation from the hardware. When you spend time focusing on the details of the next feature, you’re able to temporarily forget about the looming doom that’s about to happen. The pressure is too much. You build up your courage and communicate to your non-technical manager Tim that you think the product launch will fail. You feel slightly better that you raised the issue.

Possible negative outcomes:

• Tim is disappointed in you that the news came so late.
• Tim respects you as a developer, but that’s it. He has to figure out how to solve the problem.
• Tim has no idea how to solve the problem.

Consultant Response

Based on your experience, you realize that the past is generally a good predictor of the future. The situation with the hardware vendor is not good. You decide to talk to your non-technical manager Tim about the issues.

Being a good consultant you always come to your manager with a solution, not just a problem. During the meeting, you systematically walk Tim through the issues and the product consequences associated with not addressing the problems. Next, you present a few options, complete with pros and cons, that you have developed to help mitigate the issues. Finally, you present your recommendation for getting the product back on track. Together, you work with Tim to determine the next best course of action.

The options that you provide may include harsh actions. Here are a few examples:

• Faking parts of the product during the trade show
• Delaying the product launch
• Canceling the product
• Switching hardware vendors

Scenario 3: Estimating the Unknown

During your last iteration meeting, your business stakeholder, Mary, asked about adding a sophisticated new feature to your application. Adding the feature makes clear business sense and is right for the product offering, but you have no idea how to implement it. You tell Mary that you need some time to think about the feature and you’ll get back to her tomorrow afternoon with an estimate.

After the iteration meeting, you immediately start breaking down the feature into smaller pieces. The small components give you a good idea of the breadth of the request. The issue is that most of the components are technically challenging to implement and come with a lot of risk.

Programmer Response

You decide that you want to be extremely cautious, so you aggressively buffer each of the components in your estimate. When you deliver the estimate, you let Mary know that this new feature is a lot of work. You feel comfortable that you can deliver within the constraints of your pessimistic estimate. You think to yourself that if it ends up taking less time in reality, that will be great.

Possible negative outcomes:

• The cost is too high, and Mary decides to cancel the new feature request. The product suffers.
• Mary is surprised by the high cost and spends hours of your time trying to work with you to manage the feature.
• You move forward with the feature and finish it in half the time. You feel great, but Mary no longer trusts your estimation.

Consultant Response

Being a seasoned developer, you understand that features like this can take a lot of time. You also understand that your pessimistic estimate devoid of context is going to cause Mary to panic and then to start actively manage the situation and you: How can we do it faster? What other information do you need?

You decide, instead, that you will manage the situation. You develop an implementation plan that allows you quickly mitigate the large technical risks in the first few weeks of implementation. During your meeting with Mary, you express that you’re excited to be working on such a technically challenging and valuable feature (this sets the tone). Next, you discuss your high-level pessimistic estimate with Mary. You describe the estimate as a terrible day scenario. You then describe your implementation plan, and how over the next few weeks you’ll learn a lot more and be able to reevaluate the estimate and refine the feature if needed. The plan clearly sets expectations, gets you moving in the right direction, and creates an opportunity to reevaluate in the near future when you have more information.

Don’t Limit Yourself

If you already have a consulting mindset, kudos to you. Chances are everyone wants you on their project and respects you as more than just as a programmer. If you don’t have a consultant mindset, you’re selling yourself short. The leverage and value that you can create is inherently limited to the next line of code that your write.

Don’t sell yourself short. Take on a consulting mindset.