Engineering barely starts at delivery. Managing a project from concept through retirement, the deliverables that actually matter at each phase, the difference between a hotfix and a release, what to anticipate and what to leave alone: this is what separates programs that finish from programs that linger.
The design review was on the calendar for Thursday, so on Thursday there was a design review. Slides were shown. Nobody could say which requirements the design met, because the requirements document was a draft with a dozen open comments, and nobody could say whether the power budget closed, because the power budget was a spreadsheet with two cells filled in. The review ended with the word “passed,” because the schedule said the design phase ended that week, and the project advanced into implementation carrying every question it had walked in with.
A project lifecycle is the sequence of phases a project moves through from concept to retirement. The names vary by industry, but the shape is the same: each phase has a purpose, a deliverable, and a gate that decides whether the project is ready to advance. The gate is only as honest as the deliverable in front of it. Without a written deliverable, “ready” becomes an opinion, and projects advance on schedule pressure rather than readiness.
Why the structure exists. Engineering work has dependencies that are indifferent to schedule pressure. You cannot meaningfully design a system whose requirements you have yet to pin down. You cannot meaningfully test a system you have yet to build. The phases are a recognition that earlier work has to settle before later work has anything to operate on. Skipping ahead creates rework later, when the missing earlier work is discovered to have been necessary after all.#
The mental model. Building a house. The architect cannot draw plans before knowing the lot, the budget, and what the family needs. The framers cannot frame before the foundation is poured. The electricians cannot wire before the framing is up. Compressing the schedule by starting trades in parallel produces a house that fails to fit together.#
Six phases, six gates. Each gate asks one question, and the phase before it exists to produce the answer.
Phase
The question the gate asks
Deliverables that answer it
Review
Concept
Is the problem real, is it physically feasible, and can we afford to solve it?
Project summary and concept of operations, feasibility shown by the four budgets, rough cost and schedule, the go or no-go recommendation
Concept review
Requirements
Do we agree on what done means, and can every statement be verified?
Requirements specification with a method per requirement, interface definitions at the breadth level, acceptance criteria, customer sign-off
System requirements review
Design
Will this design meet the requirements with margin, and is every major choice defensible?
Architecture, trade studies and decision records, interface control documents, risk register, budgets with margins
Preliminary design review
Implementation
Is the detailed design complete, and is the system coming up incrementally as planned?
Detailed design, source under configuration management, unit test results, incremental integration results
Critical design review
Verification
Is the evidence complete for every requirement?
Test plans and procedures, test reports, a traceability matrix with no open rows
Test readiness review, then acceptance
Delivery and support
Can the customer operate and maintain it without us in the room?
As-built documentation, manuals, training, support and release plan, lessons learned
Requirements, design decisions, interface contracts, test results: these must be captured, because the project cannot answer its own questions without them. Meeting notes and status emails are far less critical. Over-documenting the second group is how teams run out of time for the first.
A gate that cannot say no is a calendar entry.
Each gate asks one question, the phase before it produces the deliverable that answers it, and a gate without a deliverable is a date rather than a decision.
What it is. A code freeze is a deliberate stop on new feature development, after which only bug fixes are allowed into the build. The freeze creates a stable target for the integration, regression, and acceptance work that has to happen before the release ships.#
Why it exists. Software has the property that any change can break anything. A new feature added on Monday may produce a regression that surfaces in Friday’s system test. If features keep landing throughout verification, the team is verifying a moving target, and every test result is invalidated by the next change. The freeze creates a window where the build is stable enough that test results mean something.#
The trap. “Just one more feature” is the discipline-killer. Every feature that lands after the freeze restarts the verification clock for the parts of the system it touched. The team that allows three “small” post-freeze features has effectively had no freeze.#
Eight weeks out to release day. From the freeze onward, the only changes are bug fixes, and each one is approved by name.
The exact timeline varies by project, but the shape is recognizable. Each milestone exists because of a dependency: regression testing needs feature-complete code, system testing needs a stable build, the release candidate needs verified test results. Compressing the timeline leaves the milestones where they are and removes the verification time between them, and that verification is what made the release a release rather than a hope.
When
Milestone
What it means
T minus 8 weeks
Feature complete
All planned functionality implemented.
T minus 6 weeks
Code freeze
Only bug fixes land, and each one requires approval.
T minus 4 weeks
Integration testing complete
System-level tests passing on the frozen build.
T minus 2 weeks
Regression testing
Verify the bug fixes left everything else intact.
T minus 1 week
Release candidate
Final smoke tests, documentation review.
T
Release
Delivered to the customer. Deployment support begins.
On one program we ran two freezes, and the distinction turned out to matter more than the dates. The soft freeze was feature-complete: a build that worked on the hardware and in a trustworthy software-only environment, with recordings to prove it. That was the baseline every later cleanup and reorganization could be checked against, which made it the date that mattered. The hard freeze, after which only approved fixes landed, could move to give the test team enough verification time, and did. When the soft freeze passed with features still missing, the honest status went to management the same day: what was missing, why, and the plan to hold the delivery date anyway.
The same program had two codebases for a while, the team’s original and a from-scratch rewrite. I named them Track A and Track B, on purpose, because a name like “the old one” or “the broken one” would have cost me the people I needed to finish either of them.
The lesson. The freeze that matters is the one that produces a known-good baseline, because everything after it is measured against that baseline. And the names you give things during a hard stretch are engineering decisions too; neutral ones keep the team working.
A customer wants a new feature after the freeze? Document it, add it to the backlog for the next release, and keep the current release whole. One more thing is how a release becomes a slip.
Freeze features early enough that the test results mean something, approve every post-freeze fix by name, and treat the feature-complete baseline as the date that matters.
Every claim of the form “we tested this” depends on knowing what “this” refers to. Configuration management is the discipline that makes that knowable. Every artifact has a version. Every test result references the version it was run against. The system can answer, mechanically, without human memory, the question “which version of which component was tested with which version of which other component, on which date, by whom?”
When configuration management is absent, that answer is reconstructed from human memory and shared drives, which means it is approximate at best and wrong at worst. Tests run against builds that were since overwritten. Bug reports reference versions nobody can pin down anymore. Regressions take days to investigate that should take minutes.
Source control for everything that can change: code, configuration files, scripts, documentation, FPGA images, firmware. If it has a version, it lives in version control with a commit history. If it lives only on someone’s laptop, the project does not have it.#
Build artifacts produced by automated systems, never by an engineer’s laptop. The build system runs from a known commit hash and produces an artifact tagged with that hash. Builds are reproducible because they have to be: if you cannot rebuild last quarter’s release from source, you cannot debug last quarter’s bug.
Test records that name the artifact under test, by version. “We ran the regression suite against build 4.7.2 on this date, here are the results” is a record. “It worked when I tested it last week” is a memory.#
Release tagging that pins exactly which versions of which components shipped together. The next time a customer reports a bug, you can answer “here is exactly what you have, here is what we tested it with, here is what has changed since.” That answer is the difference between a tractable investigation and a multi-week archaeology project.
A new engineer onboarding to a project asked which version of the firmware was running on the test fixture. The answer came back from three different people: “the latest one I built last week,” “the December version, that is the stable one,” and “I think Mike has a build with the fix in it.” There was no canonical answer because there was no canonical anything. Builds lived on engineers’ laptops. Tests had been run against builds that had since been overwritten. The fixture had whatever was on it last time someone flashed it.
Two weeks later, a regression was reported by the customer. Reproducing it required figuring out which build the customer had, which build had been on the fixture during the last successful test, and what had changed between them. Nobody knew. The team spent four engineer-days reconstructing what should have been a one-line answer from the commit log.
The lesson. Configuration management is the precondition for every claim of the form “we tested this.” Without it, every test result is a story rather than a fact, and every regression is an investigation rather than a diff. The cost of the discipline is small and continuous. The cost of skipping it is large and lumpy, concentrated in the days when something has gone wrong and you cannot answer basic questions about what you shipped.
Every artifact has a version, every test record names the version it ran against, and a build that lives only on a laptop is a build the project does not have.
Why this distinction matters. Once a system is in production, every change is a risk. A change that fixes one bug can introduce three more, especially if the testing time is compressed by urgency. The right discipline is to match the rigor of the change to the risk of the situation. Critical security flaws warrant rushed deployment with minimal testing because the alternative is worse. Minor UI bugs do not.#
The trade. Speed and rigor are in tension. Faster deployment means less time for regression testing, which means more risk of introducing new problems. The discipline is to be honest about which trade you are making each time, and to reserve the fastest paths for the situations that require them. Calling everything an emergency drains the meaning out of the word; the next real emergency gets the same response as the last fake one.#
Kind
When
Timeline
Testing
Hotfix
A critical bug in production, a security vulnerability, the system down or data at risk.
Hours to days.
Minimal, focused on the fix and the paths it touches. The full regression follows in the next patch.
Patch
Non-critical bugs affecting users, performance problems, accumulated small fixes.
Weeks.
Regression testing required before release.
Update or release
New features, minor bug fixes, performance improvements, on the planned schedule.
Scheduled.
The full test cycle, including the freeze.
Match the rigor to the risk: hotfix in hours with minimal tests, patch in weeks with regression, release on schedule with the full cycle.
Customers rarely know everything they need, and a good engineer spots the unstated requirements and addresses them before the field does. The spec says X; what they actually need is X plus the four things that happen when X meets reality. This is validation thinking applied early, and it is the reason the project summary is written from the customer’s point of view.
Example: a data logger request
Customer says: “We need to log sensor data to a file.”#
What happens when the disk fills up? Rotate logs, alert the operator.
How are logs retrieved? USB export, network transfer.
What if power fails during logging? Flush buffers, resume on reboot.
Can they search or filter? Timestamps, event types.
How long is data kept? Retention policy, compression.
Result: raise these as requirements now, and the customer gets a logger that survives its first month in service.#
The line to hold is between anticipating a need and inventing one. Each item above is something the customer will hit in the first month and would have asked for had anyone prompted. A need the customer has yet to feel, at a scale the customer has yet to reach, is principle 1.8 territory: write it down, and build it when it is real.
Anticipate what the customer will hit in the first month; leave what might land in year three on the list until it is real.
A specific failure mode is worth naming because it is recognizable to anyone who has been on a slipping project. The customer originally asked for a prototype, a demonstration of the concept, with the expectation that real engineering would follow. The project ran long. The customer waited. By the time something is ready to show, the customer’s patience for a “just a demo” deliverable is gone, and what the customer wants now is a working system. The word in use is still MVP, because that is the word the contract uses, but its definition has quietly migrated from “proves the concept” to “does the job.”
This is the customer naming the new reality rather than being unreasonable. The team, meanwhile, is still building toward the original definition. Both parties think they are aligned because they are using the same word. Neither has noticed the word now means different things.
Surface the change explicitly. “We agreed on a prototype. The slip means you now want production. Here is what production-grade actually costs, and here is the timeline if we shift to that goal. If we keep the original goal, here is what the prototype will and will not do.” That conversation is hard. The alternative is harder: the team delivering a prototype to a customer who expects production, and discovering the misalignment at acceptance.
The dishonest version is what most teams do under pressure: hide the cost of the slip inside the price of the next change order. The honest move costs less in the long run because it preserves the relationship. The dishonest move buys budget at the cost of trust, and trust compounds. The test of whether you are managing a customer relationship honestly is whether you can describe the project’s true state without losing the contract. If you cannot, you have already lost something more important than the contract.
When a slip turns a prototype into an expectation of production, say so out loud and reprice the goal, because hiding it in the next change order spends trust you will need later.
Engineering decisions are business decisions. Custom hardware versus COTS, development time versus recurring cost, time spent on craft versus time spent on shipping: these affect ROI, time-to-market, profitability, and whether the project gets funded for a second round. The break-even arithmetic for build-or-buy lives in the Design chapter; the principle underneath it lives here.
The deeper version is worth stating explicitly because most engineers resist it: every engineering hour has a cost, and a senior engineer’s job is partly recognizing which activities deliver value to the scope and which are ceremony. Non-recurring engineering is what you spend on the design, prototyping, testing, and documentation work that produces the product. It is finite, it is paid for, and it is one of the largest line items on most projects.
The question to ask of every engineering activity is the same: what is this hour buying for the project? If the answer is “I do not know” or “it is the right way to do it,” that is a flag. The right way to do it is the way that delivers the most value per hour against the actual scope, rather than the way that scores highest on craft.
Software engineers in particular resist this framing because they are trained to optimize for craft, but craft without budget awareness is just well-rendered overrun. An hour spent arguing over a C++ idiom that the latest online debate settled differently than yesterday is an hour that never shipped the thing. Craft compounds, and a team that never invests in it produces fragile work; the point is that craft has to be balanced against the budget that pays for it, with explicit awareness of what the trade actually buys.
One specific place this matters: code reviews. A peer review by someone who understands the problem domain is worth several thousand dollars per review. He or she can ask the questions a linter cannot, surface the bug a static analyzer would never catch, and shape the design before it becomes infrastructure. A peer review by someone who lacks the domain context costs the same per hour and returns almost nothing, because without that context the review collapses to syntax checking and style preferences, which the linter already does for free.
A senior engineer review-merged a pull request in three minutes. The comments were all about formatting: a tab versus four spaces, a function name that should have been camelCase, a brace style preference. Solid review hygiene by the C++ standard. The code in question was a sensor driver that handled the nominal case and crashed on NaN inputs at the operating temperature extreme. Six weeks later, the field unit returned NaN, and the team spent two days reproducing the failure before someone noticed the function had no defensive check for non-finite values.
The lesson. The reviewer had skill and lacked the domain context to know that this particular sensor returns NaN at -40 C. Without that context, the review collapsed to the only thing the reviewer could evaluate: style. A review that only surfaces formatting is a process to fix rather than a victory to celebrate.
The remedy is reviewers who can see the actual risk, rather than more reviewers: pairing junior engineers with seniors who know the domain, rotating reviewers to spread that knowledge, and declining to merge work that has yet to be reviewed by someone who can evaluate it on the dimensions that matter. The same goes for review rules that measure the wrong thing. I once had a change rejected for being too long, by a team that wanted very small pull requests. The change did the assigned job and carried the write-up that would let anyone on the team learn the approach. Splitting it would have satisfied the rule and taught nobody anything.
The job is to deliver value to the customer at acceptable cost and risk, and the most elegant solution is sometimes that and sometimes a detour. Sometimes that means boring COTS components. Sometimes it means custom engineering. Sometimes it means letting the senior engineer’s favorite refactor wait until it actually buys the project something. ROI drives the decision.
Ask what each hour buys the project, and put reviews in front of people who know the domain, because a review that catches only style is an expensive linter.
Every principle in this guide assumes one thing that is rarely true: that the engineer applying it has support from the layer above. Engineering rigor without management air cover gets ground down to the same patterns the team had before, just with more frustration on the engineer’s side. Rigor with management protection actually changes things. Both are required.
The principle is a specific named role. Management’s job in a healthy engineering culture is running interference for the work, more than directing it. The manager who protects time for a trade study, defends the dev-hardware budget against “we do not need it anymore,” and lets the team push back on a senior engineer’s inherited-from-the-last-project pattern is doing the high-leverage work of the role. The manager who treats the job as schedule policing and ceremony enforcement is doing none of it.
Most of the failures named in this guide look engineering-shaped on the surface and are management-shaped underneath. The team that drops dev-hardware support once final hardware arrives is making a management cost decision driven by a wrong mental model of where bugs get found. The team without configuration management is living with a resourcing failure dressed up as an oversight. The team running peer reviews that only catch syntax issues is missing the management investment in domain-deep reviewers.
The pattern repeats. A discipline costs engineer time. The cost shows up on someone’s budget. Schedule pressure mounts. The discipline gets eroded. The resulting failures look like engineering bugs. The engineer is blamed for the symptom. The actual decision was upstream.
A specific version of this misalignment is nearly universal. Work expands to fill the process built around it. A team with a heavy ticket-tracking system, sprint planning, story-pointing, retro ceremonies, backlog grooming meetings, will produce work at the rate that fills those structures, rather than at the rate the structures were designed to enable. The structures were sold as productivity tools. They become the work.
The fix is neither “more agile” nor “less agile.” It is recognizing that process has a cost, the cost shows up in engineer-hours, and a team that spends 30% of its time on process ceremony is producing 70% of the work it could be producing. Whether that is a good trade depends on what the process actually buys. Sometimes it buys real coordination value. Sometimes it buys the appearance of management. The discipline is to measure rather than assume.
If you are an engineer reading this without management air cover, the principles still apply, but applying them requires a different skill: making the cost case explicitly, with numbers, in language management can act on. “We need to keep the dev hardware support” is a request management can decline under budget pressure. “Dropping the dev hardware will cost us approximately X engineer-days per regression we hunt on production silicon, based on Y regressions per quarter from previous projects” is a request management can only decline by owning the math.
The engineers who succeed in misaligned environments do this work explicitly. They translate engineering discipline into business cost. They make the invisible cost of skipping a discipline visible enough that the math is on the record before the decision is made. Being right is the start. Being right in a form management can use is the job.
Engineering rigor is necessary. Management air cover is necessary. Either one alone is insufficient. The healthiest engineering cultures have both, structured so that neither has to fight the other to do its job. If you find yourself fighting your management to be allowed to apply basic discipline, that is a flag about an alignment problem upstream of both of you, one that needs to be named and addressed.
Rigor needs air cover and air cover needs rigor; when you lack the cover, put the cost of skipping the discipline in numbers management can only decline by owning.
Every project has mistakes and successes, and the only way either one improves the next project is if someone writes them down while they are fresh. “We should have…” is a sentence worth nothing in a hallway and a great deal in a document that gets read at the next kickoff.
The review asks three questions. What went well, and how do we repeat it: which processes worked smoothly, which decisions paid off, which tools and methods were effective. What went wrong, and how do we prevent it: what caused delays or rework, which assumptions were wrong, what we would do differently. What changes, concretely: the templates and checklists to update, the entries to add to the risk register for similar projects, the brown-bag session to share it with the team.
Then the one habit that makes the whole exercise worthwhile: read the lessons from the last project before kicking off the next one. A lessons-learned document that nobody opens is a diary.
Write the lessons while they are fresh, and read them at the next kickoff, or you have kept a diary.
The sentinel’s project summary ended with a proposal rather than a schedule: a three-month, cost-plus research phase, because the power question had no honest answer yet. In lifecycle terms, that research phase is the concept phase, and the gate at the end of it asks the concept question in its purest form: is this physically feasible, and can the customer afford it?
The three questions the research phase was funded to answer, each traced to a requirement:
Can a node listen for a season and still relay, on a battery cheap enough to leave behind? Answered by the power budget with its two guessed lines replaced by 72 hours of measured current from real nodes, with and without relay traffic.
Does the link close under wet canopy, and at which band? Answered by walking the link on real trees with the gateway on a pole, both bands, wet and dry, so the excess-loss row in the link budget is a measurement.
Can the detector hold the false-alert rate the rangers will tolerate? Answered by three nodes running a month in the preserve with every alert checked against the log.
The deliverables at the gate. The measured power budget. The measured link budget for both bands, which also closes the question the radio trade study left open. The detector trial data. An updated project summary written from what was learned rather than what was hoped. A firm estimate for the build, in the form Leading describes, and a recommendation.#
The three outcomes, all of them successes.Go: the numbers close with margin, and the build starts on an estimate that rests on measurements. Go with changes: the numbers close only with a lever pulled, the lower band, a small solar top-up, a slower heartbeat, and the summary and requirements are revised before the build starts rather than after. No-go: the physics says a season on a disposable battery is out of reach at this cost, and the customer has spent research money instead of build money to learn it. The gate exists so that the third outcome is a finding rather than a failure.#
Notice what the research phase did to the schedule. It added three months before the build and removed the possibility of eighteen months building the wrong node. That is the trade every concept gate offers, and the teams that skip the gate take the other side of it without noticing.
Write the question your next gate has to answer, in one sentence, and list the deliverables that would answer it. Check whether the deliverables on your schedule are those ones.
Pick one test result your team has relied on this month and find the build hash it ran against. If it takes more than five minutes, that is your configuration-management gap.
Take one discipline that is being eroded under schedule pressure and write the cost case in numbers: engineer-days per incident, incidents per quarter. Put it in front of the person who owns the budget.
The sentinel’s first gate trades three months of measuring for the chance of eighteen months building the wrong node, and all three outcomes count as success.
This chapter on one page
Each line is the sentence to remember from its section. The number takes you back to it.
8.1Each gate asks one question, the phase before it produces the deliverable that answers it, and a gate without a deliverable is a date rather than a decision.
8.2Freeze features early enough that the test results mean something, approve every post-freeze fix by name, and treat the feature-complete baseline as the date that matters.
8.3Every artifact has a version, every test record names the version it ran against, and a build that lives only on a laptop is a build the project does not have.
8.4Match the rigor to the risk: hotfix in hours with minimal tests, patch in weeks with regression, release on schedule with the full cycle.
8.5Anticipate what the customer will hit in the first month; leave what might land in year three on the list until it is real.
8.6When a slip turns a prototype into an expectation of production, say so out loud and reprice the goal, because hiding it in the next change order spends trust you will need later.
8.7Ask what each hour buys the project, and put reviews in front of people who know the domain, because a review that catches only style is an expensive linter.
8.8Rigor needs air cover and air cover needs rigor; when you lack the cover, put the cost of skipping the discipline in numbers management can only decline by owning.
8.9Write the lessons while they are fresh, and read them at the next kickoff, or you have kept a diary.
8.10The sentinel’s first gate trades three months of measuring for the chance of eighteen months building the wrong node, and all three outcomes count as success.