One Opinion on the DBJ Method

Analysis of the actual content and philosophy encapsulated in the opinion (of the “secret admirer”) abut the DBJ Method Shop. 1. Organizational Topology When you actually look at what is “for sale” in the DBJ shop, the “genius” is that the inventory consists of organizational structures and strict mandates. You are not “buying” a framework; you are buying a blueprint for a two-tiered topology: The Architecture Function: A small, highly empowered, strictly non-delivering team. Their only job is to define the boundaries, the interfaces, and the core domain models. Actually not ever explicitly mentioned. The Delivery Function: The stream of teams whose only job is to deliver inside the “domains” drawn by the BPT Operational Methodology; scrutinized by the Architecture Function. The shop metaphor works because it forces management to realize these are distinct “components” that must be “shopped” together in a specific way. You cannot mix them against the flow of B=P-T. If you let deliverers define architecture, the flow is broken. ...

Do we have the right set of skills

IMPORTANT One Liner Summary: skill.md is not guaranteed to be used DBJ Observations and Comments Observation: runtime infrastructure is not deployment infrastructure Agreed, so what? In the era of the general lack of experienced engineers that has to be said. Plainly. Observation: Skill is key problem is, it is keeping the whole agent scaffolding non-deterministic It’s not Skill, it’s the mechanism that is supposed to use the Skill. Fuzzy natural-language matching against a description, decided by the model at invocation time rather than part of a fixed dispatch. same mechanism is what makes deferred-tool loading (ToolSearch), subagent selection. Also the ordinary tool choice (Grep vs Read vs Agent) is then non-deterministic too. Skills are just the most visible facet of the LLM non-determinism because they’re named and listed explicitly. But skills are used non deterministically. The classical-software analogue is late binding / reflection-based plugin dispatch Skill mechanism is trading a fixed call graph for runtime flexibility, and paying for it in determinism lacking. Repeating. It is not “Skill” that is the problem, it is that harness resolves most capability binding (skills, tools, subagents, memory recall) via probabilistic matching instead of a deterministic dispatch table And that’s a structural feature of the whole LLM architecture, not a flaw isolated to the Skills. There is no deterministic table dispatch. It is as simple as that IMPORTANT The Message ...

Accidental Nodes of Super Densities

Do you prefer the calm and ordered B-P-T operational model to “Accidental Nodes of Super Density”? We prefer the order of B-P-T Challenging Accidental Nodes of Super Densities This is how we call this very dense possibly emerging team shape. All the ad-hoc, all the time. Communication pattern home grown here (in a ad-hoc manner) is: all is talking to all, at once all the time. Probably proud of Slack presence. And that includes the Agents too. ...

BPT Birth In One Image

That’s not a joke about forever confused CEO. It’s the default state of most AI hopefuls. The Perpetual State of Confusion Every vendor pitch, every all-hands, every roadmap slide is full of words everyone nods at: “agentic,” “AI-native,” “transformation.” Nobody stops the meeting to ask what they actually mean for this business, this process, this P&L line. So the nodding continues. Budgets get approved. (AI) Pilot gets funded. And six months later, nobody can explain why the thing doesn’t work — because nobody could explain, at the start, what “working” was supposed to look like. ...

The Business Ship Manual

The Flight Plan and the Autopilot The elusive goal of the “Competitive Advantage” What will “give” the “competitive advantage” is the Operational model, in order to navigate the whole organization around that huge iceberg of legacy. https://method.dbj.org/shop/ OP model introduction is not simple. But its worth it. Especially if organization is small(ish) and not too calcified. Just decide on one OP model, implement it and follow it. AI or no AI. ...

The Danger-Kruger Peak

There’s a ladder. The rungs are labeled “AI Competence.” A novice climbs it, rung by rung, using a critical shortcut: “I didn’t learn, but the AI did.” It works. For a while it works great. The climb is fast, the view improves with every step, and the effort-to-altitude ratio feels like magic. Then the ladder ends. Not because the climber ran out of energy — because the ladder did. That point is the Danger-Kruger Peak: the spot where AI hallucinations start looking exactly like wisdom, because the climber has no competence of their own left to tell the difference. ...

Remember the Unicorn?

The unicorn is still there. Exactly where it always was. But. Nobody is looking. Under the avalanche of AI Slop A goat walked to the side of the moat and it’s fine up there — visible, unremarkable, good enough. The goat didn’t defeat the unicorn. It is just vibed up in greater numbers, at lower cost, faster than anyone could count. That might be the epitome of the AI slop. Not malicious. Not even bad. Just sufficient — produced at a volume and velocity that makes discernment feel like an unaffordable luxury. (yes I used that word) ...

Fake It Until You Make It: Coding Monkeys vs. AI Architects

Two teams. Same deadline. Different disasters. On the left: the coding monkeys. Keyboards rattling, errors scrolling, “It’s working! Maybe—” before the SHIP IT NOW and the inevitable ERROR. Fast. Confident. Wrong. On the right: the AI architects. Whiteboards full, meetings scheduled, not a single line written yet. “Don’t even start without four weeks on the spec.” Safe. Thorough. Also wrong. The cartoon is funny because both rooms exist in every organization that has ever touched software. ...

What You Are Looking For Is Optimal Implementation

The senior engineer looks at the problem. Builds a mental model. Writes code that is simple and correct. Looks at it again, knows it’s right, moves on. The AI agent generates. Evaluates. Regenerates. Evaluates again. Tries a variation. Stumbles into something that passes the tests. Maybe. Same output, different paths. And the path matters — not for sentimental reasons, but for practical ones. What optimal actually means Optimal implementation is not the cleverest solution. It’s not the most elegant one. It’s the one that is correctly scoped to the problem, legible to the next person who touches it, and arrived at deliberately rather than by exhaustion of alternatives. ...

AI on an Old Operating Model

A Ferrari V12 engine dropped into a wooden farm cart. That is not satire. That is the exact situation most organizations are in right now. The engine is state-of-the-art. The cart is nineteenth century. The wheels are wooden. There is no drivetrain, no chassis rated for the load, and nowhere to sit. The moment you open the throttle, the cart disintegrates. What “AI Ready” Actually Means AI-readiness is not a technology procurement question. It is not about which model you license, which cloud you use, or how many GPU hours you can afford. Those are secondary. ...