The PM Who Builds Tools — Can You Do Both?

Every few weeks, someone asks me a version of the same question: "How do you find time to build tools when you are managing three programs?"

The honest answer is that building tools is not separate from managing programs. It is how I manage programs.

The False Dichotomy

There is a persistent belief in project management that PMs should be "above" the technical work. Your job is to coordinate, communicate, and remove blockers — not to write code. I understand where this comes from. A PM who disappears into a codebase for a week while stakeholders wait for updates is failing at their primary job.

But there is a middle ground. When I built the Engineering Intelligence Platform, I was not doing it instead of managing delivery. I was building it because manual capacity planning was eating hours of my week. The tool gave me those hours back, and it gave the entire organization better visibility.

When Building Makes Sense

I build tools when three conditions are met. First, the problem is recurring and affects my ability to manage effectively. Second, no existing tool solves it well enough. Third, I can build a working version in days, not months.

The spec-driven AI agent I designed fits all three criteria. Requirements-to-code translation was a bottleneck across all my programs. Existing tools were too generic. I prototyped the workflow in a weekend.

When It Does Not

I do not build tools for problems that are better solved by process changes or by buying existing solutions. I do not build tools that require ongoing maintenance I cannot commit to. And I never build tools during crunch time — delivery always comes first.

The key is treating tool-building as a leadership multiplier, not a hobby. If the tool makes your team faster, it is leadership work.