Project Managers Shouldn’t Trust Their Programmers. Do This Instead

A few years back, I got a call from a friend. A project was going off the rails, and months of his time and resources were circling the drain. Desperation hung in his voice.

A trusted "partner," a company that he had worked with for over a year, had left him high and dry. He had been working on a project alongside his "trusted partners," and things seemed to be going great until one day his "team" jumped ship and left him holding the bag.

My friend, who had been busy working on business development, suddenly found himself with a collection of Javascript files that he didn’t even understand. He felt like he had been abandoned on the side of the road, watching the taillights of his ride disappear over the horizon.

The departing team had all the technical skill, documentation, and understanding of the software, and my friend, while quite bright, didn’t understand the code.

This scenario is common enough that I’ve got my own shorthand for it: Trust. Pay. Lose.

You start by trusting your programmers. You think of them as partners. They’ve got all the technical skills you need. They know JavaScript (or Java, C+, whatever). They understand the inside and outs of GitHub and are DevOps experts. They’ve got Big Data down and are User Experience experts and whatever else you need.

Real superheroes.

And they might even be superheroes, able to code and design world-class software. There’s a major problem, however. The software they develop is theirs, not yours. Why? They know the code. They understand how the software operates, and the systems interface.

You don’t. At least, not unless you make that software your own.

What does that mean?

Don’t trust. Don’t pay. Don’t lose.

Don’t trust your programmers, at least not completely. You can have faith in their abilities, you can believe their milestones and feel confident in the eventual outcomes. But you should never fully trust them. Instead, hold your programmers accountable.

And you start by not paying for everything up front. Sadly, if you do so, there’s a risk that they’ll take the money and run. You can try to take them to court if they do so, but good luck. They may hem and haw and claim that everything is your fault. And if you happened to have outsourced work to a team in a foreign country? Good luck navigating a foreign legal system.

Okay, so you know not to cut all the checks right away. So when do you pay? And how do you know the project is on track?

The best solution is to validate their work by reviewing the code. If you happen to have programming chops yourself, you might dig in yourself. If not, you need to find an outside expert who can look through the code and ensure it makes sense and that the progress is real. Heck, even if you do know how to program, outside eyes are still a smart idea.

Validating the code puts you in charge. You’ll have more control over milestones and releasing payments for work completed, not the claims of your programmers. You and your expert will grasp the code from the get-go, and if the programming team does bail, you’ll be in a better position to take over the project and/or bring others on board.

And once the work is reviewed, you’ll know what you’re paying for.

As work is validated, create a "risk list." This list will help you understand where threats may emerge, allowing you to act preemptively. By constantly reviewing the project and code (ideally, at least every two weeks), you’re increasing your own knowledge and oversight, helping make the software your own, not just the programmers'.

Will some programmers balk at the idea of oversight? Sure. But if you’ve got nothing to hide, you’ve got nothing to hide. While you need to make the oversight process efficient and fair, great programmers shouldn’t fear reasonable reviews.

Trust. Pay. Lose.

Don’t trust. Instead?

Review. Reward. Win.

Yegor Bugayenko is founder and CEO of software engineering and management platform Zerocracy.