An Elegant Puzzle: Systems of Engineering Management

by Will Larson

Running this process, and enduring the awkwardness in doing so, is the most rewarding thing I’ve done as a manager. I recommend it.

Lousy hooks and confusing segues aside, the topic for discussion is the relationship between a company’s culture and its freedoms.

Positive freedom is your freedom to do: to vote, to wear the clothing you want, to own arms, to blow smoke into your neighbor’s porch when they’re trying to read a book outside on a sunny day. Negative freedom is your freedom from things: from being forced to take an impossible literacy exam before being allowed to vote, from to wear clothing you dislike or find oppressive, from having your cellular traffic recorded, from having your neighbors blow smoke onto your porch when you’re trying to read a book outside on a sunny day.

Each positive freedom we enforce strips away a negative freedom, and each negative freedom we guarantee eliminates a corresponding positive freedom. This sad state of affairs is often referred to as the Paradox of Positive Liberty.

I believe that the balancing of positive and negative freedoms is a fundamental task of managers and management.

A few closing tangents. First, Tom DeMarco’s Slack13 has an excellent suggestion for a good starting state between positive and negative freedoms for engineering teams: generally follow the standard operating procedure (i.e., keep doing what you’re already doing, the way you’re doing it), but always change exactly one thing for each new project. Perhaps use a new database, a new web server, a different templating language, a static JavaScript front-end, whatever—but always change exactly one thing.

What to do? Well, work harder! Does it work? Of course not. Unless your problem is that people aren’t trying hard, the “work harder” mantra only breeds hero programmers whose heroic ways make it difficult for nonheroes to contribute meaningfully. Later, as your new heroes finish martyring themselves on burnout, you’re left with three exceptionally challenging problems: You’ve bred a cadre of dissatisfied and burned-out heroes. You and your heroes have alienated everyone else. Your project is still totally screwed. This is a recurring pattern that many growing companies fall into, and it also happens to projects within larger companies. Anywhere you find managerial desperation and a hardworking team, “Do It Harder” may be visiting.

When it comes to solving the problem of the hero programmer, your options are limited: either kill the environment that breeds hero programmers, or kill the hero programmer by burnout.

One of the observations from systems thinking16 is that, though humans are prone to interpreting events as causal, often problems are better described in terms of a series of stockpiles that grow and shrink based on incoming and outgoing flows. The Dust Bowl17 wasn’t caused by one farmer or one year of overfarming, but by years of systemic abuse. Stocks and flows are especially valuable in understanding the failure of projects and teams. Projects fall behind one sprint at a time. Technical debt strangles projects over months. Projects fail slowly—and fixing them takes time, too.

Your options for addressing a broken system depend on whether you’re in a position to set policy.

Projects fail all the time, people screw up all the time. Usually it’s by failing to acknowledge missteps that we exacerbate them. If we acknowledge errors quickly, and cut our losses on bad decisions before burning ourselves out, then we can learn from our mistakes and improve.

Luck plays such an extraordinary role in each individual’s career progression that sometimes the entire concept of career planning seems dubious. However, as managers, we have an outsize influence in reducing the role of luck in the careers of others. That potential to influence calls us to hold ourselves accountable for creating fair and effective processes for interviewing, promoting, and growing the folks we work with.

There’s a pervasive trope that people who’ve worked for an extended period in a large company will struggle to adapt to working in a smaller company. Work at a company too long, the theory goes, and you’re too specialized to hire elsewhere. This belief is reinforced by both age bias1 and the reality that few companies continue to win the rounds of reinvention necessary to maintain excellence over time. The pool of once-phenomenal companies is quite large: Yahoo!, Oracle, and VMware, to name a few.

If long tenure holds a stigma, what of short tenure? Yep, that’s stigmatized, too.2 Although, it’s certainly less stigmatized than it used to be. A fairly consistent belief across companies is that multiple stints below one year are a bad sign, but, generally as long as you’ve worked a few years somewhere, then having a career that is otherwise entirely composed of one-year stints raises few red flags.