Recently, a recruiter contacted me on LinkedIn wanting to discuss a CTO role at a well known internet travel company. The recruiter mentioned they wanted someone who had managed/directed 100+ people. I’d only directed a considerably smaller team – about 20 talented people. So it was obvious to me that I probably wasn’t the person they were looking for. Even though this wasn’t a good match, we politely continued the conversation. The recruiter was very surprised when I revealed that my team of about 20 had developed and maintained sites delivering several hundred million dollars of transactions every year and we had 10x growth over just a few years. Reflecting on this, I think what surprises people is that we achieved so much with relatively few people in pretty short space of time.
How were we so productive?! Well we were a startup, or at least had been a “startup” just a few years earlier. The startup mentality was still in most of our DNA at that point. Pragmatism ruled. My aim was to deliver real tangible value ($$) quickly. I recognised that I did not know with very high certainty what features or UI designs actually worked, actually delivered value ($$). I also recognised that neither did the UI experts, the marketing experts or the developers. How? Well we’d conducted quite a few AB tests and a good few user testing sessions, what they taught me is that whilst we experts have a good feel for what might be a problem and what the solution might be, we also get it wrong too often. Getting it wrong too often means at best you get slow progress.
We needed a process (definitely lower case ‘p’) that enabled us to do as little as possible, as quickly as possible, to put our ideas and assumptions to the test – running experiments on our websites to gather real insight and facts about what adds value. This was the motivation for adopting a lean and metric driven process. I’m not sure the terms ‘lean’ and ‘metric driven’ where in use circa 2006, if they were I certainly hadn’t heard of them.
Whilst struggling to cope with a myriad of new work requests, bugs, changes in priority, and react to the results of AB tests, I stumbled upon the idea of modelling tasks like a sales pipeline. As I understand it, sales often kept a list of potential sales ordered by likelihood. These ‘pipelines’ are often sectioned off into states like: ‘closed’, ‘in progress’, ‘contacted’, ‘dead’. Each non-”dead” prospect is assigned to someone. The pipeline is continuously updated. At any time someone can look at this single document and understand the state of sales work and who is working on which lead or prospect. New prospects can be added very quickly and easily. Updating the pipeline to reflect a prospect progressing through these states is trivial. Some ‘prospects’ result in a sale, some die, some lead to other things. Prospects and their status and priority are fluid.
It occurred to me that this approach handled uncertainty and changing priorities really well. Exactly the same attributes our development process needed to handle. I adopted a similar process for organising and communicating my teams tasks and deliverables. My ‘pipeline’ had sections marked: ‘done’, ‘in progress’, ‘upcoming’, ‘todo’.
It was important that we could quickly change priorities. Changing priorities meant I did not want lots of ‘in progress’ tasks. I decided to create a rule of thumb – nobody should have more than 1 task “in progress”. Like many constraints this was more difficult to adhere to than you may at first think and the constraint had knock on effects. The most important consequence is that tasks/deliverables need to be very small and self contained.
Having only very small tasks/deliverables is actually hard to do. It requires a uber-pragmatic mindset. You cannot get caught up building all encompassing solutions that cover every possible use case or outcome perfectly from the beginning. The important words here are “every possible”.
Technical people are trained in system thinking. Good technical people think of every possibility, every possible combination of inputs, states and outputs. This is fabulous but it means it’s very easy to get carried away, solving problems with little consideration of the probability that a problem occurs and whether the cost of a solution is really justified. (I’m a teccy. Don’t hate. This is just something to be aware of..)
I’d already bought heavily into the idea of using metrics to identify what worked and what did not, to “smell” opportunities for improvements. I quickly learnt
that to organise and schedule small tasks/deliverables very often meant building the simplest thing first and for the most likely use case. Making our solutions more sophisticated would be an iterative process. We’d put the first piece of work live and look at our metrics for data points that suggested other use case worth investing in. Until we had data points that suggested other use cases where were worth investing in, I’d “schedule” them as low priority – in our ‘todo’ section.
This is a very subtle but important point. How often have you sat in a meeting discussing solutions to edge cases? It can go on and on and on. Edge cases by their very nature are often difficult (expensive) to solve well. How often have you or your team invested good time (and hence money) solving those edge cases? With the magic of hindsight, would you have bothered if you’d know how little those edge cases mattered, how little monetary difference they made. How little value they added for your users?
Some of you have read that and are thinking something along the lines of, “but I do care, I want ALL our users to have a great experience” and “Nonsense, what would Steve Jobs make of that” etc. I don’t necessarily disagree with those sentiments but we’re talking about priorities. Priorities are not yes or no, they’re just about when (and only sometimes if). We’re also talking about product development on the web, where there is massive opportunity to collect data, learn and often quantify what’s really important.
Lean is a mind-set, perhaps more than it is a process. Do the simplest possible thing to address those edge cases and learn how often they happen. If they happen very infrequently then they’re not that important. Alternatively, if the data says they happen a lot, then that is the point you make the decision to invest in finding and delivering solutions.