I sometimes get asked: "How does the role of a software developer differ from that of a software consultant?"
And while I could go into describing the differences between the two, I often find it useful to tell a story about my own experience making the jump to consulting.
Much of my early career was focused on writing code for companies that sold products or services to their customers.
My weeks were spent writing code to complete features and fixing bugs. Occasionally I would have to complete a support request for a client who may be having issues with some aspect of the product.
It's an exhilarating feeling to be able to create features and solve problems with code. And once you do this for a while, you get very good at it. However, if you are anything like me, you tend to want to move on to bigger and more challenging problems. And if you work long enough and have a keen eye, you will start to realize that many of the bigger, more challenging problems don't always involve code but often involve communicating and working with people to solve ambiguous problems.
This is where the role of software developers and consultants differ the most.
Software developer vs. software consultant
The difference between being purely a software developer and being purely a consultant is this: as a developer you are primarily tasked with fixing bugs, building features tasked out by some stakeholder, or resolving technical support requests blocking customers from using the product.
As a consultant, however, you are given the ambiguous task of helping your client's organization and stakeholders be successful—and to help them navigate their most challenging business problems.
There are many types of consultants who help companies do different things: management consultants, IT consultants, HR consultants, etc., who work in various areas within the business.
Under the umbrella of IT consultants, you have some consultants that work with security, devops, or software development.
As a software consultant, you are 100% a developer and 100% a consultant. It’s not 50/50. Software consultants are not only fully committed to delivery, they are also committed to adding or creating value for the clients wherever they can. Sometimes this is writing code, but often it involves scheduling meetings, making suggestions, coaching peers and stakeholders, and oftentimes doing the work no one else wants to do.
As consultants we don’t just analyze and write code, we also observe processes and engage with people. Whereas pure software developers primarily leverage code, software consultants leverage code and processes and also engage in conversations to get things done. To put it simply, consultants aren’t just focused on whether or not things work, we are always looking to improve and even delight our clients.
Consultants are unshy about interacting with senior stakeholders or peers from the organization, because we understand solving problems necessitates some level of collaboration across the organization.
While there is no typical or average software consulting experience, since they can vary widely, I want to highlight some of the various events and occurrences that happen during a day of consulting at Test Double.
Here’s what a typical day could look like for me:
- I wake up at 6:30 and get ready, I might get some coffee/breakfast and plan for my day.
- By 8:00 I’m sitting down working on my current story and code for a couple of hours before the team standup meeting.
- After the team standup, I’ll continue to code and will typically reach out to pair with other teammates throughout the day as I have questions.
- Depending on the day I’ll also have an opportunity to pair with other consultants on different projects within the firm to share knowledge and hopefully have an opportunity to learn from each other.
- Some days I have the opportunity to engage in “growth time”—the time Test Double gives its people to learn and explore something new. Some of the ways I personally leverage my growth time include: reading books on software and consulting, working on internal initiatives, and working on programming side projects that help me sharpen my skills.
- Typically, later in my workday I’ll set some time aside for code review and look over team members’ pull requests. I’ll also work on wrapping up whatever code-related thing I'm working on to prepare for the next day.
Being a consultant doesn’t come without its challenges and difficulties at times, but I truly enjoy it. Though there are numerous reasons why people navigate into consulting, I want to share with you four reasons that have pulled me into and keep me embedded in the world of consulting.
Four reasons to become a software consultant
1. Interesting problems
One of the reasons I came to consulting was that I found I get bored fast. At one point in my career, I concluded that I would have to hop around to different companies every few years to find new and interesting problems. In consulting you have the opportunity to join different engagements with multiple companies of different sizes and domains without having to leave your firm. You’d be hard-pressed to get this much exposure to various industries in any other profession. The insight gained in each gig also gives you a wealth of knowledge you can call upon for future engagements. As someone who loves constantly learning new things, I’ve found a home in consulting.
2. Highly motivated & competent people
Another thing that makes consulting worthwhile for me is the people I get to work with on a daily basis. Consultants tend to be highly motivated, critical thinkers who focus on delivery. There is a saying that, “You are the average of the five people you spend the most time with.” Since you get to work with some really amazing people on a daily basis you can’t help but grow into your best self as well as contribute to the growth of others.
3. Growth opportunities
As a consultant, you often have opportunities to contribute in ways outside of your core contribution area. As an engineer you not only have an opportunity to write code, but you can also contribute to the company blog, go to conferences, and be mentored by more experienced consultants. All of these interactions generate opportunities for you to meet with others and grow as an individual. In consulting it’s important to make the most of the opportunities that are presented to you as they help prepare you for the next client engagement
4. Autonomy
Trust is a core aspect of consulting. As a consultant, you are hired by your company exactly because the company believes in you and your ability to serve and delight clients. The freedom you are given as a consultant gives you the ability to go above and beyond in your pursuits to add value for your client. Having this autonomy also gives you the flexibility of navigating your career, and your own pace and direction. Do you enjoy working with people? Tell your manager. Do you prefer being neck-deep in challenging technical problems? Mention that as well. You set your own path/goals and decide how you want to work. What does this look like in practice?
Well, many consulting firms have various career paths you can travel.
Do you like working with people? Become a manager. If you prefer to work on deep technical problems, you can become a software architect, or in many cases, you can do a bit of both. How you navigate your career tends to be up to the individual, but the nice part is you have various people along the way who can help you get to where you want to go.
Being a consultant is a truly rewarding experience. I genuinely enjoy getting up every morning with a sense of purpose and a set of challenges to solve each day.
Connect with us
If my experiences pique your interest, and you think you might be a good fit, then please feel free to apply to Test Double, we’re hiring.
Or if you’d like us to help solve your most challenging technical and business problems, we’d love to help.
