Innovation and Treating Developers Like Adults

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

Well-well look. I already told you: I deal with the god damn customers so the engineers don’t have to. I have people skills; I am good at dealing with people. Can’t you understand that? What the hell is wrong with you people? – Tom Smykowski

I get a lot of grief when I talk about agile practices and how it ends some inefficiencies, i.e. less personal activity during work hours by developers. One commenter on my last article on the benefits of pair programming put it thusly:

It is amazing how insulting people can get when waxing on about the benefits of Pair programming. It is one thing to make the business case to an organization that Pair programming can be beneficial to an organization, but it becomes downright mean when developers get classified as being lazy because they are not paired up. As someone who has spent many a night working (alone) for as long as it takes to complete a project on time without anyone noticing, I seriously disagree with the notion that by not pair programming, developers are lazy.

He’s right, but not for the reason he states. Pair programming is still better than solo programming in almost all cases. Treating developers like children, however, is a sin that is pervasive in many businesses. In my advocacy for pair programming, I was subconsciously pitching my message to product and development managers in large organizations.

Why large organizations? Certainly, developers are treated poorly in both large organizations and small, but nowhere have I seen developers so systematically infantilized as in the large, corporate software development organization. Tally up all the times you’ve heard things like “We don’t want developers making business decisions,” or “we don’t want developers talking to users” and you get a sense of the scope of this problem. I have some ideas on why this infantilization takes place, but, more importantly, I believe that any organization with this sort of culture will not be able to innovate new software products and services.

Why Developers are Treated Like Children

To understand why developers are often treated like children, consider a similar scenario. Say you’re a politician and you’re arguing with a social scientist about public policy. This scientist is an expert. He’s studied this domain backwards and forwards. He has all the statistics and arguments and studies at his fingertips. You are not an expert. You’re likely going to lose most arguments with this guy on the merits. So you decide to cut him down to size. His ideas are from the “ivory tower” and impractical. Sure, he sounds impressive, but he’s got feet of clay. Sensing an advantage, you go a little further and point out that some of his colleagues are a little weird, wear sandals everywhere or talk to themselves. Suddenly this leading expert has become an idiot savant, an intellectual buffet where you can take or leave his arguments and opinions like shrimp or brussels sprouts.

Much the same happens in software development environments. Software developers — highly skilled experts in crafting software — are declared business incompetents. They may understand bits and bytes, but they don’t understand business. The results are predictable: the developers check out of the project and become clock watchers.

One Solution: Self-Organizing Teams

At Orthogonal, we’ve been called on to introduce Agile practices into projects and organizations. One of the more subtle changes we introduce is that of the self-organizing team. This is where developers (and BA’s, IA’s, etc.) share responsibility for organizing their own work, rather than depend on managers telling them what to do. At the same time they also become accountable for this work and the ultimate success of the project. The former “managers” become obstacle removers, freeing up the team members to do their best work.

This constitutes a seismic shift in thought for most corporate IT environments. In one case I had to repeat the concept of the self-organizing team three times until it sunk in. “You mean we will be making the decision on what to work on instead of a VP?”

This is the hardest of all agile lessons to learn. Once it takes however, some amazing things happen. Developers begin to work a lot harder. It’s amazing how giving someone a big say in what they do every day will impact their motivation. They also start to take and avid interest in the underlying business problems their software is to solve.

Since one of the biggest sources of bugs and consequent cost is the misunderstanding between stakeholders and developers, it pays to reduce that misunderstanding. That’s the purpose of sprint planning meetings and user stories. If you infantilize developers and deliver business specs to them in the equivalent of business baby-talk, is it really surprising that the result is a comedy of errors?

Innovation

Beyond productivity, there is another cost to locking a significant part of your workforce out of thinking about the business process. Some of your most creative, most analytical thinkers, the software developers in your organization, are being discounted. If less than 5% of your workforce is being asked to innovate, to come up with that great new product or service idea, or just a better way of doing something old, then odds are they won’t think of it. Harness those talented developers, however, and you’ll discover human capital you never knew you had.

If, by now, you’re still shuddering at the thought of that developer — a shy, introvert who sits in a cube farm over by the break room — taking an active role in understanding your business, then you’re going to be paying lots of management consultants a ton of money to try to splice innovation into the “DNA” of your company, all to no effect.