Your Ninja 10X Rockstar Developer is Force-Feeding Bacon to Your Lean Startup
Outsourcing and Limiting to Core Competencies are Essential — Especially in Software Development
This post is really for the non-technical CEOs and the CTOs who are delegating software architecture design decisions. I love all of you ninja 10X rockstar developers and I don’t expect (or need or want) you to change.
Primers on Lean Startups and Lean Companies focus on how to build and evaluate products quickly. While I find the overall principles of the Lean Startup methodology to be useful, I think they miss one observation that is critical to the success of any lean startup, and one that many lean startups forget: outsource everything that is not core to the business.
Just as Hillary Clinton believes that individual success requires positive input from individuals and organizations outside of the core family unit, so too does lean company success rely upon outsourcing. Instagram had only 14 employees when acquired by Facebook: how many of them were handling HR, accounting, server administration, network administration, legal paperwork, and other necessities for them to be successful?
The leanest companies will identify as few core competencies as possible, and outsource everything else. Instagram’s initial core competencies were (a) software development of image filters, (b) iPhone photo-sharing application development, and (c) driving adoption. 14 employees can handle that. When you throw in the other things I listed above, they’d need at least double the staff—so they outsourced, for example, to Amazon Web Services (server + network administration).
But it’s not just about outsourcing organizational functions—there are also lean ways of developing software and fat ways of developing software. A recent analysis of the failure of a “lean startup” drew the conclusion that they had to get “fat” to even get close to a true minimum viable product for the market. My suspicion, after reading the analysis, is that there were likely a number of software development choices made that led to the swelling of the development timeline. In my experience, most developers (a) want to build frameworks, (b) want to experiment with new and hot libraries/toolkits/languages, and (c) don’t want to spend lots of time searching for and testing established libraries/toolkits/languages. This means that when you hand the MVP specification to your hotshot ninja 10X rockstar developer, you’re probably headed for some inefficient and fat development.
I have been that developer, and I have managed those developers, and I now have a rule: 85% of all developer time must be spent on business-specific logic. This means that we’re not writing our own queuing system, business-process-management system, communications protocols, or HTML parsers unless it’s one of our few core competencies (and thus likely our product).
Oh, the online documentation for AngularJS is a bit thin and you don’t want to wait for the O’Reilly book to arrive so you’re going to re-implement it because you’re pretty sure it won’t save any time anyway? And you just read about this awesome new library written for Go, so you’re going to switch languages to one you don’t know very well and will make it harder for us to hire developers in the future? And it’ll take you at least 3 days to evaluate the various caching servers/libraries we might use and you already know Redis, and even though you’re pretty sure that Redis is on its way out, that’s 3 whole days! If you don’t have someone thinking about the long-term business impact about particular development choices that your development team is making, your development team is probably making some really fat decisions, even as you try to stay lean elsewhere.
One hallmark of lean software development is heavy reliance on a distinct set of libraries and tools that are developed by other people/organizations. I say distinct, because it does you little good to lots of different libraries and tools that do basically the same thing. It’s not lean to run MySQL and Postgresql. It’s not lean to run Cassandra and Mongo or Memcached and Redis. It’s not lean to be running Rails and Django with some Node.JS on the side. Spend the time to do the proper evaluation up front (even if—heaven forbid!—you don’t have a working application within 24 hours of your idea) so that you won’t have to switch around elements in your stack for as long as possible. (And even if you do have to switch, at least switching from all-MySQL to all-Postgresql is better than switching from some amalgamation of databases).
So if you’re not doing the software development, how can you tell if your development team is staying true to the 85% rule? One fairly simple way—if you’re following any kind of agile development methodology—is that you should be seeing business-specific features implemented on a regular basis. You should be very skeptical and concerned if you’re seeing “meta-features”—some kind of scaffolding or framework upon which your product can be built/inserted/customized. If you’re building Instagram, you better be seeing image filters and photo sharing, not file transport libraries and GUI frameworks. I watched a development team of 4 (not under me) spend more than 24 months to build a rules engine, when what was really needed was to (a) use an existing rules engine, or (b) modularize the rules into code, since that could have been done in less than a year, and would have had the same result.
If you really want to be lean, you need to apply the outsourcing requirement to your software development practices.
