Engineering project management without the overhead

Engineering project management is the practice of planning, tracking, and delivering software work: turning a pile of "we should do this" into scoped issues, moving them through a workflow, and knowing at any moment what is in flight, what is blocked, and what shipped. That is the whole job. Everything else a tool piles on top of it, the roadmaps, the portfolio views, the burndown charts, the AI copilots, is optional, and most of it is overhead.

This post is about the lean version. Not project management theory, and not the enterprise suite. The specific question a software team actually has: what is the smallest tool that lets us plan and ship the work without the process becoming the work?

#What engineering project management actually requires

Strip it down and a software team needs four things from a tracker:

• A place to write down the work. Issues with a title, an owner, a priority, and enough description to act on. That is the atom.
• A workflow to move it through. Backlog to in progress to done, with a triage step for the stuff that arrives unsorted.
• A way to batch it. A sprint or cycle so "this two weeks" is a real, bounded thing and not an open-ended list.
• A shared view of state. So anyone, a teammate or an agent, can answer "what is the status of X" without a standup.

That is engineering project management for a software team. Notice what is not on the list: Gantt charts, resource-leveling, earned-value tracking, a roadmap timeline, velocity dashboards. Those belong to a different discipline, the capital-P Project Management that runs bridges and multi-year hardware programs. Bolting that machinery onto a software team is how a tracker turns into the thing everyone quietly avoids.

Radial ships exactly the four things above and stops there on purpose. Issues, a triage queue, board and list layouts, Cycles (time-boxed sprints), estimates, and projects to group related work. It does not ship burndown charts, velocity graphs, a roadmap timeline, or portfolio management, and that is a deliberate line, not a gap we are rushing to close.

#The overhead is the process, not the tool

The reason engineering project management gets a bad name is not the tracking. It is the ceremony that accretes around it. A workflow with eleven states. Required custom fields on every ticket. A weekly ritual of updating a status you already communicated in the pull request. The tool grew a feature, someone turned it on, and now it is a tax on every issue forever.

The fix is not a better dashboard. It is less surface area. The best engineering project management setup is the one your team forgets it is using, because filing an issue costs a keystroke and the status is obvious from the work itself. Speed matters here for a concrete reason: if the tracker is slow, people route around it, and a tracker people route around stops being the source of truth. Then you are back to reconstructing state from Slack and memory.

So the lean version has two properties. It is fast enough that using it is never the friction. And it does one thing, issue tracking, well enough that you do not need a second tool to compensate.

#Run the work from where you already are

For an engineering team, the highest-leverage property of a tracker is that it can be driven from the terminal, not just clicked through a web app. When the tracker has a real CLI, project management stops being a separate context you switch into and becomes something you script into the work you are already doing.

Every Radial command takes --json, so the same operations your team does by hand also run from a script, a CI job, or an agent:

# File an issue on the engineering team, high priority, from the terminal or CI
radial create "Investigate 500s on checkout" -t ENG -p high --json

# See exactly what is on your plate right now, as data you can pipe
radial list --assignee me --status "in progress" --json

Because --json is on everything, the tracker becomes programmable. A failing CI build can file its own issue. A pre-commit hook can check what is assigned to you. And your coding agent can do the same operations over MCP, because to the API there is no difference between you typing radial create and Claude Code calling the same endpoint. Every credential is a client of the API, not a billed seat, so your agents ride free. That is the shape of engineering project management that fits how software teams actually work in 2026: the human and the agent writing to one shared record, from the terminal, without a per-agent bill.

#The bill is part of the overhead too

There is a second kind of overhead that does not show up in the workflow: the invoice. Most trackers are per seat per month, and most now meter AI work on top of that, a credit allowance per seat, overage billing, a separate charge per agent. The number you sign up for is not the number you pay, and the gap grows exactly as your team leans into agents.

Radial is one number: $50 per user, per year, flat, billed annually, locked at the rate you join. No per-agent seats, no AI credits, no usage meter, because there is no AI in the product to meter. The part that makes it a commitment rather than a slogan is the Plain Software Pledge, written down: the day Radial ships a copilot, meters your usage, or charges you for AI you did not ask for, your subscription is free. This is not anti-AI. Your agent doing real work is great. The tracker is just not where that intelligence should live or get billed.

#Where this approach is honestly the wrong fit

A fair pitch names the edges. If your "engineering project management" actually means running a program office, resource-planning across fifty teams, reporting up a burndown to leadership, or managing a hardware project with a fixed-sequence Gantt schedule, a lean issue tracker is not that tool, and Radial is not pretending to be. Jira and the heavier Work OS platforms exist for that breadth, and if it is load-bearing for you, stay.

The lean version is for engineering-led teams that ship software and want the tracking to disappear into the work. If that is you, the overhead you have been tolerating was never the point of project management. It was just the tool getting in the way.

#FAQ

#What is engineering project management?

It is the practice of planning, tracking, and delivering engineering work. For a software team specifically, that means scoping work into issues, moving them through a workflow, batching them into sprints or cycles, and keeping a shared view of what is in progress, blocked, and shipped. Broader definitions from other engineering disciplines add scheduling, budgeting, and resource allocation for large technical programs, but a software team's version is narrower: it is issue tracking done well, not a program-management suite.

#What is the best project management tool for software development?

There is no single answer, because it depends on what you need. Teams that want maximum breadth and configurability tend toward Jira or Azure DevOps. Teams that want speed and a keyboard-first workflow lean toward focused trackers. Teams glued to their repository stay in GitHub Issues until a flat list stops scaling. The honest filter for an engineering team is: pick the fastest tool that does issue tracking well and resist the ones that make you adopt a whole planning methodology to file a ticket. If a scriptable CLI and agents that ride free matter to you, that narrows the field further.

#What are the phases of a software development project?

Most frameworks name six: initiation, planning, design, development, testing, and deployment or maintenance. The lifecycle is useful as a mental model, but from a tracker's point of view all six reduce to the same primitives: issues that carry the work, a workflow that reflects where each one is, and cycles that bound how much you take on at once. You do not need a tool with a "phase" feature. You need issues that move.

#Do engineers or project managers manage the work?

On lean software teams, increasingly the engineers do, directly, which is exactly why the tracker being fast and scriptable matters. When filing and updating issues costs a keystroke or a terminal command instead of a meeting, engineers keep the record current as a byproduct of doing the work. A dedicated PM role still adds value coordinating across teams and stakeholders, but the day-to-day tracking should not require one. The overhead-heavy setups are the ones that do.

#How do coding agents fit into engineering project management?

The same way a teammate does: they read and write the tracker. In Radial, an agent connects over the MCP server or the CLI and can file issues, triage the queue, update status, and close work, using the identical API surface a human uses. Because every credential is an API client rather than a billed seat, running agents against your tracker does not add a line to the invoice. That is the practical version of "the tracker is the shared system of record," a record both the human and the agent write to.

#The short version

Engineering project management is a small job wearing a big coat. The job is: write down the work, move it through a workflow, batch it into cycles, and keep one shared view of state. The coat is everything the tools pile on top, the dashboards, the ceremony, the AI meter on the invoice.

Radial is the lean version: a fast keyboard-first tracker, scriptable from the terminal, one flat locked $50 per user per year, and agents that ride free. See the one number on pricing, or read how the same CLI turns the tracker into something you script in the Linear CLI Linear never shipped.