How we work
This is the almanac I train and point any engineer I work with to: how we open an engagement, how we choose what to build, how we ship it, and the schedule we keep.
Motivation
In most of the firms I have audited, the person responsible for technology sits somewhere in middle management. They are invited to the meetings, and their opinion rarely changes a decision. I do not think the business is being unfair here. The engineering department spent the quarter, and sometimes considerably longer, on an initiative whose outcome nobody outside the team could describe.
Three cases I keep returning to:
- An AI pilot at a property developer that impressed the top management during its demonstration and reached an MAU (monthly active users) of two in month two.
- A CRM migration inside a sales department that finished with two separate systems running in parallel and a support team grown from seven people to fifteen, close to two and a half times the cost of keeping it running.
- A year-long refactor at a wellness company that occupied three engineers and roughly $150,000 of payroll, with nobody able to put a number on what it returned.
Over the last ten years I have witnessed, discussed or mediated somewhere close to a hundred cases of this kind.
I have spent thirteen years in engineering and the last four running businesses that sell it. The worst period of my career was a year in which I shipped constantly and moved nothing, and what corrected it was giving up the belief that my job was to protect the code. Code is the artifact; the decision behind it is the actual work.
Everything below came out of that correction and was then tested against commercial teams at property developers, brokerages and an education company. Some of it will contradict what you were taught if you learned engineering inside a large organization. I have kept it anyway, because it survived contact with clients who pay for outcomes rather than for closed tickets.
What this is built on
None of it is original. Four bodies of work stand behind the twenty-one principles below, and most of what follows is a reading of them against commercial teams that do not sell software.
-
Kelly Johnson’s 14 Rules and Practices
- Rule 1 — the manager is delegated practically complete control of the program in all aspects.
- Rule 3 — the number of people connected to the project is restricted “in an almost vicious manner”, to 10–25% of a normal system.
- Rule 5 — a minimum number of reports, with the important work recorded thoroughly.
- Rule 12 — mutual trust and day-to-day liaison, which cuts correspondence to a minimum.
Principles 03, 04 and 05 are this list applied to software. The team stays between three and six people, we make the architectural call and carry the cost of it, and the reporting is one weekly written update rather than a governance layer.
-
Martin Fowler
- The pattern catalogue gives shared names to the structures we assemble, which is most of what a vocabulary is for.
- Strangler Fig — the replacement grows around the system it replaces, which keeps running until there is nothing left for it to do.
The CRM relaunch is a strangler fig migration: a new engine takes call sites one at a time while the legacy lead system stays up and read-only throughout.
-
- Small releases and continuous integration.
- Pair programming in place of a review queue.
- Collective code ownership.
- The on-site customer, close enough to answer a question the same day.
- A sustainable pace.
We keep the release rhythm, the collective ownership and the customer in the room. The pair is now an engineer and an agent, and the review gate that XP removes is the one we replaced with tests, types and a self-check the agent runs before a human reads anything.
-
A small team with agentic delivery
- Fred Brooks, The Mythical Man-Month, 1975 — communication paths grow faster than output, so adding people to a late project makes it later.
- Parasuraman, Sheridan and Wickens, 2000 — any process splits into information acquisition, information analysis, decision selection and action implementation, and each of the four is automated separately.
Acquisition and analysis go to agents, action mostly goes to agents, and the decision stays with a person. That split is what lets a team of three to six run the work that used to need a department, and it is also the line we do not intend to cross.
Premises
These six positions decide everything further down the page. I have changed my mind about a great many things over thirteen years in engineering, and these are the ones that held.
- 01
Technology is the enabler. It is almost never the business.
Your company sells apartments, courses or construction contracts, and software exists to make that work faster, cheaper or better presented. Once a team accepts this, most of the arguments it used to have about tooling lose their urgency. I do not spend meetings defending a framework choice that no customer will ever notice.
- 02
“Good” is defined by the business you are in.
Good code in an early-stage product is cheap to change and cheap to delete. In a tool built for a sales team it is code that matches the way those people work this month, which is a lower bar in some respects and a considerably higher one in others. In a bank it is code that is observable, unexciting and unlikely to surprise anyone at two in the morning.
The most common reason an engineering team feels slow is that its lead engineer learned the craft in one of these settings and kept applying the same standard in the next one.
- 03
Three to six people, all working across functions.
Fred Brooks published the observation in 1975 and it has aged well: adding people to a late project makes it later. Communication paths grow faster than output does, and every additional person creates one more document the team has to keep accurate.
I keep a team between three and six people, and everybody works across functions. The engineer writing the migration is the same person who sat with the sales manager who will have to live with it, so decisions get made in a single conversation instead of a forum, and it stays obvious who is responsible for what.
- 04
We decide, and we carry the consequences.
Clients bring us in to say how something should be built, and I treat that as the actual deliverable instead of handing the question back to them. We make the call, put our name on it, and repair it at our own cost when it turns out to be wrong. High agency comes with a price attached: you own the result, including the version of the result you would rather not show anybody. What the client gets in exchange is a team that does not need permission to begin.
- 05
Speed is an asset, so we protect the supply chain.
I would not claim that we employ the fastest engineers on the market. We are still faster than most of the teams we get brought in to replace, and the difference comes from three places: the team is small, the path from an idea to production is short, and the tools were chosen for delivery rather than for the résumé.
When something slows us down I treat it as a defect in the supply chain and fix it there, instead of asking people to work harder around it. A week without a release is a week in which the business makes decisions on older information than it needs to.
- 06
Craft is part of the adoption strategy.
A tool that looks careless will be used carelessly, and inside a commercial team that carries a direct cost. The catalogue page, the generated presentation and the proposal document are what a salesperson puts in front of a paying customer, so their appearance decides whether that person opens the tool again the following day. People make purchasing decisions visually, and they choose which internal tools to adopt in much the same way.
Engagement
This is how I run a first quarter with a new client, from the opening conversation through to the point where people open the tool without being asked to.
- 07
Start with an audit, and count before arguing.
I spend the first weeks reading the funnel and sitting with the people inside it, counting how many leads arrive in a week, how long the first reply takes, how many hours go into assembling a single offer, and which stage of the pipeline loses the most deals. That last question is usually the one nobody can answer from the data they already have.
The numbers are written down before we propose a solution. A proposal is worth very little without the baseline it claims to improve, and the counting itself tends to expose the disagreement that was hiding underneath the original request.
- 08
Name the figure you expect to move.
Every piece of work is accompanied by one sentence: if this ships, a named figure moves from A to B. That sentence is an estimate and we label it as one, because half of its value arrives later, when the figure lands somewhere else entirely and we find out which part of our reasoning was wrong. A team that never commits to a prediction never gets any better at making them.
- 09
Ship against the adoption curve.
Software that nobody opens has no value, regardless of what it cost to build. Everett Rogers’ adoption curve applies inside a twenty-person sales team as reliably as it applies to a market: the enthusiasts will try something because it is new, while the late majority moves only once the friction has been removed and somebody they trust has gone first.
So we release in small increments, watch what gets used, ask the people who stopped using it why they stopped, and adjust. Then we show the change on a call, with a visual clear enough that people want to try it for themselves.
- 10
Work with the constraint.
Somewhere in the middle of every plan you meet the obstacle you did not plan for: a vendor API missing the field you need, a data model built for a business that no longer exists, or a sales director who will not change the process. When that happens I change the strategy and hold the outcome, rather than holding the strategy and moving the date. Most of the solutions I am proud of came out of a constraint we were not allowed to remove.
How we build
I care much less about which framework a team picks than about the five habits below. They are what keeps a small team from producing something that nobody can change six months later.
- 11
Prefer the simpler version.
Given two designs that both satisfy the specification, we take the one with fewer moving parts, even when the alternative would be more interesting to build. An abstraction gets introduced once a second caller exists for it, and a helper with a single caller is a prediction about the future that the future rarely confirms.
- 12
Complex systems grow out of simple ones, so design the transition first.
John Gall’s observation from 1975 has held up well: a complex system that works is invariably found to have evolved from a simple system that worked, while systems designed complex from the start tend not to work at all.
The practical consequence is that launching anything new means running two systems side by side for a period. We design that period before we design the target state, using the strangler fig, a parallel run against the system being replaced, and expand and contract on the schema. A single cutover is where most outages come from.
- 13
Design around the attention the person has left.
The salesperson you are building for has a phone in one hand and a client on the other line. Every additional field, confirmation dialog and mandatory step consumes attention they do not have to spare, so we reduce the number of clicks, set sensible defaults, edit values in place instead of opening a dialog, and treat the mobile layout as the primary one.
Most adoption problems turn out to be friction problems, and removing a step fixes them more reliably than running a training session does.
- 14
Be ready to discard it, and ready to bend it.
In the early period a product changes shape often, so we do not over-engineer the parts most likely to be deleted within six weeks. Once the shape settles the requirement reverses, and the same code now has to change without a rewrite, which is what feature flags, configuration in place of code and third-party components are for. When the business asks for a landing page before an event, I reach for a website builder before I reach for a framework.
- 15
Use the stack you have already shipped with.
When a request arrives, the right stack is usually the one you have already put into production, because prior experience is a delivery multiplier that no benchmark measures. The tool you have been meaning to try can wait for a project without a client deadline attached. Learning is an investment I schedule deliberately, and I do not schedule it inside a client’s launch week.
How we decide
Three rules I apply when the team disagrees, or when I catch myself about to copy something for no better reason than that a larger company does it.
- 16
Do not make the engineer faster; make the path easier.
A lesson from the Toyota production system, paraphrased: the most critical work is the work that smooths the way for other work. Pushing people to type faster returns almost nothing and costs goodwill, while removing the twenty minutes it takes to get a change in front of a real user returns those minutes every day, to everybody on the team.
- 17
Copy the diagnosis rather than the structure.
Stripe’s developer-productivity team is a good answer to Stripe’s problem, and Spotify’s squad model was an answer to Spotify’s problem at a particular moment in its history. What I keep seeing is teams that copy the organization chart, inherit the ceremony that came attached to it, and never once meet the condition that justified either.
Before adopting a practice we write down which failure it is supposed to prevent, and when we cannot name that failure we skip the practice. Stand-up meetings, retrospectives, review gates and sprint boards all pass through the same filter.
- 18
Separate reversible decisions from irreversible ones.
Jeff Bezos’ distinction between one-way and two-way doors is the cheapest management tool I use. Most engineering choices swing both ways, including a naming convention, a retry policy, a batch size or a side panel against a full page, and the engineer settles those in thirty seconds and carries on.
The one-way doors are dropping a column, clearing a table, force-pushing over history, and anything that touches money or personal data. Those stop and get a second pair of eyes every time, however routine the surrounding task happened to feel.
Tools
Three things carry most of our speed. I have listed them in the order they have to be introduced, because I have watched a team put agents on top of an unclear specification and start producing wrong work faster than before.
- 19
Agentic-first, with a background agent for each task.
Our engineers run several coding agents at once, each one in an isolated checkout, each working on a single task and each reading the repository’s own instruction file. A person’s day turns into framing problems, reviewing what comes back and making the decisions that need judgment. This is where most of our speed advantage comes from, which is my assessment from running a team both ways and not a figure I have measured.
It is also the reason the next two principles matter more than they used to. An agent given an unclear specification will produce work that is confident, wrong and delivered at considerable speed.
- 20
Specifications are the source of truth, and people review specifications.
The specification states how the system should behave and the code states what was built, so when the two disagree it is the code that gets corrected. Nobody on our side answers a question about behavior by reading the implementation, and no behavioral change is written before the specification describes it.
Reading a diff line by line is no longer the most valuable use of a senior person’s hour, whereas reading whether the specification describes something the business wants still is.
The caveat I state openly: we still run an automated review over every diff. A specification describes intent, and intent does not catch a missing null check.
- 21
Delivery without a waiting step.
Merging a pull request is what deploys it. Migrations and functions reach production on merge, the frontend follows automatically, and no manual step sits between the two. An automated reviewer takes the first pass over every pull request within a couple of minutes, and the engineer works through its comments before a colleague opens the page at all. Nothing in this pipeline waits for a colleague’s calendar to free up.
The schedule we keep
Clients feel the schedule before they feel the software, so I keep ours fixed. Nobody on the client side should have to ask where the work stands.
- Releases
- Two to three a week, continuously. We cut a release as soon as a piece of customer or product feedback has been covered, so that the next round of feedback starts sooner.
- Sprint showcase
- Every two weeks. Results are locked and shown, so that the sponsor reviews a settled result instead of work in progress.
- Written update
- Weekly for business stakeholders, and daily for the product people working alongside us.
- Product and engineering sync
- Twice a week, covering blockers, customer feedback and changes to a business process or a user flow.
- Working chat
- One channel in Slack or Telegram. Tasks are collected there, written up there, and the plan is posted there.
- Engagement cycle
- One to three months, tied to a business result rather than to a list of features.