Article summary
Are you questioning your abilities working at a consultancy? It takes time for us to build confidence as software consultants.
Let’s start with a quote and bear with me.
Consulting is not for the faint of heart.
This remark has stuck with me after a past conversation. While I understand the sentiment that consulting is hard work, you should know that not all consultancies operate the same way. At Atomic, for instance, we offer an accelerator program for green developers. During onboarding, they learn to become effective consultants while working on billable projects.
Customers often contact a consultancy to solve complex problems requiring bespoke solutions. At first, working on these problems seems novel and often uncomfortable. However, over time, they become less novel, and patterns for solutions become apparent.
Green developers will gain confidence in their communication and technical abilities with more experience and support from the more seasoned folks in their workplace. Invoke discussions with them.
There are ways to mitigate consulting challenges and provide value to customers regardless of your experience level.
Early in my career, I viewed all consultants as experts who could handle any complex problem based on their past experience. Since working at Atomic, my perspective has changed. I realized this wasn’t entirely true.
Traits of Effective Software Consultants
After five years in consulting and a decade in product development overall, I’ve realized that consultants don’t need to know everything. A combination of a solid grasp of computer science fundamentals, an appreciation for end-user experience, and strong communication skills is the entry point.
Here are some traits I’ve observed from effective software consultants. They tend to value:
Communication
Deliverables aside, communicating is the epitome of success in consulting engagements. Clear and concise communication keeps everyone on the same page, mitigating fear, uncertainty, and doubt. For instance, before sending a message, remove unnecessary words and sentences to keep your stream of thoughts terse.
Admitting Uncertainty
It’s ok not to know the answer to every problem. And it’s ok to say, “I don’t know.” Communicate this to your customer and project team, commit to researching solutions, summarize your findings, and schedule a meeting to discuss the plan of attack.
Time-Boxed Experiments
Time spent on time-boxed software experiments is not wasted. Prototyping code for solutions shows customers your pragmatic approach to problem-solving and builds your skills. Working prototype code can clarify the problem and demonstrate potential solutions.
Code as a Means to an End
Don’t get emotionally attached to your code. The first version of a solution is often discarded as you better understand the problem. Good abstractions and clean implementations most often come from iterative rewrites. Before merging into the main branch and once the abstractions are solid, write unit and integration tests to ensure the data contracts don’t break while running within the higher system as new code gets written.
Simplicity Over Complexity
At the onset to a solution, less code and no abstractions are better. Early abstractions usually add unnecessary difficulty and can become problematic when requirements change (and they will). Build a quick solution first, then refine it.
Abstractions should emerge from the rear-view mirror. Have the working solution first, then make the second rewrite as clean as possible and minimal code as possible. Delayed abstractions will be better.
For example, when tinkering with a solution, it’s preferred to have big functions in a single file as it shows the solution and system concerns more clearly. As opposed to abstracting too soon, makes the solution more difficult to reason about because the logic is scattered across many files and many small functions.
Separation of Concerns
Keep business logic as pure functions without side effects, and separate IO-bound functions (network requests, file system reads, etc). This separation makes unit testing easier and more effective as these are the interfaces you’ll mock in various tests.
Consulting is a journey
Although depth and breadth of experience are beneficial, it’s not the destination to start your journey as a consultant. As you grow in your career, you’ll notice commonality.
I found that working at a product company provided depth. In contrast, consulting offered breadth, building my confidence on projects in different industries while working with developers of various skills. This combination makes consulting less stressful, as many concepts carry over between problems and technology.
In my experience, the depth of knowledge gained from building many Ruby on Rails and AngularJS apps has been invaluable. The patterns and concepts learned are applicable across various languages and frameworks, making it easier to transition to new tech stacks and solve problems for diverse customers.
Be sure to work on tech projects you find interesting and do shallow and deep dives on the languages and frameworks you’re using. Afterward, try to understand why those abstractions were made and how you feel about them.
Synthesis
While consulting may seem daunting. Curiosity, self-driven experimentation, and tapping the collective brain trust in your organization will mitigate consulting challenges.
Consultants need consulting, too. Asking for help builds your communication skills, tech know-how, and problem-solving tactics, and enhances camaraderie within your team. When applied, this will make you more confident during your consulting journey.