Once in a while you get shown the light…

I read a good article today entitled “Monitoring is not Management” in a blog on a greentech company website (http://bit.ly/a9WIBd). The subject was data center systems; in particular, energy consumption in such systems. Check it out, if that’s your cup of tea.

What struck me, though — besides being a pretty good, comprehensive summary (if that’s not too oxymoronic) on the subject — was the same distinction can be made when it come to managing or leading people. Have you ever met a supervising manager, regardless of title or level in the hierarchy, who thought their principal role was to monitor their people’s performance and document it in a formal evaluation? Or a project manager whose main focus — can’t really call it a contribution — was to monitor project progress? To the extreme of watching that person, or that project, slowly but inexorably fail right in front of them? Observe and report. Wasn’t there a bad comic film called that recently? Monitoring is absolutely not enough!

In keeping with the erstwhile theme of this blog, I need a wilderness analogy. So here it is: Whitewater paddlers in rafts, kayaks and canoes all learn and practice the art of reading water. It’s a critical skill employed in getting downstream safely, especially when confronting big water or very technical runs. It involves scouting the river ahead of you, with a particular emphasis on seeing currents, eddys, holes, ledges, obstacles and other hazards that must be negotiated… and which failing to negotiate could seriously wreck your day. In a word, it’s monitoring river conditions. But what if, having gathered all this data about the river, you did nothing with it to select or alter your planned route, tactics, maneuvers for proceeding downstream? What if you didn’t use that data to put safety measures in place, even prepare for emergency rescue in the worst case? It would the height of foolishness; it would in fact be downright nuts!

The same is true for business, and it is a management imperative. The ability to translate metrics-driven data and keen observations of people at work into concrete actions that lead to better performance is one of the defining characteristics of what a manager should be. It is the hallmark of a leader. It’s what managers should be measured — and managed — on. Failing in this regard is the whitewater equivalent of running your boat and its crew straight into a deadly hydraulic that you could easily see and avoid. Don’t settle for any manager who only monitors. It’s a recipe for disaster.

I’ve had the distinct pleasure of working on, and with, a lot of great teams in my career. Engineering teams, management teams, project teams, you name it. I’ve also been on some real doozies, where an extra incentive for accomplishing the mission at hand was just to be done with it! So, as I ponder my next business venture, and in particular, the first 30 days on that job, I’ve been thinking once again about what makes for a truly killer team; what really sets it apart from all the rest.

A useful analogy, I find, is the infamous “lifeboat exercise”, but done in reverse. Most management types have been through the lifeboat exercise at least once; this is where, when evaluating the performance or contributions of a large group of individuals or when preparing for some impending reduction in staff, you must determine who you would absolutely keep if you could only keep a certain number while all the others are cast adrift. Who gets put in the lifeboat? It’s a cruel sounding exercise, but it serves its purpose rather well.

So now, let’s flip that scenario on its ear. Rather than deciding who will “survive” whatever terrible fate awaits those not in the boat, we’re going to man this boat for a long and treacherous journey to a far off destination where fame and glory — or at least really important business achievements — await. There may be limited supplies, a sketchy map at best, and untold hazards that threaten to swamp and sink the enterprise. It will not be for the faint of heart!

A different dynamic has to be considered when you’ve manning the lifeboat in this case. That is, when you are commissioning a team to accomplish a difficult mission — or better yet, a number of such missions — it’s not just about who your best individual performers are. Yes, individual capabilities are absolutely part of the equation. But there are two other parts of equal importance, especially if you consider the goal to be completing many missions and not just one. Those parts are chemistry and longevity.

I know, I know, you’re already thinking “What does longevity have to do with a group of people completing one journey together?” The answer shouldn’t surprise you, but you’ll have to read my next post to find out. And here’s a hint: it’s less about why chemistry and longevity are so important than how you get or create them… and why it’s so hard.

“It’s a dog eat dog world”, my dad used to say. Is it really? I’m not so sure. Sometimes, perhaps, but certainly not always. Or so I’d like to think. “We’re all in the business of people”, was another of my dad’s favorites. “It’s all about PEOPLE.” On this point, I believe he was right.

I was reminded of this recently on a backpacking trip in Colorado with my oldest friend, Henry. Henry and I have known each other since high school but, he living in New York for the last 30 years and me in California, we’ve seen each other infrequently at best over that expanse of time. On this particular trip, we both realized that a few days of talking face to face around the campfire or plotting the next day’s adventure on the trail means a great deal more than year’s worth of email, texts, tweets and facebook updates. So, what does this have to do with work?

I’ve worked in the technology business, leading teams building and delivering software products and computing-enabled services, for over 25 years now. In all this time, I’m still amazed how many people think if we can just get the technology right everything else will take care of itself. As if the software or the hardware or the network protocol will deduce our desires, organize itself, and solve all our problems. If it’s not the technology itself, then it must be the methodology or processes employed to produce it.

All this, of course, is nonsense. In virtually every software related book I’ve read, seminar I’ve attended, study I’ve heard referenced, or project I’ve participated in — and there have been a great many — the number one problem encountered, the greatest impediment to success or cause of failure has ALWAYS been said to be communication. Communication between people.

It’s no surprise that the first key tenet of the Agile Manifesto is the valuing of “Individuals and interactions over processes and tools”. Yet, knowing this and acting on it to good effect are two different things. Why? There are many reasons.

First, it only takes a few disbelievers — those don’t or won’t make the effort — to frustrate and undermine those who do make the effort. There are simply some who just don’t want to play; they rather focus on the toolset exclusively. Second, there are often conflicting views over who should be “in the loop” and when. In an effort to be fast and lean, we cut people out of the conversation because we don’t appreciate their value or, perhaps, our own limitations. Third, everyone is busy and too often “communicating” is not appreciated as work. Writing code is productive work. Talking about what the customer really wants is not. Lastly, it’s just plain hard to do consistently well. People get tired, they have bad hair days, they get distracted by the crisis-du-jour, or they just don’t like each other. Maybe you’ve got a team member who isn’t pulling their weight. Then there are cultural differences, language barriers, time zones, you name it. Ultimately, these are just excuses.

So, how do we overcome these communication gaps and barriers? For starters, we need leaders who recognize both the critical importance of effective communication and the fact that PEOPLE are the key to making communication work… or fail. Then, those leaders need to do three things:

1. Personally make sure everyone on their team has, or obtains, that same understanding and are committed to doing their part diligently.
2. Create an ecosystem where it is easy for people to communicate effectively and hard for them not to. This might be everything from a common vocabulary (whitewater river guides use a system of handsignals and commands that never vary, and they teach everyone in their boat what those things are before they start), shared workspaces, frequent group reviews, a system of incentives and rewards, opportunities for socializing and fun (the campfire or trail?), and yes, even tools. But whatever it is, the ecosystem must actually work for the people in it.
3. Pay attention and watch diligently. Talk to your people. Things may start well, but once pressure is applied, people tend to wall themselves off to be “more productive”. Once the walls go up, communication stops and, well, there you have it: the number one problem that gets projects into trouble, or kills them outright.

What’s even more amazing to me than technology professionals undervaluing the human element of a complex software project is the non-technical business leader who fails to develop and care for the people in their charge. More on that in another post.