Augmenting a Team vs. Being a Separate One

A few weeks ago I was on a conference call with a client talking about a new, expanded direction they were mapping out for their e-commerce. The scope of the project was well within my reach to execute quickly and thoroughly, but there were good & valid concerns expressed over me being the keeper of the system as a one-man show. After all, it would not work if a problem arose that only I was trained to address at a time when I was, say, gallivanting about in Panama: it would be irresponsible to structure a major part of their business to be vulnerable to failures that arise with poor timing.

As I’ve mentioned before on this blog, I’m a big fan of the benefits made possible by being a team of one. I also really like the agility and flexibility afforded by being a solo act in the business aspect of my trade. So when it was asked if I would hire and train up others to make possible a 24/7 manning and support of the project, I saw it fit to propose a re-framing of the situation.

This particular client is big. The company has their own dedicated IT department complete with plenty of smart folks who are able to build, run and maintain complex systems. They are also savvy about outsourcing: they know how to keep their own internal team smoothly handling internal operations by calling in outside talent to help with big initiatives when they come down the pike (which is why were having the conversation at all).

Rather than operate as a separate team on this project, I reasoned, why not have my contribution to the project be an augmentation of their existing resources? Given they already have an in-house team that works on other things which integrate tightly with their e-commerce, I could do the heavy lifting for the project (that is to say: design and build it to everyone’s delight, and see it through to a successful launch), and then take necessary steps to leave their internal team empowered to own and maintain it with minimal effort.

It’s like building a building. The work of the architect and the construction crew are distinct from that of the maintenance team and cleaners. The better job that the former does enables an easier ongoing job for the latter. In our case of software development I’ll refer to these two parties succinctly as builder and maintainer.

Characterizing a Successful Arrangement

So what are the characteristics that should probably be in place for such a collaborative hand off work to everyone’s delight? There are a few things I can think of (this list is no doubt exhaustive, if you can name one I missed please leave it in a comment):

The system handed over by the builder should as clean and intuitive as possible. Clean software architecture rules the day here, and any lingering patch-job hacks represent a great disservice of future burdens to the maintainer.

The builder should train the maintainer. Without a doubt, the curse of knowledge can easily give the builder a comforting illusion that it should be easy for the maintainer to spot and fix problems the arise. Rather, a maintainer should be left confident that they know how to navigate the structure of the code. When they have reached that level it should be their call to make, not for the builder to assume.

The builder should be accessible to the maintainer over time. Not 24/7 for hot fixes (that would defeat the purpose of handing off to a maintainer), but as an adviser for deeper, more long term issues including building further on the system.

The maintainer should be technically qualified for the role. They needn’t be as skilled with the code as the builder (after all, it’s easier to maintain a well built system than to build it well in the first place), but they should be able to track down and fix minor bugs in addition to more regular maintenance.

There should be general camaraderie and a shared commitment as a team between builder and maintainer. While hardest to quantify this is perhaps the most important: it’s a problem waiting to happen if a builder hands off the project with any air of “it’s your problem now”. When the builder is oriented as a long term partner, his or her priorities are well-aligned with the project as a whole: “I will do it right because I am ultimately accountable for its performance”. The desire to avoid saddling the maintainer with a problem is a powerful motivation to set them up well.

These characteristics represent a chunk of overhead of the Augmenting a Team route, relative to using a separate one. When handing off a project to a separate team, that team is free to manage long-term maintainability internally, however they deem appropriate.

What’s interesting about is that is how, in the scramble to get it launched, notions of longer term maintainability can (and do) fall by the wayside. When a builder steps in to augment a team on a project, the above characteristics form a nice recipe for clean execution of a project; one that is mindful of both the initial work and long term maintainability. It’s like having people over for dinner: you’re more likely to clean up your place out of courtesy to your guests. A builder who knows that a maintenance team will be looking at and learning their code soon will do more to be proud of such a close inspection.