You can’t help it. Your team is working on a development project that's make or break. It’s your, um, neck on the line. You’ve probably read all kinds of books about how to empower your team, taken seminars on ways to encourage growth in your workers, and gone through leadership training that stresses the importance of letting good workers do good work. But, now that the pressure is on, that all goes out the window.
It’s not your fault you feel the urge to start micromanaging. When the stakes are high, it’s only natural to want to seize control of as many loose variables as you can. And won’t the team’s performance benefit from a little extra pushing here and there anyway?
What nudges this perfectly natural impulse toward blossoming into full-blown, creativity-stifling over-management isn’t as much instinct, though, as it is training. All those books and seminars about leading knowledge workers in the information age stand against a backdrop of management principles harking all the way back to the dawn of the industrial age.
For all our talk about the shifting nature of work, there are still quite a few ideas lurking in our heads that were originally conceived almost a hundred years ago. When activated by the stress of a high-stakes project, these legacy habits can overwhelm your better judgement, wreaking havoc with your team’s performance. These habits include things like:
And these are all great management practices—if you’re running an early 20th Century factory. Back then, a manager’s job was to subdivide projects into simple repetitive tasks, assign them to unskilled workers, and stand there with a scowl on his face holding a stopwatch so the workers knew they needed to do everything better and faster. Productivity was defined as the number of widgets built per unit of time.
Unfortunately, as appealing as those ideas can sound when you’re neck-deep in a big project, they just don’t make any sense unless you’re manufacturing physical products at quantity. The product part of your productivity in software development is only partly physical—and that’s not the important part. The important part is the product’s potential to help users solve some problem or overcome some challenge. Quantity isn’t even a factor you need to consider.
So basically whenever the stakes are high you’re going to be tempted to exert greater control, and we have a ready supply of management principles to help us indulge—but unfortunately those principles are ill-suited to the kind of work you’re actually doing. In fact, in most cases, they’re downright counterproductive.
What does it look like when you give in to the temptation? Here are four far-too-common wages of this particular sin. I’d wager you recognize at least a couple of these throwback practices.
Widgets per unit of time may be out of the question, but there are still processes you can time. And however agile your methods are supposed to be, you still have clients waiting impatiently for you to deliver something. Isn’t the whole point of scrum to have some feature to deliver to production at the culmination of every sprint?
The problem is that forcing deliveries on some predetermined schedule often means your developers have no choice but to cut corners. Are there larger architectural challenges? No time to take those on now. Should we build some automated tests to ensure sound code and successful integration? Not if we want to make this delivery deadline.
The result is that while you may be making your deliveries on time, you’re also building up a massive amount of technical debt. You’re essentially prioritizing speed over quality. And you’re digging yourself into a hole it’ll take longer to get out of than if you’d simply focused on quality to begin with.
A related habit that’s equally well-suited to assembly lines but that goes against the core principles of agile software development is to start tackling features in a stepwise manner, checking them off the list. You’re on a tight deadline after all. You need to deliver all the specified functionality in the limited amount of time remaining.
Well, sure, but now what you’re doing can’t be considered agile. If you’re applying agile principles, you should be working to leverage project knowledge. On the assembly line, it may not have mattered whether any individual worker understood the importance of the narrowly defined tasks before him (or her). But, in software development, the person who knows the most about a module isn’t the manager or team leader; it’s the developer who’s been working on it for a while.
Even more important than familiarity with the code underlying a given feature, though, is an understanding of the business context in which it will be used. One of the biggest reasons for the move from waterfall to agile approaches was how often software that met functional requirements down to a T still failed to deliver any business value.
A scrum product backlog should neither look like a requirements list nor be treated like one. Product backlogs are comprised of user stories, not functional requirements, and the features you develop to support those user stories should be evaluated at some point by someone representing the actual users. That’s why scrum calls for a product owner, someone with intimate knowledge of the client’s business who can provide feedback about whether the software offers the value it was designed to offer.
Okay, so you can’t use widgets per unit of time as a measure of productivity anymore. Maybe you can use other metrics to track performance—because if you aren’t tracking performance, how can you ever hope to improve it. Since you’re using a Kanban board to organize work on your development project, why not use the number of items someone moves across the board per day as a proxy figure for productivity?
Here’s why not: you shouldn’t use tasks per day as a measure of performance—or as an indicator of where you need to crack the whip—because delivering faster isn’t your primary goal. In fact, insofar as it detracts from your actual goal, you should discard it as a goal at all. A developer could be moving items across the Kanban board on the hour, but that’s not cause for celebration as much as alarm. You’re going to need to check all that developer’s code for bugs—and most likely you’re going to need to rewrite nearly all of it.
It takes some discipline to focus solely on delivering quality features that contribute real business value to the client. You’ll always be tempted to focus on things like speed and productivity—and to some degree you have to. You are on a schedule after all. The key here is to avoid mistaking the map for the territory—and to not let speed overtake quality as your top priority.
You can’t escape it. Eventually, you’re going to have to deal with toxic workers. The temptation when you’re working on a high-stakes project, though, is to avoid dealing with those problem workers in a personal way. Instead, you want to keep your response impersonal—i.e. you’re not picking on any single developer but simply making an adjustment to the standard processes, an adjustment that affects everyone equally.
But do you really want the stricter processes to apply to your top-performing developers? This is another supposed solution that ultimately just causes a larger problem. If you’re trying to maintain order in a classroom full of unruly students—or a factory manned by people who can’t show up on time and follow instructions—then more restrictive rules may be what you need.
If you’re managing a software team, though, this approach is akin to making the top performers on a sports team follow the same training regimen as the worst performers. You’re holding back the best to control the damage done by the worst. As Patty McCord explains about the success of Netflix,
“If you’re careful to hire people who will put the company’s interests first, who understand and support the desire for a high-performance workplace, 97% of your employees will do the right thing. Most companies spend endless time and money writing and enforcing HR policies to deal with problems the other 3% might cause. Instead, we tried really hard to not hire those people, and we let them go if it turned out we’d made a hiring mistake.”
Elon Musk puts it even more bluntly:
“The problem is that at a lot of big companies, process becomes a substitute for thinking. You’re encouraged to behave like a little gear in a complex machine. Frankly, it allows you to keep people who aren’t that smart, who aren’t that creative.”
The fundamental point to keep in mind is that what your team is doing is nothing like what factory workers did throughout the last century. They’re not assembling a high volume of previously designed products. What they’re doing is creative problem-solving. And there’s no assembly line for producing creative insights. There’s no process that will reliably produce innovative solutions.
Want to learn more about agile software development? Check out these episodes of our podcast:The 3 Core Principles that Make up the Agile and DevOps Gold Standard