Hi Charity,

I'm a senior staff engineer, and I’m wondering what advice you might have for a person in my role in a large company to affect priorities and the speed at which work is "expected" to be executed.

It feels like the speed at which the teams are being pushed to deliver was not really sustainable three years ago and feels even more unsustainable this year. I'm obviously not in the rooms where these decisions are made, even though I am lucky to have a good relationship with my manager (role: Director of Engineering) and their manager (role: VP of Engineering).

I'm wondering how can I push my leaders to think in a way that doesn't require teams to be operating at 100% capacity all the time or convince them that building in slack doesn't mean "you get to slack off", it means "you get space to build resilient systems and handle the unexpected."

Signed,

Senior Leader Advocating Capacity, Keeping Engineers Resilient (S.L.A.C.K.E.R.)

Dear SLACKER,

OY. Way to put your finger right on the tightest, knottiest pressure point in software engineering. What’s next, an elbow? A jackhammer?

That is not a complaint, btw. I like your style — straight for the jugular. Why mess around? LFG.

Capacity is one of the hardest problems because it sits at the knotty, gnarled-up intersection of so many other hard problems: time estimates and roadmaps, motivation and burnout, competitive pressures and tool gaps, and the small matter of “what even is productivity, and can we measure it?”

But first: Hi everyone! This is my first advice column on Stack Overflow, and I am so excited to be here. We plan to make this a limited run, every other Friday for the next three months. Do you have a question for me? Send it!! (Instructions at the bottom.)

I like to talk through the problem over phone or Zoom, so I can pepper you with questions and you can tell me more about the situation. ”What have you tried?” “who all is involved?” That sort of thing.

So I called SLACKER up over the weekend, and we talked through their situation for close to an hour. Here’s where we ended up.

Yes, yes, we all want to move faster. It’s the software equivalent of going to the doctor and saying “I don’t feel well.” Yes, it would be nice if you could get your work done in an hour instead of a day. Yes, your engineering director wishes they could wave a wand and make the backlog go away.

Sometimes I wonder if the reason we gripe about speed so much is because it’s the one place we all agree. We might have very different notions of what “good” looks like, how many people to staff a project, or whether we should spend lots of time in design meetings or code review, but you can reliably get everyone to agree that slow is bad and faster would be better.

For that reason, I suggest axing words like “we need to slow down” or “this speed is unsustainable” from your vocabulary. It’s a losing stance. As soon as you say it, you become the person arguing for doing less instead of doing better. You do not want this! Not only is it self-defeating, it probably isn’t true.

What makes software engineers happy? Shipping things. Happier still? SHIPPING FASTER. Everyone in the room wants to go fast—you, your director, your VP, the business, the engineers. Where you differ is on what that means and how to get there.

After we hung up, I kept thinking about how few descriptive terms we used for your work. I remember “slow” and “fast”, and that’s about it. I think that's a problem.

"Fast" and "slow" are flatteners—everybody knows fast is good and slow is bad, but the words don't mean anything. They collapse a complex system problem into a one-dimensional moral judgment, and that ends conversations. You need a more textured vocabulary in order to have richer conversations about tradeoffs. You need words with specificity and bite.

“Saturation” and “clock rate” are two useful terms that I like. The clock rate of a team is how long it takes to ship a piece of code and how much friction there is. The saturation point is how many of your resources it will take to deliver results for your goals in the allotted time.

I also really like how Jack Danger methodically lays out the different types of technical debt in Technical Debt Financing: there is principal debt, interest rate (how much energy is lost just putting up with it), the increase in principal (how much bigger will the payoff be in the future), the increase in interest (how much more energy will we lose in the future), and payoff events (are there inflection points in the future that will force a sudden payment in full?). That’s a much richer discussion (and thought exercise!) than one about speed.

There are lots of other frameworks and vocabulary words you can use, as well as DORA metrics, SPACE, Swarmia, GetDX, etc etc. I'm for whatever gets the job done. You have to be able to have real, hard, nuanced conversations about the work you agree to deliver, the work you must put down in order to pick up new work, and the consequences of these decisions.

How swiftly you make progress is a function of many factors: how many hours you work, how easy it is, how much work it takes to do the work (aka cycle time or clock rate), how familiar the work is, how much you get distracted, your intrinsic motivation, how much emotional pressure you feel to get the job done, and too many others to name.

The emotional pressure part is what we typically think of when we say “urgency.” Leaders often reach for “urgency” in the same way they reach for “going faster.” It means they feel stressed, and this is the only lever they think they have.

Working longer hours and applying emotional stressors are short term fixes, but not long term ones. The long term solutions to “we aren’t moving fast enough” are structural ones, most of which involve investments into platform engineering and engineering enablement that can take years to pay off, and require a high degree of engineering discipline to land and make stick.

If you have the type of leaders who are constantly pushing harder and emphasizing how urgent everything is, it may be because they see themselves as pace-setters and cheerleaders, keeping up the drumbeat to keep things on track. Like they think people will just slack off and stop working or caring if they aren’t constantly ladling out anxiety.

But a system running at 100% capacity doesn't go fast. It slows way, way down, like New York City traffic at rush hour (i.e., 6 am to 10 pm).

The strategy of loading teams up with more work than they can do might seem like an efficient way to make sure they are operating at peak performance, but it really isn’t.

The system needs some flex in it because reality is unpredictable and things always come up. Cars might be able to drive at the speed limit even if the road is 80% full. But the fuller it gets, the more any little delay risks tipping the entire system into gridlock.

One of the worst things you can do for your own velocity is run teams at their melting point for too long.

In human terms, the melting point looks like this. People are working late into the night, they’re skipping the gym, they’re eating at their desk, they’re missing family dinner. They are too fried to go to church on Sunday. They’re snapping at their loved ones, their cognitive capacity and mental health are declining. They are drinking too much at night, because the anxiety makes it hard to fall asleep. They are getting neck and back pains they can’t shake off, and they start crying every Sunday night.

Any of us can go into the red now and then and not be badly harmed by it. You can sustain it longer if it’s intrinsically motivated. But not indefinitely.

Things always come up. If you want to go fast forever, the system needs to have some flex in it. People can’t step up in a real crisis if they have nothing left in the tank. So don’t treat everyday engineering like it’s a constant crisis.

You said that when the inflow of work slows down even slightly, your team does more interesting things and their velocity actually goes up.

That’s phenomenal. You already have evidence! Not just about what happens when they let the system get too saturated, you can also point to what happens when teams get their head above the water. If your managers want the org to go faster, this is the way.

Honestly, managers get numb to a certain category of complaints. There are some things you just learn to expect to hear constantly. “We need more resources”, “we don’t have enough time”—you hear this when times are good, you hear this when times are terrible, so it’s hard to feel like it means much of anything.

ICs, take your horrified faces off. It’s the exact same thing as how you start tuning out “this is an inflection point,” or “we feel a lot of urgency.” Anything you grow to expect, you start tuning out.

Your management chain is probably already pretty well inured to the usual complaints. But someone coming up to them with a solution that works? With evidence? That would get my attention very quickly.

Most engineers have to go into management—and climb the ladder a bit—before they learn just how hard it really is to right-size work and decide what to build.

This is one of those unbridgeable chasms of experience, much like (I’m told) becoming a parent. You’re all, “what I’m feeling is unconditional love like the world has never known,” and I’m like, “you are actually miserable and sleep-deprived and there’s poop on your shoulder, you just happen to be high on evolution’s ultimate brain drugs.”[Ed: Why not both?]

Yes, let’s make things better. God yes. And yes, this is a job for staff+ engineers just as much as it is a job for managers and directors.

Power naturally drifts towards managers over time, and engineers could stand to wrench it back and assert their own authority a bit more often. We need each other. Experienced engineers are better equipped to spot and solve some types of problems than even the most technically adept managers.

But there will always be something broken, flaky or slow. You will always be a little mad at technology. Maybe we should work harder on noticing the wins and celebrating the progress we do make. Maybe we should remind ourselves that these are pretty great problems to have, all things considered.

And then maybe go outside and touch grass.

Thanks, SLACKER.

— Charity

————————-

Got a question you’d like me to tackle? Feel free to email me at charity@honeycomb.io (or pitches@stackoverflow.com, if you’d like it anonymized). I am interested in answering questions about observability, AI, careers, leadership, team dynamics, and ethics.