Seven Unbreakable Rules of Software Leadership

Steve McConnell, of Construx and Code Complete fame, gave a webinar on this topic earlier today. He started by observing that there's no shortage of number-based leadership advice, from the One Minute Manager, to The 30 Management Principles of the US Marines and nearly everything in between.

He argued that leaders of Software organizations must articulate a vision for the future of the organization - be sure that you're actually going somewhere where people might want to follow. What might the future of work in our organization look like? What kinds of improvements do we want to see in our work? How will we get there?

Steve then observed that the more successful leaders of software organizations don't just expect responsibility to be parceled out to them - they claim it. They don't "play the victim card", saying things like "my boss won't let me do X". Instead, they take an active role in explaining great ideas and initiatives, with tenacity and tireless determination. In other words, don't expect to be "assigned" or "allowed" to do something valuable or useful. Jump in, and make it happen as fast as you can.

In software, there's no "perfect" fore-knowledge. That's why great software leaders must figure out how to make viable decisions even in ambiguous circumstances. Figuring out what's the "last responsible moment" to make a decision is a critical art to master.

You also have to put the organization first - which means you might need to take some hard decisions, provided they contribute to the long-term health and viability of the organization. Some people observed that there's an apparent conflict of rule 4 with rule 7, "Treat Your Staff as Volunteers"- the astute leader will find a good balance of decisive decision-making and community engagement, possibly through habits like nemawashi and Gemba walks.

The trouble with lack of "passion" or engagement is that no business leader wants a software leader that's lackadaisical about their business. While discussing the need to find passion for your company's business, Steve offered the personal experience that although you might not feel particularly passionate about a topic at first (like he didn't feel particularly passionate about software engineering when he started writing the first version of Code Complete), you might find yourself develop an intense passion over time (like he did by the time he finished writing the 900+ pages of that tome).

Habits can inspire emotion. Even if you don't feel particularly joyful and you smile, the body will tend to release "happy" chemicals in your blood-stream. Pretty soon, you might notice you feel better. Similarly, if you should need to "fake" passion in your business for a while, that's OK - after a spell, you may well get swept in the excitement and your passion may just become "real".

Becoming a student of communication means that great software leaders must master the art of adapting their communication style to the needs of their audience. A CFO might want numbers. A marketing executive will want stories of exciting features. Developers may want exciting new tech. This may seem obvious for sales or marketing professionals, but it looks like it needs to be spelled out explicitly for software leads.

And finally, Steve concluded by observing that command-and-control is essentially dead. You can't afford not to treat your staff like volunteers, doing your best to give them purpose, autonomy and chances to practice mastery in their work.

What do you think of these seven rules?

You think "that" about teamwork?

Here are six misperceptions that HBR's J. Richard Hackman found out through research:

Misperception #1: Harmony helps. Smooth interaction among collaborators avoids time-wasting debates about how best to proceed.

Comment: A bit of creative tension is indeed useful. High-performance teams are usually also high-energy teams, that know how to navigate conflict well. I suggest that a deeper harmony exists in high-performance teams, not just superficially. People trust each other to express diverging opinions and then creatively integrate them for the benefit of all involved. That's true harmony - not just the surface appearance of it.

Misperception #2: It's good to mix it up. New members bring energy and fresh ideas to a team. Without them, members risk becoming complacent, inattentive to changes in the environment, and too forgiving of fellow members' misbehavior.

Comment: No surprises here - longer lived teams fare much better. We can safely continue to push for long-lived Agile teams in pursuit of high performance.

Misperception #3: Bigger is better. Larger groups have more resources to apply to the work. Moreover, including representatives of all relevant constituencies increases the chances that whatever is produced will be accepted and used.

Comment: No surprise here either - 7+/-2 still seems to work best.

Misperception #4: Face-to-face interaction is passé. Now that we have powerful electronic technologies for communication and coordination, teams can do their work much more efficiently at a distance.

Comment: Yes, we must keep pushing for more face-to-face contact in order to improve the flow of value.

Misperception #5: It all depends on the leader. Think of a team you have led, or on which you have served, that performed superbly. Now think of another one that did quite poorly. What accounts for the difference between them? If you are like most people, your explanation will have something to do with the personality, behavior, or style of the leaders of those two teams.

Comment: Yes, self-organizing teams matter most for achieving success. It's not just the leader - it's up to all of us to make our teams run like greased lightning...

Misperception #6: Teamwork is magical. To harvest its many benefits, all one has to do is gather up some really talented people and tell them in general terms what is needed--the team will work out the details.

Comment: Yes, teamwork requires work. High performance doesn't just emerge or happen as soon as you've dropped the "ingredients" together and stirred a bit.