Methodology
Most delivery failures are communication failures wearing a technical costume.
The build is rarely the hard part. What breaks a program is that the people who must decide, the people who must use it, and the people who must certify it are working from three different accounts of the same system — and nobody has noticed.
Back when I thought letters behind my name were the most important thing, I went deep into technical communication and rhetoric in pursuit of the Ph.D. Priorities shifted. I completed all the coursework, then made the hard decision to set the degree aside in favor of practicing the discipline inside the work rather than certifying it.
That training is not decoration on a technology résumé; it is the reason I look at a stalled implementation and start with who is being asked to believe what, on what evidence. The frameworks below are the tools I reach for at each scope. They are not a menu. They nest.
Five scopes
| Scope | What actually goes wrong | Instrument |
|---|---|---|
| The person | The same report lands as reassurance for one executive and as an alarm for another. | Audience analysis · type as vocabulary |
| The team | Everyone agrees in the room and nothing is owned when they leave it. | Lencioni’s five dysfunctions |
| The delivery system | Teams ship on cadence and the increments still do not add up to a release. | Scaled agile, applied at the weight the org can carry |
| The organization | Level 4 practices get prescribed to a Level 1 shop, and the process is blamed. | CMMI maturity, read honestly |
| The obligation | Compliance arrives as a PDF after the architecture is already set. | Controls as code, in the build |
Before any framework
The question does more work than the diagnosis.
Coaching practice calls them powerful questions: open, short, and not secretly an argument. A consultant who arrives with the answer gets told what the room thinks the answer should be. A consultant who arrives with better questions finds out what people have been unwilling to say in front of each other — which is almost always where the real constraint lives.
- What would have to be true for this to work?
- Who is harmed if this is wrong, and how would we find out?
- What has already been tried here, and what did it cost?
- Which of these constraints is real, and which is a habit?
- If we do nothing for a year, what happens?
Reading the room is a technical skill.
Rhetoric gives this a working vocabulary: audience, purpose, constraint, and timing. The same architecture decision needs three documents — one that lets a CFO approve spend, one that lets an engineer implement without guessing, one that lets an auditor trace a control. Writing one and hoping it serves all three is the most common unforced error I see.
Type language — the Myers-Briggs vocabulary of how people prefer to take in information and reach decisions — is useful for the same reason a style guide is useful: it gives a team words for a real difference instead of attributing it to bad faith. I use it as vocabulary, never as a filter. It does not belong in hiring, staffing or evaluation, the psychometric literature is genuinely mixed on its reliability, and anyone who tells you a four-letter code predicts performance is selling something.
A team that cannot argue cannot commit.
Lencioni’s sequence is the most useful thing I know about why good plans die. Absence of trust produces artificial harmony; artificial harmony produces meetings where nothing is contested; uncontested decisions are never really agreed to; unagreed decisions cannot be enforced peer to peer; and results become whatever each group was already optimizing for.
The diagnostic is cheap. Watch where the real conversation happens. If the substantive disagreement occurs in the hallway after the meeting, you do not have a process problem that a new tool will fix — you have a trust problem, and installing software on top of it will produce an expensive record of the same avoidance.
Scaled agile is a coordination tax. Pay it deliberately.
I have coordinated delivery across multiple agile teams at a scale where the teams themselves were no longer the problem — the seams between them were. That is the actual case for a scaled framework: shared cadence, a planning event where dependencies get named out loud by the people who own them, and a backlog above team level so that sequencing is a decision rather than an accident.
It is also heavy, and it is oversold. Adopted whole by an organization that has not earned it, a scaled framework becomes ceremony that produces status rather than software. The judgment is which parts to take. Most groups I work with need the dependency conversation and the shared cadence long before they need the full apparatus, and some never need the rest of it at all.
Maturity is a measurement, not an aspiration.
CMMI’s ladder — initial, managed, defined, quantitatively managed, optimizing — earns its keep as an honest mirror. Nearly every organization believes it is one level higher than its artifacts support. The test is not whether a documented process exists; it is whether the same work produces the same result when a different person does it under pressure.
This is where the other frameworks get calibrated. Prescribing quantitative process management to a group that cannot yet repeat a release is how methodology gets a bad name. Read the level first, then choose the intervention that the next level actually requires — and be willing to say that the answer is one rung, not four.
The floor
Compliance is an architecture problem that arrives disguised as paperwork.
Every obligation below is cheap to satisfy while the system is being designed and punishing to retrofit afterwards. That timing is the whole point.
- Privacy
- FERPA in a student system, GDPR and state privacy law in a SaaS platform. Data minimization is an architecture decision, not a policy sentence — you cannot retroactively not collect something.
- Fair housing
- In multifamily, the Fair Housing Act reaches screening logic, pricing models and ad targeting. A model that never sees a protected class can still proxy for one; the defense is documented feature review and testing for disparate impact, before launch.
- Data integrity
- Tamper-evident audit trails, immutable event logs, and reconciliation that runs whether or not anyone is looking. If you cannot prove what a record said last Tuesday, you do not have an audit trail.
- Cybersecurity
- Least privilege and fail-closed defaults, so an outage denies access rather than granting it. The interesting question is not whether you are breached but what an attacker can reach once they are inside.
- SOC 2
- The audit tests whether controls operated over a period, not whether they exist today. Controls that emit their own evidence turn the annual scramble into a query.
- ISO
- 27001 for the information security management system; 42001 where AI is in the decision path and someone will eventually ask how the model was governed.
The practice I hold to: guardrails belong in the architecture, not in a binder. Policy expressed as code, defaults that fail closed, and audit that is a by-product of the system running rather than a report somebody assembles. Done that way, an audit stops being an event and becomes a query — and the honest answer to “are we compliant?” stops depending on who you ask.
What this looks like in an engagement.
I start by watching the work happen and asking the questions above. I read the maturity level off your artifacts rather than your org chart. I find out where the real disagreement lives. Then I recommend the smallest change that moves the constraint — which is often not software, and I will say so before you pay me to build any.