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?

The Gemba Walk with Jim Womack

Jim Womack just gave an excellent The Gemba Walk webinar (there's also a follow-up Q&A session to watch), under the auspices of the Lean Enterprise Institute. The core message is that the Gemba Walk can be used as a mechanism to give context for horizontal conversations that lead to improved flow. An excellent practice for all leaders!

Start with Why

See the Simon Sinek: How great leaders inspire action TED talk for an interesting view on modern leadership. Simon argues that the leading companies answer the question Why? before they attempt to tackle the How? and the What?. By presenting a message in the order Why?, How?, What?, leaders can forge an emotional connection with their people and clients. Jean Tabaka just hosted a nice session in Wellington following this very concept, applied to the use of Agile methods.

This is not to be construed as being in conflict with John Shook's advice about the order of asking questions when doing a Gemba walk: "First ask what, then why, then what if ... and, finally, why not." Notice that this order checks for the standard work that should be the What?, then verifies that the Why? is understood, and then explores improvement opportunities.

Both views are harmonious. A healthy value stream or network needs a clear Why? It drives the value being created for clients, and guides the improvement efforts of the workers, for both work products (What?) and work processes (How?).

Going to the Gemba for Agilists

John Shook's latest e-letter, How to Go to the Gemba: Go See, Ask Why, Show Respect covers four main perspectives from which people generally observe work when going to the Gemba:

1. Solution View - hunting for opportunities to use Lean tools. Tempting but risky - since it implies a hazardous rush to conclusions - potentially disruptive for continuous improvement if used on its own.
2. Waste View - keeping an eye out for wastes of various kinds. Useful, and should be handled carefully so as not to pursue local optimization to the detriment of global outcomes.
3. Problem View - confirming and inquiring into impediments. Handy, and may take many shapes - its weakness (and opportunity) lies in the fact that it lacks an in-built structure. Various problem-solving approaches can be devised to suit the team and organization's context.
4. Kaizen View - seeking patterns, forms, routines. By engaging the people doing the value-adding work into a structured problem-solving pattern, this is the strongest choice.

What does this mean for the business of software-intensive systems development? The ideas apply directly - no significant adjustment required.

To achieve continuous improvement, we must start by respecting our engineers, encouraging and supporting them to create improvements to their work processes, in addition to creating and enhancing features for the systems they develop. We trust them to create intricate engineering constructs. Surely they're best placed to design the improvements to their work processes as well.

We have a responsibility to develop ourselves and our colleagues into intense noticers and tenacious experimenters. We must challenge each other to create better systems that create products in addition to creating the great products themselves.