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 programming consultants, helping our stakeholders make smart decisions that deliver maximum value.
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 stakeholder turn their investment into the most value, long-lasting, user-pleasing application possible.
To put it another way, good developers excel at solving problems 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 stakeholders — to get maximum leverage out of your considerable smarts.
I’m going to outline four scenarios that juxtapose a “consultant mindset” with a stereotypical “programer mindset”. The “programer mindset” responses are purposefully exaggerated.
Scenario 1: Answering a Difficult Question
Your business stakeholder, Andreá, just sent you an email. She’s been in talks with a new potential customer for the product that you’ve been developing. She 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.
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 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 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:
- Andreá is frustrated because she didn’t hear from you for a long time, and she still doesn’t have an answer.
- Andreá gets a false impression that you are unreliable or potentially a slow developer. That’s because you didn’t deliver on your promise to complete the reporting module.
- Potential new clients put pressure on Andreá during the week. Then, she either A) overcommits the team’s ability to deliver, or B) appears ignorant to the prospect and turns them off.
- Andreá didn’t really need detailed information, or the opportunity wasn’t fully formed yet. You wasted your time and are now behind.
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 Andreá’s message and realize it warrants a timely response. You also realize that you technically understand the product offering at a much deeper level than Andreá and that she would appreciate your counsel. You immediately send Andreá 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 Andreá address their concerns in another way.
- Does Andreá 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. one day of effort, one week of effort, one month of effort, one year of effort).
- What level of confidence and fidelity does Andreá need about the schedule impact?
- Is there anything that you can do to help Andreá win the sale?
- When does Andreá need to have answers from you?
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 another company is developing. You have an upcoming tradeshow 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.
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.
- Your non-technical manager 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.
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 programmer, 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, Mia, 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 Mia 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.
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 Mia 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 Mia decides to cancel the new feature request. The product suffers.
- The high cost surprises Mia, and she 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 Mia no longer trusts your estimation.
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 Mia to panic. She’s then going to start actively managing 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 to quickly mitigate the large technical risks in the first few weeks. During your meeting with Mia, 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 Mia. 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. After that, you’ll be able to reevaluate the estimate and refine the feature if needed. The plan clearly sets expectations and gets you moving in the right direction. It also creates an opportunity to reevaluate in the near future when you have more information.
Scenario 4: Helping Define a Feature
You’ve been working on a project with your stakeholder, Ben. Ben is the product visionary and product owner. Ben has wonderful high-level ideas, but he struggles with the details. Ben is also extremely busy with many other responsibilities. You have a deep understanding of the technology used to implement Ben’s vision and a good feel for the needs of the end clients. Recently, the project is starting to drag, though. That’s because you’re having a hard time getting the details from Ben needed to push a particular feature set forward. Ben has been able to explain the feature set at a high level but hasn’t done a good job answering your more detailed questions.
You need the details from Ben to push the project forward. After all, Ben is the product owner. Providing you with the needed details is his job. You create an expansive list of all of your detailed questions and email them to Ben.
Possible negative outcomes:
- Ben sees your email, feels overwhelmed, and doesn’t respond. More time goes by and you get more frustrated.
- Ben is confused about why you have so many detailed questions. He’s frustrated that he needs to manage your work so closely and schedules a call to discuss his frustrations with your boss.
- Ben scans your email and responds to some of the high-level points. He believes he’s provided you with enough information to continue your work. However, you don’t feel like you have adequate information to move forward.
- Ben hasn’t yet fully thought about the details and doesn’t know how to answer your questions. He responds in a scattered and defensive manner.
You know that Ben struggles with the details. Instead of peppering Ben with a list of questions, you decide the best path forward to create a document that both you and Ben can review together. The goal of the document is to help create alignment with Ben and answer your detailed questions. Starting with Ben’s strong vision and your understanding of the end client, you outline the functionality needed for the feature set. Creating this document enables you to take a point of view on the functional and technical requirements that will help unblock your development. After you’ve completed the document, you schedule a synchronous meeting with Ben to review it. During the meeting, you take notes on Ben’s feedback. After the meeting, you update your document with Ben’s feedback and then share the document back with him for approval.
In a nutshell, instead of simply sending Ben a block of questions, you both define and take the first pass at answering the questions. You then work with Ben to validate your answers.
- Puts you in the more proactive position of defining the details instead of asking about them.
- Helps focus and build alignment with Ben.
- Saves Ben both time and stress.
- Strengthens the product — you’re likely better at determining the details, while Ben excels when he can focus on the bigger picture vision.
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 a programmer. If you don’t have a programming consultant mindset, you’re selling yourself short. The leverage and value you can create are inherently limited to the next line of code that you write.
Enhancing your consulting mindset is a skill you can learn over the course of your career. Combined with your development expertise, it’s simply a mixture of curiosity, empathy for others, business acumen, and growing your confidence to act. Developing a consulting mindset will not only increase your value, but it’ll accelerate your career.
Here are a handful of additional posts that’ll aid your journey:
Refusing to Be the Victim – How to Adopt a “Player” Mindset at Work
Self-Managing People Are Smart about Asking for Help
Finding a Win-Win in Difficult Situations
Don’t Suffer in Silence – A Template for Scary Conversations
How to Formally Frame a Problem
Don’t sell yourself short. Take on a consulting mindset.