Project Management for Software Teams: Beyond Process Theatre

Most engineers we talk to have had at least one bad PM experience. The PM who scheduled a daily standup, two grooming meetings, a sprint planning, a retro, a “demo prep,” and a “demo demo prep,” and then asked at the end of the sprint why velocity was down. The PM who turned Jira tickets into novel-length specs that no engineer read. The PM who, when asked a technical question, said “I’ll bring that up with engineering” — about their own project.

This is process theatre, and it’s why engineers think project managers are useless. But that’s not what a software PM is supposed to do. A real software PM removes obstacles, owns scope, and protects the team’s focus. Done well, a PM compounds the output of every engineer they work with. Done poorly, they actively reduce it.

Here’s how we think about it.

When engineers should manage themselves

Not every team needs a dedicated PM. Some teams are better off without one.

A team can manage itself when:

• It’s 2-4 senior engineers who’ve shipped together before.
• The product owner (CTO, founder, or PM-elsewhere) is engaged daily.
• Scope is well-defined: a known feature, a clear migration, a contained refactor.
• The stakeholder surface area is small (1-2 people).

In this configuration, adding a PM creates friction. The engineers already know what to build. They don’t need someone reminding them to update Jira. The CTO can do the planning conversation directly.

A team needs a PM when any of these are true:

• 5+ engineers, especially when they’re not co-located in the same timezone.
• Multiple stakeholders pulling in different directions (sales asking for X, support escalating Y, founder pushing Z).
• Cross-team dependencies (frontend waiting on backend, mobile blocked on API).
• Regulatory or contractual deadlines (compliance, customer commitments, audit cycles).
• A roadmap that spans more than one quarter, where someone needs to own the sequencing.

Headcount alone isn’t the signal. A 4-person team in a regulated industry with 5 stakeholders absolutely needs a PM. An 8-person team building a single product with one engaged founder might not.

What a software PM actually owns

The job is specific. We use this list when we scope a PM engagement:

1. Scope definition and protection. The PM is the person who says no. Or more precisely: the person who surfaces a trade-off when a new request lands mid-sprint. “We can do that, but it pushes feature X to next sprint. Which do you want?” That conversation is the job.

2. Sprint / cycle planning. Whatever cadence you use, someone has to break the work into small enough pieces that they’re estimable, sequenced so dependencies are respected, and right-sized so the team has 70-80% commitment with 20-30% buffer.

3. Risk surfacing. A junior PM tells you what happened. A senior PM tells you what’s about to break. Risks are: the dependency we’re blocked on, the engineer who’s out next week, the third-party API that’s been flaky, the customer commitment we’re going to miss.

4. Stakeholder communication. The weekly status update, the demo, the “we’re tracking behind, here’s what we’re doing about it” email. This isn’t note-taking; it’s translation between engineering reality and business expectation.

5. Dependency management. Cross-team coordination. Vendor coordination. Procurement and licensing. The boring work that gets dropped without a PM.

6. Reporting and metrics. The numbers that matter: cycle time, escape rate, on-call burden, deploy frequency. Not “story points completed.” Story points are not a metric, they’re an estimation aid.

A PM who is doing only updating Jira and running standups is not a PM. They’re a coordinator. There’s nothing wrong with a coordinator — but if you’re paying senior PM rates, you should expect the six items above.

Methodology choice: Scrum vs Kanban vs Shape Up

There’s no universally right methodology. There is a right methodology for a given context. Here’s how we choose.

Scrum

Best for: predictable feature work with external stakeholders. Sales wants to know when a feature ships. The customer signed a contract with a deliverable list. There’s a quarterly board update.

Scrum’s strength is the ritual structure: every two weeks you commit, every two weeks you demo, every two weeks you retro. That cadence creates predictability. The customers and stakeholders see a heartbeat.

Scrum’s weakness is when you over-apply the rituals. If your daily standup runs 45 minutes for 6 people, you’re doing it wrong. If your retros are blame-fests, you’re doing it wrong. The rituals are scaffolding, not the building.

Our default for Scrum teams: 2-week sprints, 15-min standup max, planning capped at 90 min, demo + retro on Friday combined (45 min each, hard stop).

Kanban

Best for: support, ops, security response, and anything reactive. When work arrives unpredictably and you need to flow it through, sprint commitments are a fiction. You over-commit, then carry over, then over-commit again.

Kanban replaces the time-box with WIP limits and flow metrics. The team agrees on the maximum work-in-progress per state (backlog → in-progress → review → done). When you hit the limit, you can’t start new work; you have to unblock the existing.

Kanban works for product teams too, especially mature ones who don’t need the heartbeat of a sprint demo. Many of our most senior teams run a continuous Kanban with a monthly review instead of a bi-weekly sprint.

Shape Up

Best for: product-led companies with engaged design and engineering leadership. Shape Up is Basecamp’s method: 6-week cycles of meaningful work, 2-week cooldown, no daily standups, hill charts instead of burndowns.

Shape Up’s premise: the unit of meaningful product work is 6 weeks, not 2. Two weeks is enough to deliver a feature but not enough to ship something users notice. Six weeks is enough to ship something that moves the metric.

We use Shape Up for clients building consumer or product-led SaaS where the team has senior engineers and a strong design culture. We do not use it for B2B teams with heavy customer commitments — the 6-week cycles don’t map to sales cadences.

The matrix

Context	Use
Customer commitments, external timelines	Scrum
Reactive / support / ops	Kanban
Product-led, senior team, design-driven	Shape Up
Mixed product + support team	Scrum for product, Kanban for support, separate boards

The most common mistake we see: applying Scrum to a support team. The team feels lied to every sprint because half the planned work gets bumped by tickets. Switch to Kanban. The world gets quieter.

The weekly cadence that actually ships

For a Scrum-flavored team, here’s the cadence we recommend:

• Monday — Planning (60-90 min). Review the backlog, commit to the sprint scope, identify dependencies and risks.
• Tue-Thu — Standups (15 min, async if possible). What I did, what I’m doing, what’s blocking me. Anything that needs a real conversation moves to a follow-up call.
• Friday — Demo + Retro (60-90 min combined). Show what shipped (5-10 min per item). Then 20 min retro: what went well, what didn’t, one experiment for next sprint.

Notes:

• Standups don’t need to be live. Async standups in Slack are fine for senior teams, especially across timezones.
• Retros without actions are just gripe sessions. Every retro must end with one specific change for next sprint.
• Demos are for the team and stakeholders, not for the PM. If you demo only to the PM, kill it.

For Kanban teams, replace the sprint planning with a weekly triage (30 min) and the demo with a monthly review. Standups become “WIP review” — quick check of what’s stuck and what needs attention.

Anti-patterns to avoid

The PM as gatekeeper. Engineers can’t talk to product without going through the PM. This is poison. The PM should be a connector, not a wall.

The PM as note-taker. If your PM’s main output is meeting notes, you’ve miscast the role. Hire a coordinator at half the cost.

The PM as Jira janitor. Updating tickets is the responsibility of the engineer doing the work, not the PM. If you’ve delegated this to the PM, your engineers don’t actually own their work.

Story point inflation. When velocity becomes a performance metric, points inflate. Velocity goes up. Output stays flat. Then the team hates the system. Stop measuring velocity. Measure cycle time and deploy frequency.

Sprint extension. “We didn’t finish so we’re extending the sprint by 3 days.” No. Roll the unfinished work to the next sprint and figure out why the estimate was wrong. The sprint timebox is sacred.

The PM who doesn’t understand the technical work. A PM who can’t read a system diagram or follow a technical conversation will be steamrolled by engineers (rightly) and bullied by stakeholders. We don’t place PMs without technical background.

What a Softronic PM engagement looks like

Our PM engagements typically run as monthly retainers because project management is continuous work, not project work.

A standard PM retainer at $2,000/mo includes:

• A dedicated senior PM (5+ years, technical background, English-fluent, US/LatAm timezone overlap).
• Up to 25 hours/week on your team.
• Full Scrum / Kanban / Shape Up facilitation as appropriate.
• Weekly stakeholder reports.
• Risk register maintained continuously.
• Tool setup if needed: Linear, Jira, GitHub Projects, ClickUp — we have opinions but we adapt to your stack.

For higher-touch engagements (multi-team coordination, regulated workloads, dedicated 40 hr/week PM), retainers scale from there.

Bottom line

A good PM is the highest-leverage hire on a software team after the senior engineers themselves. A bad PM is a tax on every engineer they touch. The difference is whether they’re doing the six things in the list above or just running meetings.

If your team is shipping slower than the engineers’ actual capacity suggests, the bottleneck is usually not engineering. It’s coordination, prioritization, and scope. That’s PM work.

We can match a senior PM to your team in 10-14 days. Discovery call is free.