This fellow had been using a new approach to software development, adopted by just a few companies so far. It's called Scrum. (Can you tell that an engineer named it?) Scrum is an iterative response to the deficiencies of the straight-line software development process known as waterfall.
In waterfall, a project sponsor describes what to build, and then builders build it. Because there is agreement on the end-product up front, waterfall projects are easy to fund, budget, staff, and manage. There's just one problem – they fail. That's because every software project is inherently unique and uncertain. Sponsors don't really know what they want, and builders don't really know how to build it! So no matter what you call the process, they wind up starting somewhere and learning as they go along.
Scrum (and other "agile" approaches) cleverly accommodate this learning, and deliver dramatic benefits as a result. In fact, they make learning key, by empowering the development team. That team (which includes a representative of the sponsor, by the way) is always learning these three things:
- What is needed
- How the needs can be satisfied
- How to work better as a team
So here's what I told that engineering manager. He asked me how he could keep his professional staff accountable, and I said, "they have to feel a little pain." Somewhat agitated, he quickly responded: "no, we don't want any pain."
A world without pain… wouldn't that be nice.
I found that exchange troubling, and reflected on it for several days. I discussed it with colleagues, one of whom asked me what I thought the engineering manager was trying to tell me. I said that he was probably feeling protective towards his staff. Maybe it was a blaming corporate culture, for example. I was trying to be empathetic, and then I realized I knew the real reason – the engineering manager was protecting himself!
Imagine: his empowered team is trying to learn how to deliver useful solutions, and therefore they're making mistakes. These mistakes are resulting in missed deliveries, omitted features, subpar quality. The learning is a sound long-term investment for the company, but the engineering manager has to take the heat in the meantime! In other words, his butt is on the line, and he would rather protect himself then help his team learn.
As you can see, team empowerment is a hot topic in software development today. But its challenges apply to any business management situation. We are, collectively, trying to outgrow outmoded management philosophies that are two hundred years old. It's hard and sometimes painful. Organizations that succeed do so by making mistakes and learning from them. And mistakes have consequences. If you, as a leader, are not willing to support and defend your team's learning curve, you're holding your company back.
Maybe I should have said discomfort?
