Social Glass

I had an interesting conversation with a good friend of mine while rock climbing tonight about being a Manager.  He runs engineering and IT Ops for a medium-sized company in San Diego, and we’re almost exactly the same age.  I asked if he ever feels settled with his job.  He said “no”. And I feel the same way.

Back in the day I was a Software Engineer.  My ability to do my job was easily measurable – almost binary even.  If I wrote good code quickly that had few bugs it could be easily guaged that I was doing a good job.  Bugs and features are all tracked and can be reported on.  Life as a Software Engineer is, well, very quantifiable.

But life as a Manager is not. It’s qualifiable.  Managers are good if they develop maintain trusted relationships with others within the company, if they delegate, and if they empower those who work for them.  And how is “good” measured?  It’s not, really.  If the team’s producing, then the Manager must be doing a good job.  But what if the team is producing because it’s a good team in its own right?  What effect do I, as a Manager, actually have on output?  It’s hard to say.

So how do the people who’ve been managing for 20 years stay sane?  How do they feel like their teams are better because they’re there?  I think they’ve learned to let go.  To concentrate on a few important items, and to delegate the rest, even when that means “the rest” might fail.

The chart above illustrates where a good Manager will find himself operating.  If he’s planned well, the matters at hand will not be urgent.  And if he’s properly plugged into the business and maintains healthy relationships, he’ll be able to identify what’s important and what’s not.  A good Manager, then, wants to exist in quadrant IV on a daily basis.  The rest should be delegated.

Quadrant IV is the key to sanity.  It’s the key to managing being a Manager.  I guess I haven’t figured out how to get to quadrant IV yet.

Five of the people on my team work out of our China office in X’ian. Last week they informed me they were taking Monday off for a team building exercise. Each team was given a wall in the office to paint. And they didn’t paint murals. Nope, just a fresh coat of white paint.

On Tuesday they were instructed to work from home to avoid the overwhelming smell of drying paint. So we had our weekly standup meeting on instant messenger (I actually found this to be a rather effective way to communicate with my team there) instead of on the phone.

I love these little cultural differences.

I must say, though, that I’ve never had a team of more enthusiastic, dedicated people than my team in China. They own their work and take personal pride in getting it done the right way. Now if I could only figure out how to do Agile with them…

Enterprise 2.0 is about helping knowledge workers foster productive collaboration, innovation, and create a more connected culture. Knowledge workers keep each other informed through blog posts, author wiki pages together, and share bookmarks for interesting information resources. Together they generate folksonomies – user perspectives on corporate information assets, and bypass IT-sanctioned applications in favor of more helpful tools.

But do all of these activities concern Management – you know, the people who organize the “doers”? Management spends most of its time in meetings reporting progress and being appraised of new initiatives. Does Management really have time to make sense of all of the blog posts, wiki pages and social bookmarks in their Enterprise 2.0 Solution? I’m not sure they do.

Management is more concerned with milestones and KPIs. Milestones track the development of new product features and release dates. They track progress. Progress is achieved through the effort of knowledge workers who may or may not be using Enterprise 2.0 tools to do their work.

And Management’s management is concerned with KPIs (key performance indicators). KPIs track progress at a macro-level and let business strategist understand how well their strategies are being implemented.

Managers need to make sense of the organized chaos that is Enterprise 2.0. From a traceability perspective, knowing which blog posts and wiki pages helped contribute to the development of “feature X” would help Management give recognition to those who authored those assets. It would also help Management track the ROI on their Enterprise 2.0 investment. Semantic Web search engines offer perhaps the greatest technical hope for providing this automated capability. Imagine a world where information assets were annotated with metadata that helped computer programs derive the same meaning from them as humans do through natural language. Each asset about “project Z” could be annotated as such helping a semantic computer program automatically aggregate information about said project.

But I digress.

I’m not convinced that Enterprise 2.0 is a platform through which Management will track milestones and KPIs. Managers don’t operate in the “Detail” layer. Instead, they’ll depend on their teams, which do operate in the detail layer and do leverage Enterprise 2.0, to help them make sense of progress.

I’ve taken a new job with a consumer-focused company in San Diego. I am responsible for a group of people that develop a web site in the endurance sports market (and we use Clearspace externally). Most of my team works in the office with me. Others work out of LA and China. Together we fix bugs and implement new features on the site. Gone are the days of Management Consulting and talking to clients about Enterprise 2.0. Instead I’ve become a middle manager – you know the kind that does nothing but control the flow of information in and out of his group. The kind that adds no value to the business.

Or at least this was my “pre new job” thinking. I couldn’t imagine the chaos that would evolve should I allow the business unbridled access to my team. Focus and prioritization would be non-existent if I sat back and waited for my guys to self organize like a colony of ants. Teams need direction. They need to understand business initiatives. They need to be structured. They need to have context behind the flurry of requirements that would otherwise be hurled at them. On top of this the business needs to manage risk. It needs to know that my team can produce on a relatively consistent basis.

Certainly the Enterprise 2.0 community would never condone absolute dissolution of middle management. But I’m admiting now that at least I am guilty of being over-presumptuous about the lack of value that comes out of the middle management layer. I’m sure organizations are full of bureaucrats, but there also full of good managers who are there for important reasons.