From Developer to Consultant
Editorial Note: Next week, I’m going to Panama to explore the canal. I have no idea how much internet access I will see, so next week could potentially be a quiet week for DaedTech posting, if I can’t log in to publish a few cross posts.
If you write software, but not for the company that signs your paychecks, this title may sound strange to you. “What do you mean, ‘from developer to consultant,’ when you can be both?” I have answered that question previously, so I won’t rehash it here. Suffice it to say writing code for someone other than your employer does not a consultant make. (But read that post, seriously, because it becomes even more important later in this one.)
A few readers have submitted variants of the same question, so I’ll capture it simply, and as a composite.
As an independent, how do I go from doing app dev work to consulting?
I added the bit about independent status because it matters. Without that, I could answer trivially by saying, “get hired by a consulting firm that wants you to consult, and let them train you.” But if you go from contract to contract slinging code or if you write code as a W2 employee, you have a less obvious transition.
The Nature of Both Beasts
Before I lay out a tactical set of steps, I need to define the underlying nature of both roles. In the taxonomy post, I approached the matter in terms of definitions, as one might expect from a taxonomy. Here, I want to talk philosophy.
I once gave seeking app dev work a satirical treatment. I asked the reader to imagine a world where, instead of “I’ll fix your garage door” contractors advertised their services with “I have 5 years of hammer, 2 years of table saw, proficiency with 6 kinds of metal, etc.” As an app dev contractor or W2 employee, you offer the world the latter. You say, “here’s a brain dump of stuff I’ve done, so all I need is someone who knows how to make me useful and who also signs checks, and we can get going.” You offer exactly the sum of your experience tuples.
A consultant, on the other hand, offers services akin to general contractors. “Call me if you have a problem with your garage door, and let me worry about finding someone who can do the job and how many ‘years of hammer’ they need.” An app dev free agent solves one problem (writes code for someone who can’t) even as he presents another (figure out what skills are needed and manage that person during execution). A consultant steers clear of execution and offers only guidance.
I love the productive feeling of writing code. I get the same sort of satisfaction from it that I do from redoing a room in my house. When finished, I’ve made a thing that I can point to with pride.
This entails a certain pattern of behavior. You formulate a plan, start executing, hit a state of flow, and see it through to completion. I daresay you develop a quasi-addiction to this over the years (and enter withdrawal going too long without it).
None of this describes consulting. You affect the world much more indirectly as a consultant. Imagine that you set up in some conference room and offer “office hours” where you give advice about writing software. Every now and then, people wander in and solicit your advice, and sometimes they even listen. The only way you now touch the world is indirectly, through their execution. Your “job well done” becomes looking at their job well done and hoping that the “well done” came from your advice.
I mention this because it constitutes a serious adjustment. Steel yourself against the execution itch if you want to continue. Execution paves your road back to app dev.
Now that I have sufficiently depressed you, I’ll offer what I see as the upside of consulting. With app dev, you have the tangible feel of building a thing. But, unless you build lots of tiny utilities, the big wins occur on timelines of months or years. You grind, push, and sweat and eventually you coax something impressive into existence.
Pure consulting offers much more rapid fire and much more high leverage opportunities. You get a phone call because a team or department has entered some sort of crisis state. They need triage, an outside voice of authority, a plan of attack, and then periodic check-ins from time to time. You come and go like a ninja (or so I daydream during delusions of grandeur). Okay, probably not quite like that. But you see tons of variety, gain tons of experience, and enter only at the most crucial moments. In honor of my beloved (World Series Champion!) Cubs, you come in during the 9th inning to close out games.
I would also be remiss not to state bluntly that pure consulting commands much higher bill rates. Done right, you could consult for a quarter to half of the hours, and dedicate the rest of your time to building and selling your own software, instead of doing it for someone else.
I realize I have spent a lot of words on background. But background makes the nature of the game extremely clear. To consult, you embrace uncertainty, shorter engagements, and understanding of business that gets you well outside the comfortable flow and feedback loop of app dev. To consult, you see code as a means of solving the real problem, rather than a career-defining goal in and of itself.
If you find that palatable, it will please you to know that you have a fairly simple playbook. Well, you have a simple to understand playbook, if uncomfortable to execute. Go back, re-visit the taxonomy post, and chart your course from software pro to specialist to consultant.
For some concrete ideas about this transition step, go out and look at prominent developers in the field. Need a boost with code quality? Call Uncle Bob Martin. Need your application secured? Call Troy Hunt. Having trouble with your Entity Framework setup? Call Julie Lerman.
You may find yourself wondering whether each of them represents my consultant archetype or my specialist archetype. To that I answer, “I honestly don’t know.” It depends on the degree to which they execute (specialist) versus advise (consult). I do not actually observe their interaction with their clients, so I couldn’t tell you. But what I can tell you is that any of them could wear either hat.
In the beginning, you won’t have the brand name recognition and thus you won’t have that luxury. Start by taking a narrower class of work that makes you a specialist. Build your reputation, and then you, like those three, can choose to consult as it suits you.
The Right Path?
I want to offer some clarity on my own opinion. I talk with some bemusement about the experience tuples and how we define ourselves with them. Regardless of what path any of us choose, I find that silly and limiting, at least as a way to advertise outside of a software team. Within the team, sure, talk shop. You need to in order to divvy up the work and communicate. But outside of the team, talk about solving problems.
But apart from that philosophical gripe, I truly view the taxonomy as containing three equally reasonable ways to ply one’s trade, depending on one’s preference. I have dabbled in all three and sincerely hope that, over the course of my life, I can continue to dabble in all three. But I definitely suggest picking some specialty niche(s) for yourself so that you maximize your options.
Why do you think you will be so angry, while posting from Panama?
I’m curious: What do you consider your specialty?
When I was first off on my own, I specialized in clean code/craftsmanship practices. That got me a lot of coaching oriented work. These days, though, I’ve evolved to specialize in codebase analysis and assessment as a management consulting offering. I’m currently building that into a niche practice, and one of the the things I’m actually working on right now is how to bundle that into a quick value pitch ala “I can help you install CRM” (or whatever).