Scaling a Dev Team of One

Buckets of Fun

Our new product direction has meant a complete overhaul of our development timeline and a shift from R&D mode to product mode. As our tech lead, I’m mostly alone when it comes to the nuts and bolts of development, so in some ways I am my own teammate. Because of this, and since I tend to be a bit OCD, I want to make sure I don’t get overzealous about one piece of the puzzle and miss the forest for the trees.

We need to make sure that the product as a whole is moving forward in our planned time frame, so I’ve started a new process I’m calling “dev buckets”. Sure, delays are part of life, but this process builds in a psychological (and practical) incentive to make big strides every week, along with a new way to estimate remaining work. It also leverages our diverse collection of technical challenges to help keep me at 100% excitement.

So basically I’m cultivating a massive split personality: I’m treating myself as a collection of teams that each work on one piece of the product. (I’m calling the work associated with each piece a dev bucket.) Every Monday work begins on a new dev bucket, so I am forced to make a major context switch on a weekly basis. I get a week of focus, and it’s OK if things run long, but that means I won’t get back to that bucket for a month or more. So each of my self-minions has a selfish motivation to hit some sort of exciting milestone before his week is up and he goes back into the matrix for hibernation.

The plan is to keep a backlog of the bucket assignments for upcoming weeks, so every week Charlotte and I decide together how many weeks of work are left in the bucket I’ve been working on, and we assign one or more buckets to the end of the backlog. Buckets/teams can also split or merge as necessary (as long as there are no personality clashes!). The backlog goes about a month out, so hopefully things like last-minute changes of next week’s planned bucket can be avoided. Ideally we just have a few minutes of overhead every Monday and move on with our lives.

Although I’ve seen a number of different dev processes under different (or the same) names, I’m of the firm belief that every team is unique, and in that regard my dev team of one is no different. Maybe in the future we’ll adopt something else, but for now this seems to fit.