On Consulting

2013/03/17

After four years being a consultant I jumped ship and joined a startup.

In this post I describe my time as a consultant, what I learned during the experience, and why I got out. If you’re considering joining a consultancy, this post is for you.

The consulting I refer to in this post is specifically software consulting, though I believe it applies to other facets of consulting as well.

In the beginning

Prior to consulting I worked at a company where I was the only developer. I wasn’t a developer when I joined, but over the course of about a year I taught myself to program in Ruby and that became my full-time job. I made some good software but never felt truly satisfied with the pace of my progress. I wanted to be better, faster. I wanted to learn from and work with other people.

That is where my consulting journey began.

ThoughtWorks

I joined ThoughtWorks in 2009 after having been to a few of the Chi.rb meetups they hosted.

Soon after I joined I was put on a project in Atlanta. The team I joined was exactly what I was looking for: 30 or so developers who were all much more experienced than I was, working on a very large Rails codebase.

It was my first time pairing, doing TDD, doing Rails, and being a consultant.

Though, to be honest, I wasn’t really a consultant then. I was a pretty green developer that was easily absorbed into a large team at a reduced rate. In the first 6 months on that project I was doing more learning than giving much back to the project. I had to learn the stack (Rails, JavaScript, MySQL), the tools (Subversion, TextMate), testing (RSpec, Selenium), and the method (agile, TDD, pairing) in addition to Object-oriented design and a very large domain model.

I wasn’t a consultant in the sense of being an expert in a domain or a technology, lending my expertise to the client to help them grow. I was a consultant purely in the sense that I was being flown in on a weekly basis to the client’s site to work on their application.

The client had their own developers, but they were all more senior than I was. They knew the stack, the tools, the domain better, having been there for years already.

My experience on that project set a precedent for me that gave me a false idea of what it meant to be a consultant.

I worked on a few other projects at ThoughtWorks, all with a similar theme. My knowledge grew and I became a better developer, but I didn’t become a better consultant. I didn’t even know what it meant to be a consultant then, let alone a good one.

Pivotal Labs

I joined Pivotal Labs in 2011.

After all the time I spent at ThoughtWorks becoming a better developer, I continued in the same fashion on joining Pivotal.

I worked on a few projects, some with only a couple client developers, some with none, one which was purely staff-augmentation (meaning the client wanted us purely to increase their capacity to deliver software, not necessarily to teach them how to write it), all which kept the idea in my head that being a consultant meant writing good software, and no more.

It wasn’t until later, while still at Pivotal, that it was impressed upon me what it meant to be a consultant.

In the end

One of the best developers I’ve worked with to date also happens to be one of the best consultants I’ve worked with to date.

It was from him that I learned that the duty of a consultant is not simply to join a project, write code, and eventually exit, as had been my experience for the three previous years being a consultant.

I thought my job as a consultant was to write the best code I could, to do the best job I could for the client. That’s how I thought I best delivered value.

I was wrong.

Consulting means working with clients and client developers who are less experienced or less capable of writing the software they need. As a consultant your job is to help them build what they need while making a concerted effort to teach them how to continue building it once you’re gone.

I had been merely a developer, not a consultant, for years. It’s probably the case that I imparted some knowledge onto the client developers I’ve worked with, but my primary motivation was writing good software at my pace, not being a good teacher. In that sense, I failed my clients.

Parting words

I hope you’ve gotten out of this an understanding of what I believe it means to be a proper consultant, such that you might make an informed decision to decide whether or not consulting is for you.

I decided it wasn’t for me; I wanted to build a product that I would own, where I would work only with people that were as capable as I was or moreso. By definition, not a consultant.

Of course, you can join a consultancy and be just a developer, but if you do so you’re missing the point, and doing a disservice to your clients.