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.

Confronting Reality - are you ready to become Fierce?

Surfacing issues or current states of mind to top levels of leadership in organizations with deep hierarchies is fraught with peril. Some top leaders seem afraid of transparency. Some resist the idea of nemawashi - of showing deep respect for their people, of acknowledging that in order to improve our collective lot we should engage everyone's intellect. Vital constraints and facts are closely guarded, and decisions are made in relative secrecy.

Top leaders don't have to attempt to carry the full burden of imagination. They don't have to do all the thinking for all of us, and then issue directives. And yet, many of them don't yet know how to let go. Some haven't managed to muster the courage to become fierce. Some are likely Very Afraid of just such Anarchy as Tobias Mayer's Spirit of Change implies. And attempts at tightening grips of control will only generate more backlash and discontent, more frustration & misery.

Ultimately (and rather amazingly), it comes down to what we believe matters most. Belief is so insubstantial, it's a fleeting pattern of dynamic electro-chemical reactions in the neural networks of humans. And despite this fragility, belief and intent are perhaps the most powerful forces in the human sphere of affairs.

What we believe in drives our habits. It informs our reactions and choices. It shapes who we are, and what we want to be remembered for.

What do you believe in? How do you want to be remembered? What will you do to make it so?

STEP – A Map for an Agile Journey

I recently published an article on InfoQ, about how one might look at a journey of continuous improvement inspired by Agile thinking. Would love to hear what you think of it. Which ideas are most helpful to you?

Delight and Joy - unalienable rights

The Agile Manifesto is an excellent foundation for creating better software development organisations. However, on its own, it lacks a unifying foundation - a means of bringing everyone together, across any organisational boundaries.

Many people still predominantly think in terms of applicability of Agile for specific projects: "Can this project be run using Agile?" or "Would Agile be appropriate for this project?". That kind of attitude slows organisation-wide improvement - it implies that in some areas, the existing ways of work might be "good enough" and therefore exempt from scrutiny and improvement.

The Agile Manifesto, as it currently stands, doesn't directly help people to think in more holistic terms, like: "How may we delight our customers better?", or "How may we best improve our way of work?", despite the fact that agile techniques are very well designed to support improvement.

A few hundred years ago, a nation was born with a proclamation that included the following words:

We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.

In my experience, nothing fundamental has changed in the mean time - we can still safely perceive these truths as self-evident. All of us that work for a living deserve the opportunity to delight our customers and find joy in our work.

Recent research shows that positive emotions play a significant role in achieving success. Consider Shawn Achor's TED Talk: The happy secret to better work, and Barbara Fredrickson's work on positivity.

We all deserve to have ample opportunities to pursue happiness. Since our work lives use up most of our waking hours each week, we had better make sure we can find great joy in our work. Focusing on delighting customers is an excellent and sustainable source of joy and satisfaction in work.

Dan Pink proposes that in our current culture we are primarily motivated by autonomy, mastery and purpose - I find it fascinating how well that parallels with spirit of the Declaration of Independence. Liberty matches autonomy (the freedom to choose our own course of action), mastery matches life (the opportunity to work at improving our skills, minds and bodies), and happiness matches purpose.

I suggest we may find ways of improving upon the Agile Manifesto, quite possibly by harnessing the influence of positive emotions to achieve lasting success in our organisations. What do you think?

Beware greed in retrospectives

Retrospectives are healthy. Retrospectives are vital for improving our work life. Without them, we wouldn't have a systematic way of examining what needs improving and what we might do about it.

Even so, too often I see teams becoming so excited with the 57 things they've just discovered could do with improvement that they want to try them all at once. Beware greed in retrospectives - do your best to pick just one. Search for the most valuable improvement opportunity, design some experiments for countermeasures, and focus on that one improvement. Create a measurement system such that the results can be analysed with as much clarity as possible. Let the data speak.

Only then focus on the next most pressing constraint and repeat the process of root cause analysis, countermeasure design, experimentation and adaptation. We owe it to ourselves to be very reserved with our investments - we only have a very limited capacity for improvement, we should spend it wisely, on the item that we expect will lead to the best improvement.

Hrair - how many folks should we have in our meetings?

Meetings:

• Some are the bane of our existence. Too many people involved, too easy to get distracted, not much happening overall.
• Some are delightful. Just enough people, high energy, intense conversation and collaboration, joyful enthusiasm shared.

It turns out that our brains are wired such that we can only keep a very small number of things in mind at any one time. Some argued for 7+/-2, some say even less, around three or four.

Hrair is a word found in the rabbit vocabulary of the book Watership Down. Since rabbits have an awful time with numbers, they only have actual words for numbers one, two, three, and four. Any number after that is hrair, which literally means "a thousand", but often means "a lot". The idea is that for humans, hrair might be similar, and at most stretch to 7 plus-or-minus 2.

The interesting observation is that small meetings (of no more than hrair folks) tend to be far more focused, effective and joyful. The same concept applies to Agile teams - teams of no more than hrair folks have an advantage at keeping tightly focused on a shared set of goals.

Groups of more than hrair people find it increasingly harder to keep focused on a single conversation. It becomes a progressively easier to get distracted and tempted to draw into a side-conversation with hrair folks or less.

The Power of an Agile Mindset

Linda Rising gave rousing closing keynote The Power of an Agile Mindset at Agile 2011. She got an impressing standing ovation at the end of the session, and at times there were even a few tears in the audience - a most impressive feat for a rather cerebral audience.

Linda draws our attention to the “agile mindset,” an attitude that equates failure and problems with opportunities for learning, a belief that we can all improve over time, that our abilities are not fixed but evolve with effort.

In contrast, a fixed mindset constrains our ability to change, improve & adapt - it robs us of a joyful future.