The Consulting Legitimacy Cycle: 4+ years to 2 weeks

Four years ago this month, I wrote “The Consulting Legitimacy Cycle,” a post about cycling between predominantly consulting/training and predominantly in-team software development. At the time I’d been consulting for about 15 months, and was pondering when I might next return to full-time development.legitimacy

It turns out that the answer was “a little more than a year.” I signed on to Outpace Systems as a remote developer in August 2013, and wound down my other engagements to be fully engaged with Outpace by the end of the year. Thus after about 2 and a half years on the consulting side of the cycle, I switched to the development side, where I would spend almost 2 and a half years.

Outpace would turn out to be the biggest challenge I’d had in a long time: a pile of new technologies with which I had little familiarity kept me under water for at least the first six months. I’ll be honest and blunt: I felt like an idiot for a half year.

During those first six months at Outpace, I would bounce virtually every day or every other day to something completely different. It kind of works when pairing… but it sure takes a long time to ramp up on something! We began to replace Ruby with Clojure a couple months in, which was great. But when you code in a new language for a day, and then don’t touch it for a week, it takes a long time to get proficient. At maybe a day a week, it took me six months before I began to feel reasonably comfortable in Clojure.

(Among the bigger learning curve elements: using a Mac daily for the first time, the sheer hell of learning Emacs for someone with a solid preference for vim, and for the longest time, a New Library of the Week. See “Surviving Chaos With Pairing” for the complete list of technologies.)

The upside: I picked up a pile of skills and an updated understanding of the daily feeling of being a real team member, as opposed to experiencing it from the outside as a consultant/coach/trainer. And the regular success we had in delivering software to happy customers lends a lot of credibility to what I learned about process and technique.

I’m convinced that my regular cycling back into “real” development is what helps me relate so well to teams I work with as a coach. They can tell if you really appreciate and understand what their daily life is like.

The downside: the business languishes. I managed to sneak in a few short engagements (mostly training) each year by using vacation. But I was too swamped to invest much energy otherwise: I wrote only a single blog post in two years, my web site started to crumble a bit (and continued to look increasingly outdated), I didn’t tweet much, and most other forms of outreach to customers, existing or potential, languished.

In February of this year, I chose to re-start Langr Software Solutions based on the financial assurance of a regular bi-weekly gig that should last until the end of the year. This time around, I decided that continuing to help deliver real software was going to be in important aspect of sustaining the viability of the business as well. As such, I chose to continue providing services to Outpace, and I’m also seeking to close a freelance development gig.

I’m hoping this continued involvement in “real” software deliver will prevent me from ever having to halt in order to take a full-time development gig again, and will help me keep the business continually vibrant and available. Maybe my Consulting Legitimacy Cycle will change from 2+ years for a half cycle (4+ years for the full cycle) to about a week.

The Consulting Legitimacy Cycle

Pausing to determine where you’ve come from and why you are where you are can be a valuable exercise in knowing where you want to go, as well as in understanding the value you can provide. An exploration of my past dozen consulting years taught me that taking an occasional break from consulting has improved my ability to better understand and help subsequent customers.consulting :-)

In 1998, after over 15 years of professional development, I thought I’d be Mr.-Retire-From-Big-Corporation-With-Nice-Pension. In 1998, I had just reached my five-year mark with MCI. When WorldCom came around seeking souls to connect to the hive mind, my research determined that they didn’t provide such a hot place to work. I was in the 1% of shareholders who voted against it. Sometimes being right isn’t gratifying (what a debacle).

I moved on to a local dot-com, the now-defunct ChannelPoint. In 1999, I learned about XP** and did what of it I could–mostly some TDD–while isolated as a professional services developer in my shared office. Cool stuff!

In 2000, with ChannelPoint’s collapse pending, I excitedly began my foray into the world of consulting. I worked proudly for Object Mentor for two years. I then joined an XP team and enjoyed pair-programming day-to-day as “just another developer” for seven months.

An important revelation hit me: Promoting XP as a consultant and practicing XP as a team member are two completely different things. I’d preached about a few things–pairing, most significantly–that I’d done only as an external party, not as a true team member. Until you experience what pairing is like, day-in day-out for an extended period of time, you can’t possibly understand what it really feels like. And pairing felt good, but I also learned to recognize some problems with it.

I knew I had gathered very relevant information, and started consulting on my own. Cool! Well, the wife didn’t think so; she preferred me home. In 2004, I took on a local position again as a developer, and ended up a developer/manager for the better part of a year. I learned a lot more about what makes teams excel–I had a kick-ass development team, and they weren’t even doing much in an XP sense.

The call of consulting took me again on the road to help other teams learn what I’d learned. I transitioned to being an internal consultant at a large shop pushing the mandate of Thou Shalt All Be Agile All At Once (it doesn’t work, believe me). I started feeling out of touch, and the unending barriers presented by a rigid corporate structure made things all the more frustrating.

I returned to development as a remote programmer for GeoLearning for most of 2010. More learning about what works and what doesn’t! After GeoLearning was bought out and all remote individuals terminated, and after a local 3-month “just a developer” contract, I figured it was time to spread words again.

(The sneaky part: Employee vacation time over the years provided an opportunity to take on short training and consulting engagements here and there, largely to give me a fix for my books and training addictions.)

I’ve been back in full consulting swing for about 15 months. I wonder when that will need to end again. Yes, I could remain a full-time consultant and still provide good value for my customers. But I’ve found I can be even better by finding a way to occasionally immerse in a development team, to remain current, open-minded, and relevant.

** Extreme Programming. That’s for you, J.B. It’s not dead yet.

Atom