S.P.E.C
Cheap code raises the premium on system understanding.
Managing a software engineering team in the era of agentic coding is a prime opportunity to re-think how we operate. Agile, Shape Up and the like were all designed before agentic coding was popular. These traditional frameworks put a lot of emphasis on execution as the target, but this was a time when full feature-sets took weeks to build by hand. Now that developers are armed with AI coding tools, execution has become much cheaper. We can shoe-horn AI coding into these frameworks, however in doing so we create a new, very expensive problem - you can execute a task from A to B quite easily and have no f*cking clue how it works. This is very risky for a software team, as you have now effectively coupled domain-knowledge of the system to an LLM-providers API uptime. Alternatively, we can develop a new workflow strategy to empower engineers to level-up in the critical skills that will keep them in a job: deep system understanding, clear sense of ownership, plenty of contributions, and a sustainable working pace without pressure towards burnout.
I call this approach S.P.E.C - Simultaneous Project Execution Cycles.
An asynchronous, agentic-first, human-critical approach to collaborative software development.
What S.P.E.C Delivers
- Job security for experienced and emerging software engineers.
- Controlled scope, ample focus time and sustainable pace.
- Asynchronous & remote-friendly contributions.
- Deep system knowledge and understanding shared across the team.
- Wrangled chaos of agentic development by involving humans deeply where it counts.
- A continuously expanding knowledge base of software system design and reasoning history.
- Multiple new features for customers each cycle and perpetual improvement of existing system functions.
Cycles
I believe a cyclical approach is a good pattern to steal from other methodologies. Life is cyclical, it’s rhythmic, it helps us define a pace at which to work and maintain momentum. As for how long the cycle is, that’s up to the team to decide. You may start with a 5-week cycle while you warm up and get comfortable in the workflow, but depending on team flow and how quickly the process runs considering the assistance of tooling and coding agents, we might see much more rapid cycle times. Ideally it’s long enough to actually make good progress on work, yet short enough to remain nimble and get team health-checks (retrospectives) frequently.
Spec Phase
We start with the Spec Phase, where it’s essentially all hands on research, design and refinement. Each member of the squad takes on either a full end-to-end feature slice, or a set of enhancements/improvements. For the sake of argument, see if you can split it 50/50 between the team. In a team of four contributors, two of them are on feature work, two of them are on enhancements; this has a nice benefit of consistent new additions, as well as constantly updating and improving the system, burning down debt and maintaining momentum towards a “perfect” state of a system.
Each individual owns the production of one SPEC.md document for their project or enhancements. Ideally the first draft of a spec sheet is done in a day or two; then we submit our specs into a shared filesystem and parallel review them as a team. We build understanding of the plan & reasoning, and raise any questions or concerns for each of the specs. SPEC.md can include a decision log to track the evolution of Q&A for asyncronous reference and historical record.
What goes in SPEC.md?
The spec sheet is the source of truth for a unit of work. It’s an opportunity to capture product & design reasoning, technical planning and QA expectations. A SPEC.md document could potentially go through a pipeline of contributors even - perhaps a PM creates the beginning of a spec sheet, outlining the customer problem, the product thinking behind possible and chosen solutions, definition of one or many user stories, etc. Then, if there is desire to involve QA early in the process, perhaps SPEC.md is passed to QA to define some expectations for the solution. That would set the stage for the engineer to have a clear view into why this work should be done, and guidance on what the end result should be capable of. They then fill out the engineering implementation portion of the spec, ensuring alignment throughout the document.
Dependency management
Generally the goal for specs should be separate units of work that can be executed in parallel, dependencies between projects or enhancements should be identified and separated into sequential cycles to prevent blocking work-streams.
Escape Hatches
We need an evac!
At any point during the spec design or build phase, it’s not uncommon to uncover blockers or show-stopper information. We need to include a safety mechanism in here to be able to document our findings and pull the eject ripcord to reorient on a more suitable focus. Sending an agent down a rabbit-hole that leads nowhere is a waste of time and tokens. How this is enabled in practice, I’m not sure yet, but it is something to be aware of when piloting the approach to understand how you can insulate yourselves from dead-ends and misplaced focus.
Cross-functional Integration
How do we involve Designers and DevOps? Given we are centralising a “source of truth” for each feature & enhancement, buy-in from other functions within the organisation is neccessary. Designer input early during the spec design, devops awareness on the infrastructure dependencies defined towards the end of spec design - we could likely design a pipeline of spec design phases to ensure it crosses the hands of those that need input at the right times.
Onboarding
Another important aspect to consider is how we introduce new talent into the process. Part of me fears that throwing them in the deep end with their own ownership over a SPEC.md may risk drowning them a little. For this I think theres a handful of approaches to support newcomers:
- Buddy system - maybe we pair them up with an experienced team member to shadow/apprentice on the process, so they can see how we are getting work through discovery, design, implementation and testing.
- Appetite-based scoping of
SPEC.md, ensuring that their focuses are within their capability, whilst being challenging enough to get them exploring the codebase and building familiarity.
Build Phase
Each team member takes their refined and approved SPEC.md and owns the implementation of it. We delegate to our coding agent of choice with instruction to carry out building the spec in a stacked PR approach. The agent can be instructed to use correct JIRA ticket numbers, commit conventions, stacking strategies and automatic PR creation w/ succinct, detailed descriptions - automating away as much of the project-management process as we can to ensure external visibility on team progress is accurate. Each project or enhancement set produces a handful of stacked PRs, in order of merging/dependency, across one or many repos. Stacked PR workflows are not a new workflow, but with the advent of AI-generated code and the increase in code volume, it looks like the industry is addressing this with more first-class support of stacking workflows. There’s a lot of tooling on offer for stacking workflows, so we should make our lives easier by using them.
Review Phase
Once features have been implemented, once again the team goes into a rotational review phase for 1-2 weeks, this time on the executed work and code-diffs. Reviewing the stacked PRs bottom to top, we want to ensure the humans in the loop are intimately aware of what has been built and how it was built. The key here is to encourage understanding of the domain - this is how we stay valuable, we ensure deep knowledge of our systems so we can react quickly to problems and build additions with confidence. Once the review rotation has been completed, authors (or their agents) correct any issues necessary, track any debt tasks and after one more sense check, merge down their features into main.
QA and Cleanup
In the final week, all features, enhancements and improvements go through their QA and testing process, any issues are highlighted and raised with feature owners. Issues are either actioned or prioritised in the backlog. During cleanup week, the team should be grooming the backlog for any newly added tasks, team leads and product managers should be working out what units of work need to come through next, and the team should close out the cycle with some health-checks and win-celebrations.
Where Product Management Fits In
The traditional Product Manager and Tech Lead roles still have a home in this mode of operation. They should be cooperating to set the stage on what the engineers can choose from during Spec Phase. Ideally there should be a bucket of prioritised features/needs & improvements available to pick from at the start of each S.P.E.C cycle. I think a bit of flexibility here is good so engineers have the freedom of choice, whilst still ensuring we are aligned towards progress on a north star. PMs need to be close to the customers, relaying their current needs and their experiences of our products to the team, the Tech Lead is responsible for filtering out what can be done soon, versus what needs further cooking or cooperation between teams before staging for implementation. The QA and Cleanup week is a good opportunity for the PM and TL to ensure we have work ready for the next cycle.
As far as optimising team effort, of course some metrics are good to monitor across project cycles. This could be lead time, rework rate after merge, incident rate in touched areas, and especially % of team who can explain a change.
Potential Pitfalls
No solution is perfect, and this approach is still vulnerable to a few cut corners or behavioural issues that could erode its effectiveness.
LGTM
This strategy depends - somewhat naturally - on honest participation from each team member. The whole point is to foster thorough understanding of the system in each team member, this requires us to really read and process the specs and PR stacks being produced. We could just shrug off with a “LGTM”, but this would be actively undermining the purpose of S.P.E.C.
So perhaps some type of team contract is required to align on our expectations for each other, so we can operate effectively while respecting each other’s time.
Direction
As with any other methodology, if the team does not have a good path defined ahead of them, our efforts will be somewhat aimless and lacking in tangible value to the end user. There’s always plenty of tasks an engineer would love to work on, for their own satisfaction, but in order to maintain PMF and satisfied customers, we have to be building stuff that aligns with their needs and the direction of our company. This is really on the PM and TL to keep tidy.
Bottlenecks
Any process with a “review phase” will have a natural bottleneck on the reviews actually getting done. This methodology does acknowledge that plans and reviews will be the time consuming work, code execution is cheap and fast. This is why SPEC.md development and review gets a whole week dedicated to it, and why the review phase gets 1-2 weeks. It’s a known and expected “slow” part of the process, because I think it deserves to be slow, the planning and reviewing phases are where the engineers really extract all the value out of the S.P.E.C approach.
Hot Paths
Naturally fires pop up mid-cycle, urgent priorities come through, we might need to pivot on our focus to address burning requirements. These sorts of tasks can sidestep the typical cycle and be produced ad-hoc, but we need to be conscious of not letting “urgent work” disrupt our cadence and momentum excessively. Again the PM and TL can aim to insulate the team from these impacts, ensuring everyone’s time and focus is being respected.
Staying Relevant in the Agentic Era
As more people are empowered to use agentic coding tools, the traditional “software engineer” role often suffers some fear around displacement and obsolescence. Non-technical founders and entrepreneurs swear they will be vibing all their future software startups, but I firmly believe that the devil is in the details. As the production of code becomes cheap and fast, it’s not execution that makes a software engineer valuable, it’s the ability to intimately understand a system and its moving pieces. When we understand systems, we are efficient at working on them, fixing them and improving them and we maintain our ability to put out fires when the Anthropic API is down. This requires that traditional “techy” mind, familiar with software design patterns, trade-offs and translation of business needs into appropriate software solutions, that is where the meatbags can shine.
Making a Bulletproof Process
With SPEC.md being essentially the gospel of product, design, engineering, devops and QA thinking, I do think it would pay to build tooling around the lifecycle management of the document. We don’t want to regress to manually passing around a text document between many hands, trying to manage version history and decision logging - this will introduce significant friction in our workflow and potentially open up the door for missed details, lost documents etc.
To support this “methodology” write-up, I’d love to chase it with a proof of concept around tooling that software teams can use to ensure success with S.P.E.C. This might look like a set of Agent Skills, or some form of custom rolled application, whatever form it takes, ideally it should integrate with existing tooling that is deeply integrated with our business (Figma, JIRA, Coding Harnesses, Github).
Cross-functional spec intake
sequenceDiagram
actor PM
actor TL
actor Designer
actor QA
participant Confluence
participant Jira
participant Figma
participant Teams
PM->>Confluence: Create SPEC page from template<br/>(Problem, User Stories, Success Metrics)
Confluence->>Jira: Auto-create Epic<br/>(Atlassian Automation)
Confluence->>Teams: "SPEC-042 draft, needs TL review"
Teams-->>TL: Notification
TL->>Confluence: Review feasibility, scope & dependencies
Confluence->>Teams: "SPEC-042 ready for design"
Teams-->>Designer: Notification
Designer->>Figma: Create flows & mockups
Designer->>Confluence: Add Figma embeds +<br/>design rationale
Confluence->>Teams: "SPEC-042 design complete"
par TL technical review
TL->>Confluence: Review design for fit, risks & constraints
and QA expectations
QA->>Confluence: Add acceptance criteria &<br/>test expectations
end
TL->>Confluence: Approve technical staging<br/>for implementation
Confluence->>Jira: Transition Epic → Ready for Engineering
Confluence->>Teams: "SPEC-042 ready for engineering"
Engineering handoff & technical plan
sequenceDiagram
actor Engineer
participant Claude Code
participant Confluence
participant GitHub
participant Teams
Teams-->>Engineer: Notification
Engineer->>Claude Code: spec pull SPEC-042
Claude Code->>Confluence: Fetch page via MCP
Confluence-->>Claude Code: Page content
Claude Code->>GitHub: Write SPEC-042.md to repo
Engineer->>GitHub: Add technical implementation plan
Engineer->>GitHub: Open PR for SPEC.md review
GitHub->>Teams: "SPEC-042 plan ready for review"
Engineer->>GitHub: Team reviews & approves
Engineer->>GitHub: Merge SPEC.md
Build phase
sequenceDiagram
actor Engineer
participant Claude Code
participant GitHub
participant Jira
participant Teams
Engineer->>Claude Code: spec build SPEC-042
loop For each implementation slice
Claude Code->>GitHub: Create stacked PR<br/>(with Jira ticket refs)
GitHub->>Jira: Link PR to Epic
end
GitHub->>Teams: "SPEC-042 has 4 stacked PRs<br/>ready for review"
Review phase
sequenceDiagram
actor Engineer
participant Claude Code
participant GitHub
participant Teams
GitHub->>Teams: "SPEC-042 PRs ready for review"
Engineer->>GitHub: Review stacked PRs bottom-to-top
loop Fixes needed
Engineer->>Claude Code: Address review feedback
Claude Code->>GitHub: Push fixes
end
Engineer->>GitHub: Approve & merge PR stack
QA & cleanup
sequenceDiagram
actor QA
actor Engineer
participant GitHub
participant Jira
participant Claude Code
participant Confluence
participant Teams
GitHub->>Jira: Transition Epic → QA
Jira->>Teams: "SPEC-042 merged, ready for QA"
Teams-->>QA: Notification
QA->>GitHub: Test against acceptance criteria
alt Issues found
QA->>Jira: Create bug tickets
Jira->>Teams: "SPEC-042 QA issues raised"
Engineer->>Claude Code: Fix issues
Claude Code->>GitHub: Push fixes
else All clear
QA->>Jira: Transition Epic → Done
Jira->>Teams: "SPEC-042 complete"
end
Jira->>Confluence: Final status synced to SPEC page Return