Humble & Kind

Jean-Philippe LeBlanc

JP LeBlanc

Ask Jean-Philippe's page a question. An AI answers from what Jean-Philippe chose to share, cites it, and says it is not Jean-Philippe.

Ask Jean-Philippe · An assistant can ask through MCP at https://humblekind.co/api/mcp/p/jpleblanc

Elsewhere: LinkedIn · jpleblanc.com

What Jean-Philippe has shared

How-to: What artefacts matter most in the first few days?

A valid org chart with more than names and positions! Ideally, a three-ring tier of people surrounding the onboarded individual. First tier: people that the onboardee will work with. Second tier: people that the onboardee will interact with. Third tier: the rest of the company.

Note: What leaders have to give up

Three things to let go of. The task as the unit of accountability: tickets closed, pull requests merged and story points burned all rise while value delivered stays flat, because they track activity inside a process rather than what the process produces. The interface as proof of work: the standup, the status update and the weekly report exist partly for coordination and partly because they let managers observe effort, and when the system routes work and surfaces only exceptions that visible surface shrinks. Leaders who cannot read outcomes without process theatre will find this deeply uncomfortable, and the discomfort is diagnostic rather than a reason to slow down. And the AI initiative as a project with an end date: substitution projects close, ambient ones compound as the system accumulates context, so funding it like a deployment means cutting resources exactly as the returns start to accelerate.

Note: The connective tissue worry

The "AI taking jobs" framing misses the thing actually worth worrying about. Teams are how humans make sense of work. I am on the platform team, we own the billing service. Those statements are psychological as much as organisational, telling people who they are and what they are responsible for. When the team dissolves into a collection of individual operators with agents, we will be more efficient and something else goes with it: the connective tissue that makes people feel they are building something together rather than accumulating their own output. The loneliest version of the future I can imagine is one where everyone is productive and nobody is connected, where the software gets better and the experience of making it gets emptier. I do not know how to prevent that, and it needs naming out loud before we sleepwalk into it optimising for throughput. The teams that solve it will not be the ones with the best tooling or the fastest shipping. They will be the ones who find a reason for people to build together that has nothing to do with efficiency, and I have no idea what that looks like.

How-to: Run intent definition workshops

Most engineers were trained to solve problems in code. The higher value skill now is specifying what the system should do, with constraints, edge cases and integration points clear enough that an agent implements it well. Run it as a workshop: hand the team a complex feature description, have them write the specification rather than the code, then review the specs together. The engineers who struggle with this exercise are the ones who will struggle most over the next two years, and you would rather find that out in a workshop than in a performance conversation. The same shift belongs in hiring, where screening for architectural reasoning, tradeoff analysis and second order effects beats screening for five years of a named technology.

How-to: Pipeline as a product

Your pipeline is not infrastructure someone maintains on the side. It is the single biggest multiplier on your team's output, so give it a roadmap and staff it with a product minded engineer. Set quarterly goals the way you would for any product: build time from forty five minutes to fifteen, flaky test rate from eight percent to under two, impact scoped testing so a change only validates the services it touches. Redefine done while you are there, because your current definition still assumes a human wrote the code. Done now means the generated code passed automated validation, a human reviewed system level impact rather than every line, integration tests confirmed behaviour across affected services, and the deployment cleared a confidence threshold set from past reliability data. Write that down and share it.

How-to: Measure ai native delivery

Measure time to confidence rather than deployment frequency. Frequency tells you how often you ship and nothing about whether you should have. Time to confidence runs from commit to a confident deployment decision and includes test execution, review, security checks and the human judgment call, so a team deploying ten times a day with three hours of manual validation each time is slower than one deploying twice with full autonomous validation in eight minutes. Drop story points, which measured implementation effort and became noise once implementation compressed. Track cycle time from work starting to running in production, throughput as meaningful changes reaching users per week, and rework rate as the share of shipped code needing correction within forty eight hours.

How-to: Audit the handoff chain

Trace one feature from idea to production and count every human handoff. PM to design, design to engineering, engineering to QA, QA back to engineering, engineering to staging, staging to production. Each one adds latency, miscommunication and context loss. Set a target of halving the touchpoints within six months, and give people both the tools and the explicit permission to cross role boundaries, because the permission is usually the missing half. Then ask the question the count sets up: if the outcome could be reached without a given step, what is that step for.

How-to: Stay calibrated as a leader

Build a prototype with an agent before your next planning cycle and compare how long it took against what your team estimated. A five times gap is a conversation worth having. Ship a small change through your own pipeline and feel the friction your team feels: thirty minutes from commit to production is healthy, two days is a systems problem and you would not have known without touching it. Use the tools on a real problem rather than a demo, writing a spec and getting to a running prototype inside an hour. You will learn more in that session than in a quarter of executive briefings. None of this is about shipping features weekly. It is about staying close enough that your judgment on timelines, architecture, hiring and prioritisation stays calibrated.

How-to: Make speed an outcome

Start with an honest look at where work actually stops, not whether you are fast enough in the abstract. Where does a feature sit waiting after the code is written. How long does it take a new engineer to ship their first thing. When a decision needs making, who has to be in the room, and are they ever all in it at the same time. The answers are usually specific and a little embarrassing: a two day deploy process, a review bottleneck that traces back to one person, a spec that arrives late and gets rewritten twice. Fix those. Then let people move, which is the cultural half and only works once the operational half is done. Do not announce any of it.

Lesson: Identity fractures under mutation

One team shipped eleven changes to a single feature in one week. Not bug fixes, substantive changes driven by how people were actually using it, and by Friday the feature bore almost no resemblance to what launched on Monday. Is that one feature or eleven, who owns it, and which version is the customer filing a bug against. People build psychological ownership around what they create, and when the thing you built on Tuesday has been rewritten three times by Friday by agents acting on signals you never saw, it is not clear what you own or what you are responsible for. I noticed the engineers on those fast moving teams talk differently about their work. Less pride of authorship. More resignation to impermanence.

Lesson: Context decays across handoffs

Ticket, queue, planning meeting, sprint, build, review, QA, staging, deploy, measure. At every handoff context bleeds, and the original intent degrades a little more each time the work changes hands or waits in a queue. A developer picks up a ticket three weeks after a PM wrote it, the PM's mental model has moved, the codebase has changed, and the developer fills the gaps with assumptions. The reviewer catches some and misses others. QA tests against a spec that is already stale. What reaches production is an approximation of the intent passed through six handoffs and three weeks of decay. Substitution AI speeds up the individual stations and leaves the chain intact, which is why the gains stay modest.

Lesson: The constraint moved to validation

A Series B team I know went from forty to two hundred pull requests a week with the same eight engineers, and their deployments slowed. The pipeline was built for forty. Code generation got five times faster and the constraint moved from generation to validation, where it stayed. More people writing code does not fix a validation bottleneck, and neither does more tooling on the generation side. The same arithmetic breaks QA as a department: you cannot scale human review linearly against machine generated volume, so validation has to become a property of the pipeline rather than a phase staffed by people.

Lesson: Estimates break before anything else

A designer on our team rebuilt two critical platform pages, the ones carrying ninety percent of platform traffic, in three days using an agent. We had estimated two months through traditional engineering. The number that should bother you is not the three days, it is that the two month estimate came from experienced people applying sound judgment to a world that had already changed underneath them. Estimates are the first thing to break, they break quietly, and they keep getting produced with full confidence. Which is the practical argument for leaders staying hands on: you cannot spot a five times gap in an estimate you have no way to calibrate.

Lesson: Should a human be doing this

The move from treating AI as autocomplete to treating it as a delivery loop turns on one uncomfortable question: not can AI do this step, but should a person be spending time on it. That reframe is where the real cultural friction sits, because it touches identity. Engineers who define themselves by their implementation craft are being asked to reframe their value around judgment, problem definition and validation design. Past that point the work stops being about whether engineers use AI and becomes structural, about whether the pipeline itself can be trusted to catch what humans used to catch. The question shifts from did a human review this to do our automated gates catch the failure modes that matter, and that is a genuinely different engineering problem.

Lesson: The uncomfortable middle

Expect a wildly uneven distribution and do not treat it as a failure. We had teams genuinely pushing into agent driven delivery loops and teams where half the engineers were still in tab completion mode, in the same organisation, reporting up the same chain, at the same time. The instinct is to treat the lagging teams as problems to solve under pressure, ship a mandate and set a deadline. What matters more is that each team has a clear picture of where it is, where it is going, and what the next concrete step looks like. The transformation does not happen in the announcement or in the maturity model. It happens in the thousands of small conversations where a manager sits with an engineer and says the way you have been doing this is good, and it is not enough anymore. That is the hardest sentence in engineering leadership right now.

Lesson: Being good at the old thing

Fifteen years of being exceptionally good at software delivery was the single biggest obstacle to becoming the company we needed to be next. Deep institutional knowledge, hard won customer confidence, production systems at enormous scale, engineers genuinely proud of how they build. All real, all earned, and a meaningful amount of it wrong for where we were going. A company founded two years ago carries none of that weight and has nothing to unlearn because it never learned the old patterns. This is why the transition is harder for the good organisations than the mediocre ones, and why it is open heart surgery on a running system rather than a migration.

Lesson: Managers go first visibly

One of the most effective things a manager can do is use the tools visibly in their own work. Write the incident postmortem with it. Write the technical proposal with it. When the manager uses it in the open, it stops being a mandate and starts being normal. Early on the blocker is almost never sophistication, it is access and psychological safety, so the unglamorous work is auditing who actually has the tools, having honest one to one conversations about where each person really is, and making it safe to experiment and fail.

Lesson

You cannot argue someone out of a position they arrived at through experience. The engineer who watched blockchain and low code and every other revolution that turned out to be a tool you use sometimes has earned their skepticism honestly. Arguing produces compliance at best. You have to show them, on their own work, and then give them enough structured time to get past the first mediocre result, because we keep asking people to learn something new while fully occupied with their current job and then reading the failure to learn as an attitude problem.

Lesson: Three layers of friction

Resistance breaks into three layers and each needs a different intervention. Attitude: engineers who have watched hype cycles and do not believe this one changes their job, a skepticism that is earned and rational and this time expensive. Aptitude: using these tools well is a real skill, so an engineer who tried once, got a mediocre result and concluded it is not ready has made a skill error rather than a technology assessment. Knowledge: even the willing do not know what AI native delivery means in practice, because most of the industry is still working it out, so you are asking teams to adopt patterns that do not exist yet. Each layer compounds the others, and an engineer who is skeptical, unskilled and unclear on the destination will not move because you sent a Slack message about adoption goals.

Lesson: I optimised for deployment first

I had this wrong for a while. My first instinct was to optimise for deployment: more tools, more coverage, more seats. I am less sure that is the lever now. The organisations that look different in two years may be the ones that worked out how to make the contact frequent enough, and real enough, that the rewiring actually happened. People build new habits in the actual work, not by watching demos, which makes this a leadership problem rather than a tooling one. Coverage is the number that is easy to move and easy to report, and it is not obviously the number that matters.

Position: The solo operator

Follow the logic far enough and you reach an uncomfortable destination. If AI handles implementation, assists with prioritisation, and consensus is too slow for the pace of decisions, the optimal unit of software production is not a cross functional team. It is one person with a fleet of agents holding the vision, making the calls and directing execution at production scale. I keep seeing early versions: a designer shipping a full production feature front to back with no engineer involved, a PM building and deploying an internal tool over a weekend. The cross functional squad was designed for a world where those skills had to live in different people, and those boundaries are dissolving fast enough that assuming the team structure of 2020 survives to 2030 feels like denial.

Position: What a pm is for

The PM role today is defined by understanding what customers need and deciding what to build. If AI handles the second and increasingly assists with the first through automated research and feedback synthesis, I genuinely do not know what a product manager is for. The honest candidate answer is taste, or desire. Not "what should we build" but "what do we want to exist in the world," which is a question no model can answer because it requires wanting something, and wanting is the one capability AI does not have. Maybe that is enough. I am not sure "the person who wants things" is a job description that survives a reorg.

Position: The roadmap as artifact

A roadmap was a coping mechanism for slow implementation. When a quarter spent on the wrong feature was a quarter you could not get back, you needed a document saying what you were building and in what order. That economics has collapsed. Looking at one Q1 roadmap in February, half of it was done by the third week and the other half got replaced by things we did not know mattered until usage data told us. We still write them, and I think we write them because the ritual feels safe. I have started wondering whether the roadmap is becoming what the Gantt chart became in the agile era, a comforting holdover everyone maintains and nobody follows. I have not concluded that yet.

Position: Productivity is the wrong roi

The obvious thing to measure when Ada started tracking AI adoption was productivity, how much faster and how much more output. Those numbers are real. The more time I spend inside this the less convinced I am that productivity is the right thing to optimise for. What I keep noticing, and what we do not know how to measure yet, is that people who work alongside AI seem to think differently after a while. Engineers scope problems at a different altitude. Support teams pattern match across conversations and change the questions they ask. This is neuroplasticity as an org design hypothesis, not a proven playbook: the bet is that where AI is embedded in the actual work rather than the periphery, people's cognitive habits genuinely shift and their bar for an acceptable answer rises. Whether that is real, whether it is durable, whether we are building the conditions for it deliberately, I do not know yet. It is the bet I would make.

Opinion: Compliance is not transformation

Some things are genuinely non negotiable. Every engineer has the tooling and every engineer uses it. But pressure alone does not produce the shift. An engineer who opens the tool because they were told to, does not trust it, does not know how to use it well, and cannot see how it connects to their actual work is not AI native. They are compliant, and compliance is not the same as transformation. The real work sits in the middle ground: clear expectations paired with genuine support, structured experimentation time, paved paths that give people the best possible first experience, managers who can have an honest conversation about what is changing and why, and engineers who made the shift sharing what worked with those who have not. It is slow and messy and it does not compress into a quarter.

Opinion: Elite is now table stakes

The scoreboard changed and nobody sent a memo. Deployment frequency, change failure rate, mean time to recovery, the metrics that meant world class for a decade, are now the floor. The processes that earned that status, meticulous human review on every pull request, manually sequenced deployment gates, engineers owning every step from commit to production, are not best practices anymore. They are friction. And the gravity of past success keeps pulling teams back toward them, because the old way felt right, produced results, and built careers. Telling an engineer who spent eight years perfecting a workflow that their workflow is now a bottleneck is not a comfortable conversation, and it is the one that has to happen.

Opinion: Service as software

You stop configuring and operating delivery software and start consuming it as a service. Today CI/CD is plumbing: you write the YAML, configure the triggers, and the pipeline does what you told it. The version worth building knows your codebase structure, dependency graph, test history and failure patterns, analyses the diff, maps the affected services, generates the right validation and runs it without anyone editing a config file. You push code, the service validates, tests and deploys, and you pay for successful deployments rather than pipeline minutes. Stripe does not sell you payment processing software. The question to put to every vendor is when this becomes a service I consume rather than software I operate, and the answer tells you who is building for the next few years and who is still selling 2019.

Opinion: Consensus breaks before the team does

Consensus is a serial process running on top of a parallelised implementation layer. It works when decisions come in days or weeks and you have time to socialise an idea. It cannot keep pace with a cycle that goes from spec to production in ninety minutes, and no framework fixes that, because the constraint is social bandwidth rather than decision quality. I watched both outcomes on two teams. On one the PM started deciding unilaterally out of necessity, and that team shipped faster than any other in the org while morale got complicated, some engineers loving the speed and others feeling sidelined. On the other they tried to hold consensus at the accelerated pace, lasted about six weeks, and then the engineers started making product calls in Slack threads the PM never saw. Either one person decides or nobody does.

Opinion: The gatekeeping reflex

When the pace of possible change exceeds what a team can absorb, the natural human response is to create friction. Not because friction is useful, but because people need somewhere to put the anxiety of infinite possibility. New approval workflows. Architecture review boards moving from monthly to weekly. An AI governance committee adding three days of review to something that took two hours to build. Teams adopt the tools, individual output spikes, and organisational delivery stays flat, and a good part of that gap is gatekeeping invented specifically to slow things back to a pace that feels manageable. The gates do not improve quality. They reduce anxiety. It is a fear response dressed up as process, and organisations that cannot see it for that will build elaborate bureaucracies around AI output and wonder why they got slower.

Opinion: Leaders must stay hands on

For twenty years the advice was that the best leaders do not write code, they build teams that write code. That advice is wrong now. It made sense when a leader spending three hours debugging lost three hours of alignment and hiring, and the tradeoff held because building software was slow. When a working prototype takes twenty minutes instead of three weeks, the context switching penalty shrinks and the maths flips. This is not about proving you can still code. It is about keeping the technical judgment that sits underneath every other decision you make: timelines you cannot validate, architecture you cannot evaluate, backlogs you rank on estimates that are themselves guesses about tools you have never used. Leaders who stay out of the details make worse decisions. The sideline coach had a good run and it is over.

Opinion: Ambient over invoked

In substitution mode you bring context to the AI: open a window, explain the problem, paste the code, describe the constraints. Every interaction starts cold and the whole cognitive tax falls on the human, who has to know the right question and evaluate whether the answer fits. In ambient mode the system already holds the context and surfaces what needs your judgment. The distinction explains why the gains have been so unequal so far. The people benefiting most are already high performers, because they know which question to ask and can evaluate output fast, so the productivity lands with the people who need the least help. Ambient inverts that: the skill that matters moves from prompting well to setting intent clearly, and that is a different distribution of who benefits.

Opinion: The substitution trap

A VP buys an AI coding assistant, the team reports a fifteen to twenty percent gain six months later, leadership builds a deck, the board is satisfied, the initiative gets a green check. That ceiling is fixed the moment success is defined as hours saved on existing tasks. It is seductive because it produces a clean ROI narrative you can put in a quarterly report, and the maximum upside you can capture is a fraction of your current labour cost. That is a cost optimisation story, not a capabilities story. Substitution is a fine starting point and every technology begins there. The trap is that the structure of the work, the sequence of handoffs, and the organisational assumptions underneath never get questioned.

Belief: Coding is a minority of shipping

Coding is only fifteen to twenty five percent of shipping software. The other three quarters is code review, testing, deployment, integration and monitoring, and that is where the real friction lives. This is why individual practitioners report three to ten times gains on specific tasks while most engineering leaders report one to ten percent at the organisation level. The gap is not that the tools underdeliver. It is that leaders who have not built anything with them do not know which parts got faster and which part is now the constraint.

Belief: Judgment did not get cheap

AI made implementation cheap. It did not make judgment cheap. Legacy code is still hard, distributed systems still fail in strange ways at 2am, and getting an organisation to change how it works is still political. The engineers who thrive will not be the fastest prompt writers. They will be the ones who can hold a system with twelve services in their head, state clear intent for an agent, and make the right call when three options look equally reasonable and the data does not point anywhere. Taste still matters.

Belief: The org chart is the bottleneck

When electricity replaced steam, manufacturers pulled out the steam engine and bolted an electric motor into the same spot, keeping the shafts and belts and the whole layout. It took about thirty years before someone put a small motor on each machine, tore out the belts, and redesigned the floor around the flow of work rather than the flow of power. We are in that thirty year gap. The gains from bolting AI onto an existing workflow are real and capped by the structure they are plugged into. The technology is ready. The org chart is the bottleneck now, and that is a political problem rather than a technical one, because processes exist because someone designed them, someone owns them, and someone's authority depends on them.

Belief: Culture is downstream of friction

Removing friction is operational work, not cultural work. Where a feature sits waiting after the code is written, how long a new engineer takes to ship their first thing, who has to be in the room for a decision and whether they are ever all in it at once. Unglamorous questions with sometimes embarrassing answers. The cultural piece is real but downstream: once the friction is gone you have to actually let people move, tolerate quick imperfect calls, stop relitigating what already shipped, and trust the person closest to the work. That only matters after the operational constraints are gone. Culture cannot override a broken deployment pipeline or a six person approval chain.

Belief: Speed is an outcome not a value

Every fast company I have seen became fast the same way. They removed the things that made work slow. Not one of them got there by deciding speed was a value. When speed is a value it lives in the handbook and the all hands and the recruiting pitch, while the work continues to move at whatever pace the system allows. I have worked with teams that had "move fast" in their operating principles and a two week PR review cycle, both true at once, and nobody found it strange because the value was aspirational rather than descriptive. Speed as a value gets announced. Speed as an outcome gets noticed, usually by someone who cannot say when it happened.

Belief: The org includes its symbionts

About forty trillion microorganisms live in a human body, roughly equal to human cells by count, and we do not say "the human plus its bacteria." We say the human. The organism includes its symbionts, the ones that work with it are what make it viable, and the ones that try to sterilise the environment tend not to survive. Organisations still drawing a hard line between "our team" and "the AI" are fighting their own biology. Where the analogy breaks, and it is worth naming: a nervous system does not have to persuade cells to participate. Organisations do, and no tooling solves that.

Belief: Routing not reliance

"How much should we rely on AI" is a good question and the wrong one. Your nervous system handles about eleven million bits a second and your conscious mind about fifty, and the body never holds a strategy meeting about appropriate reliance levels. It routes: reflexes at the spinal cord, pattern recognition in the basal ganglia, novel decisions in the prefrontal cortex. The question worth asking is what architecture lets each kind of intelligence do what it is actually suited for. Reflexes for the predictable, attention for the novel. Most software orgs are still stuck in the strategy meeting, treating AI as a vendor they procure and allow in through a gate, which keeps producing the same result: a carefully governed layer of AI assisted work sitting on top of an organisation that has not otherwise changed.

How-to: Decide where a check lives

Take the class of change and name what the pre merge gate catches that canary plus flag off plus rollback does not. Require a specific answer, not a hypothetical one. If the answer is an irreversible schema change that breaks old code before the new code lands, keep the gate and make it real. If there is no specific answer, the gate is ceremony and most review bottleneck process is exactly that. What belongs pre merge is a floor rather than a judgment: the suite tells the truth, a flag is attached to the change, and the rollback path exists. Not coverage percentage, not style, not whether somebody senior has looked at it. The classification never keys on who or what wrote the code.

How-to: Fix a slow pipeline

Measure and publish the number before touching anything. Set a time budget and fail the build when it is exceeded, so going over becomes a decision somebody makes rather than a drift nobody notices. Then split and parallelise the runs, prune low value tests instead of tolerating them, and quarantine every flake the week it appears. Do not accept the workaround: a team that has started batching changes and stopped running anything locally has already passed judgment on your pipeline from the inside. Argue for the work in engineer months and payback weeks, because four weeks of one person's time buying back two engineers of waiting survives a tight quarter and developers will be happier does not.

Lesson: Ci in the agent era

CI's old job was catching a bad diff, and that is no longer the right target now the diff is the cheapest part of the work. Check the spec instead. Where the spec is precise enough to verify against, CI runs evals that fail loudly when the implementation drifts from what was agreed, and a person reviews the spec rather than the diff. CI also has to defend the review queue, since that is where the constraint went, so run a machine first pass that checks house conventions and flags missing migrations and unhandled errors before anything reaches a human. Make diff size policy rather than hope, because an agent hands you eight hundred lines where a human wrote eighty, and a large diff approved in ten minutes is an unreviewed change with a green checkmark. Measure deployments to main, not pull request volume.

Lesson: Repo layout is an ownership decision

Monorepo against many repos is a category mistake until you decide what belongs in a repo, because the real variable is ownership and ownership is what sets your build and test times. I run mixed deliberately: shared platform code, libraries, anything used by more than one team goes central, and product code splits by team. One repo with no ownership enforcement gives you shared dependency state and one version bump for everyone, at the price of every team's build breaking on every team's mistake with nobody owning the tooling. Repo per service gives each team a fast local build and a coordination tax on every shared library bump, so nobody upgrades, five versions run in production, and tests stay green against a stale copy. Pick one and enforce the boundaries mechanically.

Lesson: Ci spend is a unit cost

Watch cost per merged change, not the speedometer. CI compute is a unit cost like any other cloud spend, and the question about faster machines is whether they lower the cost per thing that actually ships or just make the build feel fast while the queue holds. Price it as arithmetic: build time, times runs per day, times engineers, times days, converted to engineer months and set against the machine bill. Faster hardware is worth buying when it crosses the ten minute threshold, because you are buying attention back rather than clock time, and worth nothing when you are already well under and the real constraint is the review queue. Fast machines on top of an unbudgeted test suite are a tax on a tax. Never promise the recovered time back as feature output.

Lesson: What gates a pull request

Two questions decide where a check lives: what does it catch that the other side cannot, and how expensive is being wrong once the code is out. Pre merge gates earn their keep in one situation, when being wrong after merge costs more than any rollback can fix, which is a short list: a migration dropping or renaming a column, anything moving money irreversibly, data destruction. Everything else moves after merge, because detection is genuinely better there. Pre merge you have fixtures and staging, which are always wrong in data and scale and hand you a confident green about a system that does not exist. The deciding test is concrete. What does this gate catch that canary plus flag off plus rollback does not. Not might catch. Catch. Nothing specific means the gate is ceremony.

Lesson: Continuous deployment with flags

Merges go to production automatically with no human deploy step, on the condition that production means dark behind a flag. That condition is the whole answer. The human step is not removed, it moves from "is this safe to deploy" to "is this ready to expose", and for most changes the second decision is automated too, through percentage rollout, canary and automatic rollback on a metric threshold. The honest exception is the one way door, anything touching money, auth or data in a way that cannot be reversed, which gets a slower rollout and a second pair of eyes on the release side rather than as a merge checkpoint. Holding merges because you do not trust the pipeline is a safety net problem wearing a process costume.

Lesson: Flakiness is an emergency

The day somebody notices a flaky test, quarantine it, that same day, then fix it or delete it. It does not wait for a sprint and it is never scheduled as a debt project. Every day it survives teaches the team that red does not necessarily mean stop, and by the fifth false red nobody reads the failure, so the suite has stopped checking anything while still eating everyone's time. The investment is not a coverage number, it is confidence per second of runtime, so prune tests that guard nothing and brittle ones that guard mistakes nobody would make. Agent volume makes this urgent rather than optional: a flake firing weekly at human pace fires several times a day at agent pace, and the instinct of the engineer who double checks has no time to operate.

Lesson: Trunk based short branches

Trunk based, with branches measured in hours or days and never weeks. A long lived feature branch is a process for accumulating risk and calling it safety. Branch lifetime and merge pain rise together and not linearly, so a branch that lived six weeks is negotiating with six weeks of everyone else's work, and forty changes landing together means you know production broke at 2am and not which one did it. The branch also converts a reversible decision into an irreversible one, because stakeholders attach to it until cancelling becomes a social event. The objection is always that the feature is not done, and that is what flags are for. If the pipeline cannot ship every merge without ceremony, fix the pipeline rather than growing longer branches to compensate.

Lesson: Pipeline speed is behavioural

Under ten minutes for the full pipeline, under one for the inner loop an engineer runs while working. These are behavioural thresholds, not preferences. Past roughly ten minutes people stop waiting and start context switching, and what you lose is the quality of the work rather than the minutes. A twelve minute build hit fifteen times a day by twenty engineers is a permanent full time person of waiting, on nobody's budget. Do not start by optimising. Measure the number and publish it, because slow pipelines are built by accretion and every step in there was individually justified. Set a budget, fail the build when it is exceeded, and make going over a conscious decision rather than a drift.

Opinion: Code freezes are a confession

A code freeze is a public statement that you do not trust your own safety mechanisms. It is usually described as prudence before a high traffic period, and what it actually does is batch up every change until the moment the system is under the most load, then release them together. Long lived release branches are the same confession in a different format. If you cannot ship on the busiest day of the year, the freeze is not the fix.

Opinion: Merge approval is a proxy

A human approving a merge is a proxy for safety and a poor one, because it happens before the change has met real traffic, real data and real third party latency. If the harness underneath is honest, a suite that tells the truth, a flag on every change, staged rollout, rollback in seconds, then the approval adds nothing. If it is not honest, the approval never saved you either. The line for human review is blast radius, not authorship. A one way door gets a person whoever wrote it. A dependency bump does not, whoever wrote it.

Belief: A suite that lies

A failing test, unqualified, has to mean something is actually broken. A team with no tests knows it is flying blind. A team with a suite it has quietly learned to half ignore thinks it has instruments and does not, which is worse than having none.