What's the right focus for managing a bunch of software engineers? Should you focus first on assuring that you have a congenial team with good working relationships, or should you focus first on assuring the substance of what they're creating is the best it can be? This is a similar question to the choice of process and substance that I covered in a previous post and it's just as important.
Substance vs. Process and People
Just as schools of education purport to teach people how to educate without reference to the subject that is being educated (math, history, etc.), management schools (you know, the kind that give MBA's) purport to teach people how to manage without reference to the kind of work that is being done or the kind of people who are being managed. The idea that "good management" and "management skills" are entirely distinct from the actual work being done pervades our work environment. The more esoteric the work skills, and thus the more difficult it is for a manager to have a clue about what his people are doing, the more this seems to be the case. Software development is right up there with particle physics in its ability to induce glassy eyes among the non-initiated.
Substance vs. People
It's really tough if you're a manager and you're trying to manage something when you have no clue what the people doing the work are doing. This is what leads to the strong tendency for anyone who claims to be a good manager to focus on process instead of substance, and to focus on people and human relationships rather than substance. Truth be told, if you don't have a clue about what people are doing or talking about, you don't have a lot of choice. A normal human being observing an exchange between two engineers can easily discern that engineer A is being nasty and disrespectful to engineer B, but how can that normal human being see that engineer B is proposing a completely stupid approach that will take a lot of time and then fail, while engineer A is being quite restrained (relatively speaking) in his reaction to the uneducated drivel drooling out of engineer B's mouth? The manager is likely to react to the only thing he actually sees, i.e., the disrespect being given by engineer A to engineer B, and therefore chastise engineer A, when actually it's engineer B who should be sent back to the farm teams, if not worse.
I am not claiming that there is a binary choice between people and substance, that if you focus on one you can't pay attention to the other. Of course, both are important. But as I look at software shops, I frequently see managers treating one of these as the primary goal, while figuring that the other will mostly take care of itself if they get the primary one right. The less they know about the substance, the more likely this is to be the case, but even experienced engineers who are trying to make the transition to management get a clear message on this subject from their superiors: good management is independent of substance, and a "good manager" makes sure above all that the human relationships in his group are in good shape, and that if they are, good software will naturally be the result.
Management focus and company success
In the best of all possible worlds, a manager would create harmony and excellent relationships among the programmers, while at the same time achieving maximum productivity towards making the company successful. That's a nice fantasy. But that's all it is. While being nasty doesn't imply great programming any more than being misunderstood implies that you're a genius, the fact is that there's a strong correlation between a focus on substance and company success.
The reason putting major emphasis on substance (i.e., "who's right" is more important than "who's more respectful of other opinions") is a winner is simple. The groups who all agree that writing the best possible software to meet the company's needs are more likely to ... write the best possible software to meet the company's needs! Compare this to groups who all agree that having personal harmony among its members is more important than achieving the best possible software -- doesn't it make sense that you'll make all sorts of compromises in software to optimize everyone's feelings? Oooo, better give everyone a medal, we don't want to risk diminishing anyone's self-esteem, do we?
Organizational Size
I've noticed that the larger the overall organization, the more that general, content-free management is the norm, and the more likely it is to be imposed on groups that develop software. This is completely understandable from a human psychology point of view. Everyone thinks that the skills and knowledge they have are the really important ones, and the others (which they don't have) pale in importance by comparison. The big bosses are likely to come from sales, finance or consulting and think that having an MBA is a good thing. Why should software be different from, say, running a store, or making deliveries? Or making tubes of toothpaste? If you're a ... drum roll, please ... manager, then that's what you do: manage. Your skill trumps all the others!
This is the dominant view of people who run organizations, or are on the management ladder. In order to advance, you have to adopt the organizational management-centric creed. Otherwise, you'll be "stuck" at the bottom of the management ladder, along with all the unwashed, unrewarded hordes who have to sit quietly with their heads down as various management fashions sweep through the grasping folks with sharp elbows who occupy the rungs of management ambition. If you even try to say "software doesn't work that way," all you've done is further disqualify yourself from advancement in rank.
If you've ever wondered why it is that small, under-funded organizations are nearly always the one who build ground-breaking software, and that giant, "well-managed" organizations with hundreds or thousands of programmers rarely do, this is your answer. "Good management practices" assure that good software rarely emerges from their large organization, and that outstanding programmers with superior ideas about how to do things are marginalized and otherwise made unproductive.
Software and Baseball
This may sound cynical and harsh. But think about, say, baseball. While it is tempting to think that all those beards
had something to do with the Red Sox winning the 2013 World Series, it is more likely that their outstanding pitching, fielding and hitting enabled them to defeat an excellent Cardinals team.
The 2012 season was awful for the Sox. It was their first losing season since 1997, and worst season since 1965. How did they respond? Did they update their project management methodology? Did they send in HR specialists to get everyone to be nicer to each other? Did they sideline people based on failing to high-five someone when they struck out with men on base? They did none of these things. Here's what they did:
- They fired the manager, even though he had a year left on his contract.
- They got rid of a bunch of players based on ... their poor performance!
- They acquired a bunch of players based on ... their superior performance!
- Finally they focused on their energies on, you know, ... winning games! Doing whatever it takes!
Building good software is surprisingly like building a winning baseball team. Everyone does their job and puts everything they have into delivering great results. If someone isn't performing, too bad -- you're not good enough to be a Red Sox! (Oh, just think how badly his feelings must hurt. How cruel!) Even so, sometimes someone is so awesomely good that it seems like he's carrying the team on his shoulders -- and with Series MVP David Ortiz, you can make a strong argument that's exactly what he did with the excellent Sox.
Conclusion
People should be nice to each other. There should be mutual respect. But software is about results. The difference between average and great can easily be 10X for an individual, and 100X for an organization. You don't get "great" by focusing on process issues or good general management practices. You get "great" by ... wait for it ... focusing on software! Just like a musician focuses on the music and a painter focuses on the painting, the best software people focus on the software. The substance.
Comments