Slack

Executives train and judge managers by efficiency, specifically utilization. Nobody wants to pay for an engineer to sit around, right? We call employee downtime under-utilization and it’s a bad, bad thing.

Here’s the rub. Having slack in your system is good and not just for employees, but also for the customer and company.

In software engineering, slack lets you improve several of the four success measures of software delivery:

1. Respond to customers faster, decreasing Lead Time
2. Increase quality, decreasing Change Failure Rate
3. Build systems of reinvention to increase Deployment Frequency

DeMarco calls for the return of middle managers.

Sitting between strategy and execution, middle managers have tremendous influence on the direction of the company. Software engineering managers specifically have the opportunity to plan and schedule their team’s work, granting slack to the production s system.

In this slack lies the opportunity for reinvention – new features and solutions or even whole products, new ways of automating and systematizing, and new ideas for individual and team growth.

Individual contributors can’t do reinvention alone; they need the support and space provided by middle managers.

Knowledge work doesn’t respond particularly well to management schedule pressure. Knowledge work is about thinking and we can’t just think faster.

Conversely, when pressured to think faster we usually start cutting corners.

I’m a big fan of “maxing out” periodically – using periods of high intensity to elevate and reset our idea of what’s possible. But you can’t always have the pedal to the metal. You need both deload periods and slack.

Here’s a recipe for disappointment and failure – treat goals and schedules interchangeably.

Why do we confuse goals and schedules? Because we don’t want to disappoint our boss. Because we’re optimists. Because we probably weren’t trained to separate the two, so we don’t know any better.

Whenever I talk about goals, I first lead with a schedule clause. “Well, we’re scheduled for a February 15 launch, but internally we’re aiming for February 1.”

Explicitly separating goals from schedules works surprisingly well for both setting reasonable expectations while also conveying enthusiasm and drive.

I’m definitely guilty of making this mistake.

As a technical engineering manager it’s easy to place yourself into individual contributor roles for short periods. Brief stretches of individual contributor work probably won’t hurt and in fact probably help you understand your team’s systems and code.

The problem comes when managers view their individual contributor capabilities as the mechanism for providing slack. When you regularly provide slack through individual contributions, you’re assuming two jobs – manager and individual contributor. Better to whole-ass one job than half-ass two.