Things slow down


This is lightly edited text from an email I sent to a collegue who was looking for help with running a dozen delivery teams. His CEO was asking how they could “go faster”, but as my friend pointed out at that time he really didn’t have any reasonable measure of how fast they were currently going. From 2013, none of these things change with time. I now know a lot more about the company in question incidentally, and the comment about self-disruption was more on the nose than I even imagined.

I think systems are destined to slow down:

  • The total percentage of change for a given unit of work goes down over time; at one point a month of new features was doubling the product. Now a month of work is what, 2%? Worse? Even if you figure man-months with team growth instead of calendar months it is a drastic shift.
  • The most important thing over time is stability, not innovation. Customers are usually not excited by new features unless the new feature makes something that was expensive cheap or impossible possible.
  • An established product also needs compatibility. And as I’ve found myself saying more than once recently “Compatibility means deliberately repeating other people’s mistakes.” You’re hemmed in by the inability to deliberately break stuff, and if you find something worth breaking the amount of work to do it successfully is easily an order of magnitude what it would be if the product were young and nobody cared.
  • Nobody can hold the system in their head any more. This dramatically changes the level of mental effort and the complexity of transformations of the solution.

I would reasonably bet that you guys have to try to put yourselves out of business before someone does it for you; i.e. start up a skunkworks project to either completely revolutionize the space or at least create new approaches. I can pretty much guarantee without knowing anything at all about your product and market that if you were to start over to serve it with a clean slate today you’d create something rather different and in less than half the code.

With any luck new stuff can be designed to be inter-operating clusters of systems. Apps as features. That’s the way the world is moving and it has considerable advantages for speed, team size, testability, etc. You may be able to start creating external (to you) apps that look integrated (to the client) as a way forward.

Every CEO wants to go faster. I’m facing it even now. They focus on features but as I’ve been at pains to point out to him there are actually 5 different things my team has to be responsible for, cut and pasted from my notes by probably applies to you with little translation:

  • Keep things running (load, bugs, system failures, integration point/dependency changes)
  • Respond to Client/Partner needs and Customer Service requests
  • Product improvements (features, portal, web, content network)
  • Clear path for improvement of efficiency/speed on the other tracks (i.e. refactor things that were deliberate ‘debt’ spikes in past so they don’t impede new work)
  • Internal Success (reporting, tools, knowledge collection, algorithms)
  • If you’re doing any kind of client-specific implementation or delivery work on top of your product that would be yet another track.

As a product matures and the code size/complexity increases, and the number of things running on (clients x use cases) it increase, the effort required just to keep it alive and not rotting goes up, the effort to marginally improve already existing capabilities goes up, the effort to communicate changes goes up, the effort to onboard new team members goes up…

All of these factors apply to anything that is code and touches the real world, from iPhone game to desktop app to SaaS to embedded systems.