Learnings from My First Month in Software Consulting

Note: This post was originally published on the Quick Left blog on 3/19/15.

I’ve long had a special affinity for consulting. The thought of working with many clients and many technologies in semi-rapid succession is exciting and represents an ideal opportunity to learn a lot, quickly. Here are a few high level learning lessons from my first 30 days in consulting.

The best consultants are both generalists and specialists

In his well-read book, The Passionate Programmer, Chad Fowler encourages software engineers to explore a breadth of topics and the depth of a few. In our arena, this idea pays dividends. Some of the best value I’ve seen my colleagues deliver a client is in the selection of the right technology or architecture for the job. The implications of these types of decisions ripple throughout a project over its lifetime, and being able to draw on a large array of experiences with languages, paradigms and patterns is the best way to ensure our client gets a tech stack with the appropriate complexity and flexibility.

Being a generalist means you’re able to participate and contribute to most of these conversations. Being a specialist means you’re the one clearing up any specific uncertainty, highlighting edge cases, or warning of pitfalls to come. Your role in a conversation will vary by topic, but the relative frequency of these conversations makes the generalist/specialist all the more valuable in a consultancy.

We’re selling culture

The culture of a consultancy is critical, because it lives in the public eye. Because our business commonly takes place within the doors of other companies, our style, beliefs and habits are readily observable to those clients. For that reason, we spend time cultivating our culture. We enjoy Lunch and Learn sessions on becoming better consultants, are encouraged to bring our good habits with us (see: PR templates), and most crucially, we hire for culture. Developer interviews at Quick Left are as much about identifying interest and aptitude for consulting as they are an assessment of technical skill.

There is power in one

Because a client may interact with as few as one of us, we each have the meaningful responsibility of representing the above-mentioned culture. Cheesy, but: to a client, I may be all they know of Quick Left. Each of us shapes the view and reputation of the company, so accordingly, I’m empowered to make decisions to best represent myself and our team. Depending on the client, I may decide how often I’ll work from their location, dictate our development workflow, or if appropriate, provide an outsider’s critique of their processes.

But we are more than the sum of our parts

While a client may book a pair of developers, they in fact get the intermittent attention of a dozen or more developers and business-folk over the lifetime of the project. We enjoy a highly collaborative environment and regularly discuss and debate the implementation details of each other’s projects. Furthermore, If ever I get wildly stumped, I know that a nudge in the right direction, or even a lengthy pairing session with another developer (who’s probably on another project) is just a slack message away.