On ownership

The first time I “owned” a project was when I started full-time work. I had managed to go through all of secondary school, university, graduate school, and a few summer internships, without ever “owning” anything, so the idea was completely foreign to me. I imagine it’s foreign to most people just joining the workforce.

The project owner is the person responsible for a project’s success or failure. When the project succeeds, they get the credit; when it fails, they get the blame. This is similar to other corporate roles, so it may be worthwhile to define ownership by reference to its pecularities.

1. Each project participant reports to the owner, but the owner isn’t the participant’s manager.

The project participants report to the owner in the sense they are expected to update the owner on their progress and flag any roadblocks. But, unlike a manager, the owner typically doesn’t have the power to discipline incompetent or recalcitrant participants, or to reward excellence. The owner can only raise any issues with the person who launched the project.

Ownership also isn’t the same thing as dotted-line reporting, which is typical in “matrix management” structures. In a matrix structure, you may, for example, have a technical boss (responsible for reviewing the details of your work) and a different regional or country-level boss (responsible for the office in which you’re located). But unlike project owners, your dotted-line manager usually has real power over your future at the company.

2. You can own a project in which you also participate.

You may start working on a project with no owner, and gradually grow into the ownership role. This is fairly typical, in fact. All it means is that you have to wear two hats in any project updates.

3. You can also own a project in which your boss is participating.

More interestingly, there’s nothing stopping your direct boss from being on a project that you own. In this case, for the purposes of the project, your boss reports to you. This works because your boss wants (or should want) the project to be successful and understands that she has a role to play in making that happen, but doesn’t want to be involved in every detail. They’re happy to cede control to someone else, including a subordinate, who will get things done. Good bosses also don’t mind being held accountable.

4. Owners have no “real” power, but are blamed for a project’s failure…

It’s appropriate to blame owners for project failures because projects, like programming code, tend to have smells that portend problems. Projects where responsibilities aren’t explicit, distinct, and documented; where deadlines are non-existent or habitually missed; where there are large, unaddressed unknowns; where there are single points of failure; and where there are no waypoints to measure progress and change course, all tend to smell very badly indeed to anyone paying attention. It’s these types of factors, rather than the incompetence or brilliance of any single individual, that tend to determine a project’s fate.

It’s true that owners, unlike managers, have neither carrot nor stick in their arsenal to encourage good behaviour. They have no “real” — that is, formal — power. In practice, all they can do is stand on a soap box and scream.

But the owner can give early warning of problems to the person with the actual arsenal. This is more than half the battle. Important projects are also visible, and embarrassment can be a powerful motivator. Nobody wants to be singled out as one of the reasons why a project failed.

5. …and credited with its success.

Any project of reasonable size that comes off without a hitch probably has a good project owner behind the scenes, even if they don’t have that official title. Diffuse responsibility for individual project parts usually leads to no accountability for the whole.

A good project owner will be everywhere and nowhere. Everywhere, in that they will touch every part, and nowhere, in that they may be responsible for none of them. Like many professionals, good project owners can make their role look easy almost to the point of superfluity. But anyone with experience knows to attribute the appearance of smooth sailing to the ferocious pedalling underwater.

6. Ownership doesn’t have to be granted; it can be taken.

Anyone can decide to be a project owner. It doesn’t require a promotion, or an assignment from your boss. You can simply declare to whomever created the project that you will be the single point of contact. If you listen carefully, you’ll usually hear their sigh of relief.

Sometimes, as I mentioned above, you’ll become the owner gradually. People notice that you tend to know what’s going on, and they start coming to you for updates.

7. Ownership is the proving ground for management.

Unlike owners, managers are also responsible for people. They need to make sure that they are getting the most from their team, keeping them happy, and helping them grow.

But in the end, all of that is in the service of one goal: Getting things done. Someone who can consistently deliver projects on time, with quality, and without excuses, is a very strong candidate for a managerial role. Giving that person additional responsibility before promoting them allows bosses to test their mettle, without having to pay to run the experiment.

The whining stops when you become the owner.

Ownership does share one fundamental attribute with management: Once you become the owner, you lose the right to complain. This was the thing that was hard for me to understand, at first.

I had worked on tons of projects at university, and was used to being responsible for what I did. It seemed bizarre to now be held accountable for the shortcomings of the useless ne’er-do-well in the next cubicle. After all, I can’t make them do anything. How can that be fair?

But when your project fails, “it wasn’t me” is never an appropriate response. The time to bring up the shortcomings of individual participants was before. If there were warning signs, you should have noticed and mentioned them. If there were no warning signs, you should still have seen trouble brewing. If there was no way to do that, you should have had a backup plan. This way of operating isn’t always fair, but neither is life, especially corporate life.

Once you get comfortable with this idea, you’ll become appropriately paranoid. You’ll pay closer attention to the work of participants who are unproven or weak. You’ll think of other ways, however improbable, in which your project may fail, and develop contingency plans. You’ll disbelieve optimistic timelines, and build in buffers. You’ll communicate risks early, to get help from the powers that be and to keep your ass covered if no help is forthcoming. And you’ll wield the power of your office — access to all participants, knowledge of the whole, the ear of the sponsor, and the ability to call out underperformers— to get things done.