ICTworks

The central problem of software is that anything can be built.

With a physical structure, nature and physics puts some constraints on the space of ideas. With software, a project can be wholly completed and deployed and only then reveal itself as fundamentally flawed, and then we are all so inured to bad technology that no one will really notice.

Construct a monstrous building in the middle of nowhere and movies might be made about you; build a pointless app that no one uses and you will just need to cite a misleading metric in a donor report and no one will care.

Conversely, construct a good building in a sensible place and no one will think it worthy of notice; build a not-terrible app that people use for longer than the launch press release circulates, and you will immediately be nominated to half a dozen “X under X” lists.

So, by far the best method is to adopt a simple principle: Don’t build it.

Challenges to Saying No to App Development

But that is very hard when all around you people are pretending to build cool new apps and one article after another is talking breathlessly about supposed “technology for good”.

It is more or less inevitable that the forces of press attention, donor preferences, team preferences, and institutional inertia result in a decision to build some technology for bad reasons. You may be pressed to “do something digital”, to undertake “digital transformation”, or the like. Vanity metrics will proliferate. Someone will suggest press coverage.

Before you know it, you’ll be connecting unrepresentative organizations to unaccountable institutions via unusable chatbots, justifying it by a few thousand people who tried it out and never used it again.

As proof of these forces, we can observe that for half a decade one research report after another has pointed to the limited effect (if any) of well-intentioned but insufficiently rigorous technology projects (“let’s build an app”). And despite all of that research, the apps keep being built.

Hence this guide: Don’t Build It. A Guide for Practitioners

How to Just Say No More Apps

The guide starts with project selection, including why the best project to select is no project at all. It moves on to team structure, and the extreme importance of a full-time senior tech lead (or chief technology officer (CTO), understood as an excellent engineering manager). It then covers timelines, emphasizing shipping early but having enormous patience getting to maturity, above all in finding product-use-fit, and avoiding vanity metrics.

The guide then goes into some detail on hiring, covering the CTO role, senior contractors, designers and young engineers. The longest section, by some distance, is that on hiring. Hiring is the one thing considered critical in every piece of the lore, by founders and investors and managers alike, across all sectors.

The main message throughout is very clear: If you can avoid building it, don’t build it; if you have to build it, hire a CTO, ship early, and mature long; and no matter what, draw on a trusted crew, build lean and fast, and get close to and build with your users as soon as possible.

By Luke Jordan, Practitioner in Residence at Massachusetts Institute of Technology