Random Walks in the Low Countries: Managing outside the book

I was off the computer and working with associates and contractors this week, building my businesses. It’s arguably what I should be doing more of: planning, communicating, coordinating, motivating. But since both companies are very dispersed, virtual organizations, a “stroll around the bridge” becomes a circuit of the country. Maybe hours of driving isn’t the best use of my time, but I get space to think, listen to some podcasts, catch up on some calls.

It’s not what my classes said to do. But, here, now, for me, so far… it works.

In part, it’s because I’m working within a well defined process and towards a very clear goal.

Then it's almost just a matter of resources: populating the roles and funding the work. Once the wheels are spinning, it comes down to assure that milestones are met, transferring results quickly, noticing problems early, and dealing with them effectively.

And, for the rest, it’s because I can rely on really good people.

This is where management feels unconventional. As a virtual company staffed by contract, our high-performers have to work both independently of and collaboratively with other contractors that they never meet. So, I end up fitting people together like a puzzle rather than as a network: have to specify and mediate all of the boundaries since they are each making bind transfers.

It’s not what the books recommend.

Wisdom dictates that high-performing teams should share a space and interact closely. If you dole out component tasks to geographically dispersed vendors, you end up like early space shuttle projects. NASA designers made work requests, then bolted the pieces together as they came back. They turned on the finished system: there were, fortunately, only several small fires and no really damaging explosions.

I’m hoping that frequent physical contact and a good sequence of progressive testing will prevent too many problems.

Besides, these are *simple* projects: what could possibly happen?

Lots, of course: I keep the list handy:

Unrealistic or unarticulated project goals
Inaccurate estimates of needed resources
Badly defined system requirements
Poor reporting of the project's status
Unmanaged risks
Poor communication among customers, developers, and users
Use of immature technology
Inability to handle the project's complexity
Sloppy development practices
Poor project management
Commercial pressures
Stakeholder politics

That last one was a particular issue this week: addressing politics and underperformance. It’s my least favorite part of the job.

In one case, I’ve got a principle who is isolating his activities from the others, who are naturally concerned. This comes down to policy: We will all be respectful, open, and collaborative even while taking responsibility for our functional areas. I try to engage with everyone’s suggestions (from Why can’t we do a clinical study first instead of last? to Why don’t we use an iPod as the device controller?) and they’ve resulted in changes that really improved the business (actually, only one of those two did). Building silos will kill us.

In another, lack of specific knowledge is making an otherwise capable consultant slow and tentative (at $300 per hour). I stopped him and framed up the specific, short-term questions that need to be solved. I made a couple of calls and picked up some resource materials, then sent them to our consultant. “I think I see what you are getting at,” he wrote back. What do you recommend? A day passed and then I got a really brilliant piece of interpretation and a plan for action. He absolutely flowered just when I was thinking of replacing him: the challenge to raise his game brought out his best.

So, that’s my week. I travel from site to site, thinking of what I need on the way in, then how it fits on the way out. At each stop, I draw pictures with circles and arrows; lay out the process and the connections. After each visit, I stop at a Starbucks for a coffee and muffin, firing off emails while the ideas and enthusiasms are fresh.