Project Managers Should Know Developer Tools

Getting in the coding weeds, no matter your role, can help your teammates, and it allows you to more intelligently speak to clients about how and why coding decisions are made.

As a project manager and frequent hands-on, quality assurance tester, I find I tell people they did something wrong a lot. I try to tell people when they’ve done something great too, but it’s so easy to get in phases of projects where I feel like a big jerk who’s making other people feel like big jerks. But it’s an important role. We care about quality, and we want things built right. So reporting and killing bugs is a must.

While I can’t just skip what I’m doing to resolve feeling like a jerk, there is something I’ve tried that helps—getting in the code and solving the problems myself.

If You Work on Digital Products, Code is Your World

I’m not a developer. I’m a content strategist, project manager, and tester, if you were to ask what skills I utilize most often on the job. Code is not my world... but it is. I may not personally be brought on a job to code, but I am brought onto jobs to help manage projects that have code as the end product. So, code is my world. And what better way to understand my world, than to actually swim around in it?

Feeling Like Less of a Jerk

In order to help better understand what we’re doing and, mostly, to feel like more of a supportive teammate, I code what I can. When I’m in the heat of reporting issues, I’ll keep my eyes out for ones I can solve for the team. Copy change? I got it. Minor and very well-defined color or some other change I can handle? I got it.

It was pretty scary at first, but now hopping in Github (through the website), creating a branch, making edits, creating a pull request, and even reviewing and merging simple pull requests feels completely natural. And I think I’m a better manager for knowing it.

The Result

Adding code winds up with one of two results:

  1. I fall flat on my face, and the developers I’ve been critiquing get their chance to critique me, OR

  2. I save someone on my team time to focus on other issues.

I have my pride. I totally want to be right, but there’s good in both outcomes. I either alleviate time or remind them I’m not perfect either, and I also better understand the tools our developers are using each time.

The more I get into code, the more intelligently I can speak to clients about how and why we do things. Bonus: sometimes I even solve a problem for a client while we’re on the phone together, and they get that instant satisfaction and realize I’m decently competent. (win)