MOAR is not the answer.

We need to rethink outdated assumptions we’ve inherited:

MOAR is not efficient.

MOAR is not faster.

MOAR is not less complex.

MOAR is not effective.

    Larger teams
  • Move slower
  • Create more complexity
  • Are more susceptible to forced layoffs

The push for MOAR over the past decade led to huge numbers of layoffs the past two years. Why? Perhaps leaders felt pressure to impress VC firms by hiring huge numbers of developers. Maybe they fell prey to the myth of industrializing software engineering.

You can’t lay off someone you never hired. If you staff full-timers to meet the peak of your company’s demand, be prepared for when that demand dips. Because it always dips.

Instead, let’s talk about how avoiding incidental complexity and focusing on simplifying can unlock a different way to solve for speed. So you can do more with less.

When simplicity goes away, businesses are forced to invest in other areas like documentation, training, and customer support ... ask yourself how often you see teams prioritize removing neglected features as part of their planning? ... overly complicated software designs are the number one reason for failure within software focused businesses. Yet engineering leaders rarely focus on addressing complexity within their systems ... with only one option to pursue: throw more bodies at the problem.
Todd Kaufman
Echoing Wirth's plea for lean
Regardless of whether additional complexity is essential (valuable) or incidental (waste), all complexity adds to the carrying cost of software. As a result, doing low-priority work costs the business twice: paying people to build things it doesn’t need, sure, but also paying higher maintenance costs on the existing things it really did need. That’s because, as as is often forgotten: as complexity goes up, maintenance costs increase in super-linear proportion!
Justin Searls
Never staff to the peak
Embrace the inherent flexibility software provides to experiment rapidly. Software is much more malleable to rapid change and redeployment. On day one, we don’t need all the details to be set in stone; we can gradually solve the problems in piecemeal fashion. Our product teams can co-discover along the way as they build, experiment, succeed or fail, and understand what code needs to be written to solve problems in a way that delights users and customers and delivers value back to the business.
Michael Toland
The myth of industrializing software engineering

Help your team move faster
(and get help when you need it)

Line illustration showing concept accelerate with little a agile
Build small, efficient teams.
(Need burst capacity, too?)
Line illustration showing concept renovate tech debt
Avoid expensive rewrites.
(Legacy blockers holding your team back?)
Line illustration showing concept of DevOps security
Tackle scale with holistic DevOps.
(Wasting time on infrastructure?)
Line illustration showing concept ongoing product management
Build the right thing.
(Don't have product managers?)