Requiem

My friend Larry Robbins died last Wednesday, apparently of karoshi. He was 52 years old.

Larry’s death by overwork was self-inflicted. He was the sort of person who constantly looked for what wasn’t being done that he could do. The universe being what it is, his attitude gave Larry an infinite pile of work.

He figured if he just shoveled hard enough and well enough he could clear the pile.

Larry was driven by accomplishment, not by work/life balance. If you worked for him, you needed to be driven by the need to accomplish too, because like it or not, that’s what you’d do: Produce more and better work than you’d ever produced before.

I worked for Larry for several years, and we became close friends. Later, in a different company that hired him to be their CIO, he became a difficult client. Consultants should never consult for former consultants. You can’t win.

And so, after a year we agreed we had to choose between being friends and doing business together. Friendship won.

Before I left I asked what he’d learned from having left consulting for an honest job. His answer surprised me: After more than a decade of being a process consultant, designing “perfect” processes and making them work for clients, he’d discovered that putting a good-enough process in place and perfecting it one day and insight at a time worked better.

What I admired second-most about Larry was that he never stopped learning.

What I admired most about him was this: In a conversation about corporate, what headquarters ought to be doing but wasn’t, and other general griping about how the company should be run, Larry said, “Wait a minute. We’re all leaders of the company. Let’s just do what we need to do.”

We’re all leaders of the company. Every year since I’ve peeled back another layer of that statement. I’m not done yet.

That statement is why, in my book and seminars on project management, I encourage participants to take responsibility for more than “just” project completion – to take responsibility for success as well, and to engage every member of the project team at that level, too.

The difference, in case it isn’t clear, is that completion means you produce all of the promised deliverables in forms that adhere to their specifications … say, a piece of working software. Success means the business actually receives the intended benefits … improved process throughput, perhaps, or reduced unit costs if that’s the plan.

The usual response, when I first present this perspective, is for participants to ask how they can be held accountable for success when they don’t have the authority to make it happen, because, “Everyone knows you have to match authority and responsibility.”

Fair enough: Those companies that hire and lead poorly enough that managers have to hold people accountable can only do so within their areas of delegated authority.

I tell them what I think Larry would have said: That nobody has to hold a leader accountable for anything, because leaders take responsibility for getting the job done. If they don’t have authority they rely on their ability to persuade, and if they can’t fully persuade they do their best to influence.

That means a project team that’s accountable for building software should take responsibility for maximizing the likelihood of it being put to productive use. This is quite different from the all-too-frequent arguments between developers and business managers as to whose fault it is that the software doesn’t do what the business needs.

More broadly it means asking where we each have leverage instead of figuring out what prevents us from getting something important done. It’s a better way to look at leadership in an organization of any size, whether your role is project manager, operational manager, executive, or staff. Figure out:

• What you want to accomplish.
• Whose help you’ll need to accomplish it.
• How you can obtain their support.
• Where you can compromise to obtain it, and where you can’t.
• Whether you’re willing to do what it will take. And if you’re not, don’t complain when it doesn’t happen.

I’m pretty sure that, or something like it, is what Larry meant when he told his managers they were all leaders in the company. It was the most important lesson in leadership I ever received.

Larry and I had our differences, among them wildly different theological perspectives. We promised ourselves we’d explore them in depth one day.

It appears we’ll have to delay the conversation for awhile. If we have it, though, it will be a short conversation.

Because if we do, I’ll have to acknowledge he was right.