What a life cycle even is, and why yours is implicit
Nobody at your company wrote down how work becomes software. It happened anyway, by accumulation, and the parts nobody chose are the parts that fail first under speed.
Ask five people on the same team to describe how a piece of work becomes shipped software. Do it separately, on a call, and write down what they say.
You will get five different answers, and the differences will not be about detail. They will be about structure. One person’s account starts at the ticket. Another starts three weeks earlier at the conversation that produced the ticket. One includes a design review that two of the others have never attended. One describes an approval step that was removed last year and that they still perform out of habit. Nobody mentions the staging soak, and the staging soak is where things actually get caught.
This is not a sign of a dysfunctional team. It is the normal condition. Almost nobody has a written life cycle, and the ones who do have a written one that describes a process nobody follows, which is arguably worse because it stops people from looking.
The point of this piece is not that you should write yours down, though you probably should. It is that the parts of your life cycle you never chose are the parts most likely to fail when the work rate goes up, and they fail without anyone recognising the failure as structural.
What a life cycle actually is
Strip the term of its heritage and it means one thing: the sequence of state changes a piece of work goes through between somebody wanting something and that thing being real, plus the rules for moving between the states.
That is it. Waterfall was one answer. Agile was a family of answers. The specific ceremonies are just a way of implementing a state machine on top of humans.
Two properties matter and both tend to get lost in methodology arguments.
Every state transition has a condition, and the condition is either explicit or someone’s judgement. “Ready for development” means something. Somewhere, somebody decides that a ticket has crossed that line. If nobody wrote down what qualifies, then the condition is that person’s taste on that day, which is a real condition, just an undocumented and variable one.
Every state has a holder. Work in a state is somebody’s problem. When work sits in a state with no clear holder, it sits there indefinitely, and the classic example is the ticket that has been in “ready for QA” for five weeks in an organisation with no QA function.
So a life cycle is states, transition conditions, and holders. When people say a team has no process, what they mean is that the states are informal, the conditions are unwritten, and the holders are assumed. All three still exist. You cannot not have a life cycle. You can only have one nobody designed.
How the implicit one gets built
It accumulates, and the archaeology is usually recoverable if you ask.
There was an incident, and a review step was added. There was a compliance requirement, and a field became mandatory. Someone joined from a company that did design docs, and now there are design docs, and the requirement lives in that person’s expectations rather than in any document. A tool was introduced that had opinions, and those opinions became process because nobody reconfigured them. A manager left and their weekly check-in stopped, and the coordination it was doing quietly stopped with it.
Ten years of that produces something with a characteristic shape: heavily specified in the places where a memorable failure happened, and completely unspecified everywhere else.
Accumulated process is heavily specified where a memorable failure happened and completely unspecified everywhere else. That distribution is not random: it maps to organisational trauma.
Which means it is optimised against the recurrence of past failures and says nothing at all about new ones. Steps also never leave, because adding one is a visible response and removing one requires arguing a failure will not return.
That distribution is important. It is not random. It maps to organisational trauma. Which means it is optimised for the recurrence of past failures and says nothing at all about new ones, and it is the reason “we have a rigorous process” and “we keep getting surprised” coexist so comfortably.
The other characteristic of accumulated process is that steps never leave. Adding a step is a visible response to a problem and costs the adder nothing. Removing one requires arguing that a risk is now acceptable, which is a career-negative act with no upside. So the accumulation is monotonic, and the total weight of the life cycle rises steadily regardless of whether the environment still justifies it.
Why implicitness is fine, until it is not
Here is the part I want to be careful about, because it is easy to conclude that implicit means bad and that is not true.
Implicit process runs on shared context. A team of six who have worked together for two years genuinely do not need a written definition of ready. They have a shared model, calibrated by repetition, and it is more nuanced than anything they could write down. Formalising it would make it worse. Anyone who has watched a high-functioning team get handed a process framework knows exactly how this goes.
Implicit process holds under three conditions. Low turnover, because the model lives in people. Low volume, because the model is applied by attention and attention is finite. And a homogeneous set of participants, because everyone applying the shared model has to have it.
Agents break the third condition immediately, absolutely, and permanently. An agent has no shared context. It cannot read the room, it has never sat in the retro where you decided you do not do it that way any more, and it cannot infer the unwritten condition from tone. Everything implicit is invisible to it.
And they strain the second badly, because the volume of work flowing through the state machine goes up while the amount of human attention available to apply the unwritten rules stays flat.
So a team that was running perfectly well on shared understanding does not fail because their process was bad. They fail because they added participants who cannot access the process, at the same time as they increased the load on the humans who can. The failure looks like the agents being unreliable. It is not. It is the life cycle having been unreadable all along, and nobody noticing because every previous participant could read minds.
The parts most likely to be implicit
If you go looking, and I recommend going looking, these are the states where the condition is most often unwritten, roughly in order of how much damage the omission does.
Ready for development. Nearly always implicit. Everyone believes there is a shared standard for when a ticket is workable. There is not. There is a distribution of standards across whoever is writing tickets, and the variance is wide. This is the single highest-leverage thing to make explicit, because it is upstream of everything, and because an agent given a not-actually-ready ticket does not stop and ask. It builds something.
Done. The other big one, and it is worth distinguishing three things that get conflated. Code complete (it merged), functionally complete (it does what was asked), and value complete (it is in front of users and doing what it was supposed to do for them). Most teams’ implicit definition is the first while their conversation assumes the third, and that gap is where a lot of “we shipped it but nothing changed” comes from.
When something needs a design conversation. Almost universally implicit, almost universally judgement-based, and the judgement is usually made by the person doing the work, who is the least well-placed to know whether it interacts with something they have never seen.
When to stop. Nobody writes this down. Work is finished when the person doing it decides it is finished, and for humans that decision comes from a sense of proportion. Agents have no sense of proportion. They will keep going, or stop at the literal boundary of the request, and neither matches what a person would have done.
Who has to know. Which changes require telling support, or an account manager, or the person who owns the adjacent system. Held entirely in the heads of a few long-serving people, and it degrades every time one of them leaves.
Making it explicit without making it heavy
The obvious risk in all this is that “write down your life cycle” becomes a documentation project that produces a wiki page nobody reads and no change in behaviour.
Three things keep it useful.
Write conditions, not steps. “Ready for development means acceptance criteria exist and each one can be evaluated as true or false without asking the author” is useful. “Step 3: refinement meeting” is not, because it describes an event rather than a bar.
Only formalise where the readers cannot infer. The test is not “is this important.” It is “would a competent participant with no history here get this right.” Where the answer is yes, leave it implicit and save the budget. Where the answer is no, and increasingly the participant in question is an agent, write it down.
Put it where the work is. A definition of ready that lives on a wiki is a suggestion. One that is attached to the ticket, and that a machine evaluates before work starts, is a condition. This is the difference between documenting your life cycle and actually having one, and it is the whole reason machine-checkable criteria keep coming up in this series. They are the mechanism by which a transition condition stops being a matter of opinion.
Where this breaks down
Explicit process has a real cost and I have priced it too cheaply. Every written condition is a thing to maintain, argue about and enforce, and written rules generate rule-following behaviour, including the malicious-compliance kind where a ticket technically satisfies the definition of ready and is still useless. Shared judgement does not have that failure mode. You are trading a flexible mechanism for a rigid one, and the rigid one is only better because one class of participant cannot use the flexible one.
Some teams should not do this at all. Four people, one product, everyone in the same conversation, agents used as assistants rather than as autonomous workers: writing down your life cycle would be pure overhead and would make you slower with no offsetting benefit. The threshold is roughly the point at which somebody has to ask what the state of something is, rather than knowing.
Making the implicit explicit surfaces disagreements that were productively buried. This is the one nobody warns you about. Two senior engineers have had different definitions of done for three years and it has never mattered because they work on different things. Write it down and now there is a meeting, and possibly a conflict, and the conflict is real rather than manufactured. Sometimes that is exactly what needed to happen. Sometimes you have spent three weeks and a relationship on a disagreement that was costing nothing.
And a written life cycle is a description that drifts, like any other. The same argument this series makes about the tracker applies here. A documented process is a copy of how work happens, and copies degrade. The only durable version is one that is enforced at the point of the transition rather than described somewhere adjacent to it, which is a much higher bar than writing a page.
The takeaway
A life cycle is states, transition conditions and holders, and you have one whether or not anyone designed it. The one you have was assembled by accumulation, is heavily specified where past failures happened and unspecified everywhere else, and runs on shared context held in people’s heads.
That worked while every participant could access the shared context. Agents cannot, which turns every unwritten condition into a silent failure, and volume removes the human attention that used to paper over the gaps. The response is not a process framework. It is making explicit the specific conditions that a participant without history cannot infer, starting with ready and done, and enforcing them where the work is rather than describing them on a page.
The last piece in the Foundations series draws the whole thing as one diagram and then goes through it slowly, loop by loop, so you can see exactly which parts of your current life cycle survive unchanged and which have to be rebuilt.