Excerpt of my new upcoming book: Vertical Velocity!

How to Break Silos, Ship Faster, and Reclaim Engineering Joy 

The Resource Utilization Trap (The 100% Busy Fallacy)

In many corporate cultures, "slack time" is treated as an existential sin. Managers obsess over ensuring every developer is $100$ utilized. If a backend developer finishes their tasks early, they are immediately assigned another ticket. If a QA engineer has downtime while waiting for a build, they are given manual regression scripts to run.

This philosophy—maximizing resource utilization—makes intuitive sense to someone managing a factory floor. But software engineering is not a factory floor. It is not a manufacturing line of physical, predictable goods; it is a creative network of highly variable cognitive work.

Optimizing an organization for resource utilization systematically destroys flow efficiency—the percentage of time a feature actually spends being worked on, as opposed to waiting in line.

To visualize this, think of a local highway.

• When highway utilization is $50$, cars can move at the maximum speed limit. If one car changes lanes or taps its brakes, the system absorbs the variation. Flow efficiency is high.

• When highway utilization reaches $90$, traffic slows to a crawl. The slightest variation—a minor lane merge—creates a cascading shockwave of brake lights that travels miles backward.

• When highway utilization is $100$, the highway is perfectly "utilized." Every square foot of asphalt is covered by a vehicle. But the speed is $0\text{ mph}$. You have built a parking lot. No value is being delivered to anyone.

In siloed organizations, software delivery functions exactly like a $100$ utilized highway. Because every engineer is fully booked, there is zero buffer capacity. When a frontend developer needs a minor backend change to unblock their task, they cannot get it immediately. The backend developers are $100$ booked with their own sprint commitments. The request is placed in a backlog—a queue—where it sits idle, waiting for capacity to free up.

By maximizing resource utilization, we minimize delivery speed.

The Mathematics of Congestion (Kingman’s Formula)

The highway isn't just an analogy. Queueing theory gives us the exact math. Kingman's Formula (specifically Kingman's approximation for average waiting time in a single-server queue) shows why:

$$E[W]\approx \left(\frac{\rho }{1-\rho }\right)\cdot \left(\frac{C_a^2+C_s^2}{2}\right)\cdot E[S]$$

Where:

• $E[W]$ is the average waiting time (queue delay).

• $\rho$ is the resource utilization level ($0\le \rho <1$).

• $C_a$ is the coefficient of variation for arrivals (how unpredictably work arrives).

• $C_s$ is the coefficient of variation for service times (how unpredictable the work is to complete).

• $E[S]$ is the average service time (how long it takes to actually write the code).

Source: Donald G. Reinertsen, The Principles of Product Development Flow (2009)

Look closely at the first term of this equation: $\frac{\rho }{1-\rho }$. This is a non-linear relationship.

If we plot the average waiting time ($E[W]$) against utilization ($\rho$), the curve is relatively flat until it crosses the $70$ mark. Beyond $80$, the curve bends sharply upward. At $90$ utilization, the waiting time explodes. At $99$, it approaches infinity.

In software delivery, variation ($C_a$ and $C_s$) is naturally high. We rarely build the exact same feature twice, meaning we cannot precisely predict how long a task will take or when unexpected bugs will arrive.

📋 What this means: When utilization exceeds 80%, waiting time grows exponentially. The more unpredictable your work, the worse it gets.

Because our variation is high, Kingman's formula dictates that any organization operating near $90$ resource utilization will experience massive, systemic queue delays. If a feature has to traverse four different horizontal teams, and each of those teams is operating at $90$ utilization, the feature will spend over $90$ of its lifecycle waiting in queues.

Vertical feature teams solve this math problem. By bringing all necessary disciplines into a single pod, we drastically reduce the number of handoffs. When you eliminate the handoffs, you eliminate the queues, shifting your delivery speed back down to the flat, fast end of the Kingman curve.

Stop Breaking Your API with Primitive Drift: A Guide to Semantic Type Modeling

If you’ve ever debugged a weird rounding error in a financial transaction or watched a perfectly good API fail because a description field suddenly allowed emojis, you’ve already met the problem this article solves.

It’s called Primitive Drift, and it’s quietly destroying your API reliability.

Let me show you how to fix it using Semantic Type Modeling —and why your E2E tests are probably making things worse.

The Problem: When Strings and Numbers Become Liabilities

Most API designs start simple. You map a business concept directly to a JSON primitive:

description:
  type: string
price:
  type: number

Seems harmless. But over time, this causes three predictable disasters:

1. Inconsistent rules – One team limits descriptions to 250 characters. Another allows 1000. Good luck explaining that to customers.
2. Financial fraud, literally – Floating-point numbers can’t represent cents exactly. 0.01 + 0.02 isn’t always 0.03. Attackers exploit this for fractional-cent theft.
3. Leaky security – Each microservice reinvents XSS or SQL injection validation. Gaps appear. Compliance fails.

The solution isn’t more E2E tests. It’s a single source of truth for what your data actually means.

Semantic Type Modeling: Treat Data Like a Business, Not a Compiler

Instead of seeing string, see ItemDescription. Instead of number, see Money.

You define the rule once:

ItemDescription:
  type: string
  minLength: 10
  maxLength: 500
  pattern: '^[a-zA-Z0-9\s.,!?()"-]+$'

Then everywhere else, you just reference it:

description:
  $ref: './domain-types.yaml#/components/schemas/ItemDescription'

That’s it. One change propagates everywhere. No drift. No debate.

The Architecture: How It Stays Enforced (Without Nagging)

You don’t need a committee to enforce this. You need automation.

• Central Domain Library – A single YAML file (domain-types.yaml) holding every canonical business type.
• API specs – Each endpoint references types from that library using $ref.
• CI/CD linter – Tools like Spectral block any PR that uses a raw primitive where a domain type exists.
• API Gateway – Rejects malformed payloads at the edge, before they touch your backend.

Result: Developers get instant feedback, not a broken pipeline hours later.

Why E2E Tests Are the Wrong Hammer for This Nail

I see teams fall into the E2E Test-Driven Specification anti-pattern all the time:

“We don’t know what the API expects, so we’ll throw payloads at staging, see what breaks, and write a test to lock in that behavior.”

That’s expensive, slow, and fragile.

Bug-Driven Loop	Semantic Modeling Loop
Write code → Deploy → Run slow E2E → Fail → Fix → Re-deploy	Write schema → Linter flags error instantly → Fix → Done
Hours to days	Seconds

If a business rule changes (e.g., SKU format lengthens), bug-driven teams rewrite dozens of E2E tests. Semantic teams change one line in domain-types.yaml.

Shift Left: Make Validation an IDE Feature, Not a CI Surprise

Give developers local mock servers (like Prism) and OpenAPI validators. When they send a bad payload during development, they get an immediate 400 Bad Request with a precise error:

body/description must match pattern ^[a-zA-Z0-9\s.,!?()"-]+$

No waiting. No guessing. No staging environment required.

When E2E Tests Are Still Useful (And When They Aren’t)

Educate your team on the testing pyramid:

• Contract validation → OpenAPI + linter (zero cost)
• Integration/unit tests → business logic like discount calculation (low cost)
• E2E tests → user journeys, multi-system flows (high cost)

If your E2E test fails because a field was an integer instead of a string, delete that test. That constraint should have been caught before the code was compiled.

But What About Cross-Field Logic? (“If A then B required”)

Developers often argue: “Sure, single-field validation works, but what about conditional rules? That needs an E2E test.”

That argument is outdated. Modern JSON Schema (OpenAPI 3.x) supports oneOf, allOf, and conditional logic natively.

Example: If payment method is CREDIT_CARD, require card details. If PAYPAL, require a redirect URL.

OrderPayload:
  type: object
  required: [orderId, paymentMethod]
  properties:
    orderId: {type: string}
    paymentMethod: {type: string, enum: [CREDIT_CARD, PAYPAL]}
  allOf:
    - if:
        properties: {paymentMethod: {const: CREDIT_CARD}}
      then:
        required: [cardDetails]
    - if:
        properties: {paymentMethod: {const: PAYPAL}}
      then:
        required: [paypalRedirectUrl]

No E2E test needed. The schema enforces it directly.

How to Roll This Out Without Causing a Rebellion

Phase 1: Audit
Look at your existing E2E suite. Flag every test that checks a simple field constraint (description too long, price negative).

Phase 2: Migrate
Move those constraints into domain-types.yaml. Add Spectral to your CI pipeline.

Phase 3: Delete
Remove those E2E tests. Watch build times drop.

Phase 4: Enforce
Make updating the OpenAPI schema a prerequisite for starting development on any feature that touches data shapes.

The Bottom Line

Semantic Type Modeling isn’t just cleaner — it’s faster, safer, and cheaper.

• API gateways reject attacks at the perimeter
• SDKs auto-generate correct validation code
• Documentation stays accurate without manual updates

Stop reverse-engineering your own API. Start modeling what your business actually means.

Your future self (and your on-call rotation) will thank you.

---

Want the full OpenAPI examples and Spectral rules? Check out the companion repo [link].

Agile Working Agreement that Works

Let’s be honest: we’ve all been there. The Daily Stand-up that devolves into a 45-minute debugging session. The Sprint Planning that drags on so long you forget what you were planning to build. Or the dreaded "Demo Day Disaster," where the Backend team hands over an API only for the Frontend team to realize the data structures don't match.

It doesn’t have to be this way. High-performing teams don’t just "do Scrum"—they build a Working Agreement.

Think of this as your team’s constitution. It isn’t about corporate bureaucracy; it’s about protecting your "flow state," respecting each other’s time, and ensuring that "Done" actually means "Shippable." Here is a battle-tested Working Agreement designed for modern, cross-functional teams.

---

1. Meeting Etiquette: Principles for Productive Flow

If you want productive ceremonies, you must start with a foundation for mutual respect.

• The 2-Minute Rule: If a deep technical debate breaks out during a Stand-up, pause it. If it lasts longer than 120 seconds, move it to the "parking lot" to be discussed by the relevant parties immediately after the meeting.
• Camera On (Remote Teams)? Cameras are mandatory for Sprint Planning and Retrospectives - these require high emotional intelligence and engagement. For the Daily Stand-up? Optional. We trust you’re focused.
• Punctuality is Non-Negotiable: If Stand-up starts at 10:00 AM, we start at 10:00 AM. If you are late, you owe the team a "coffee debt" or a quick lightning talk on a topic of your choice at the next Retro.
• No "Second-Screening": Put the distractions away. If you need to answer a Slack message, 

do it before or after the ceremony. Multitasking is the enemy of a 15-minute meeting.

Ceremony Cheat Sheet:

• Sprint Planning: 2–4 hours (Once per Sprint)

• Daily Scrum: 15 mins (Daily)

• Backlog Refinement: 1-2 hours (1–2x per Sprint)

• Sprint Review: 1-2 hours (Once per Sprint)

• Retrospective: 1-1.5 hours (Once per Sprint)

2. Refinement vs. Planning (They Are Not the Same)

Teams often fail because they try to do two different jobs at once.

• Backlog Refinement (The "Look Ahead"): This is not about committing to work; it is about "DEEP" grooming (Detailed, Estimated, Emergent, and Prioritized). Split this into two 1-hour sessions per sprint. This gives the Product Owner time to find answers to technical blockers before the actual Planning starts.

• Sprint Planning (The "Commitment"): The team selects items from the already refined backlog.

• The Golden Rule: If Sprint Planning takes 4+ hours, your Refinement failed. When Refinement is done well, Planning should be a smooth "select and commit" process that takes under 2 hours.

3. The Perfect 2-Week Sprint Calendar

For those who need a visual rhythm, here is your standard cadence:

• Day 1 (Monday AM): Sprint Planning.

• Daily: Stand-up (same time, every day).

• Day 4 or 5: Refinement Session #1 (Mid-sprint check).

• Day 8 or 9: Refinement Session #2 (Finalizing the "Ready" state).

• Last Day (Friday PM): Sprint Review (Demo) → Immediately followed by Retrospective.

Pro-Tip: Use "Hard Stops." If a Retrospective is scheduled for 60 minutes, end it at 60 minutes. Timeboxing forces the team to prioritize the most important issues rather than venting about minor ones.

4. The Holy Grail: Unified Planning for Cross-Functional Teams

This is where most cross-functional teams break down. To stop the "Silo Effect" between Backend (BE) and Frontend (FE), adopt these three habits:

The "Interface-First" Approach

Before a single line of code is written, BE and FE engineers must agree on the API Contract (the JSON structure). Once this "handshake" is defined, the FE team can build using mock data while the BE builds the logic. No one waits for anyone.

The "One-Sprint-Ahead" Design Rule

UX/UI Design is not part of the current sprint’s development; it is part of Refinement. If a story’s design isn't finalized by Planning, that story is not "Ready" and does not enter the sprint.

The "Three Amigos" Flow

During planning, use this three-phase approach for every story:

• Phase A (The Vision): The Product Owner explains the "Why" and "What."

• Phase B (Technical Alignment): BE and FE engineers draft the contract together and identify architectural hazards.

• Phase C (Sub-Tasking): Break the story into specific tasks (e.g., Task 1: Define API Contract; Task 2: Build logic; Task 3: Integration testing).

5. Shared Planning vs. Split Planning

Shared Planning (The Goal)	Split Planning (The Risk)
Early Integration: Interfaces are discussed upfront.	Late Integration: Bugs are discovered on Day 9.
High Context: Everyone understands the full stack.	Black Boxes: Teams don't know what the "other side" is doing.
Shared Accountability: The team wins or loses together.	Finger-Pointing: "The API is broken" vs. "The UI is wrong."
Parallel Work: FE uses mocks to start immediately.	Linear Work: FE waits for the BE to finish.

One final tip: If the Backend team needs a deep 10-minute architecture huddle that the Frontend doesn't need to hear, use a breakout group. Huddle for 10 minutes, then "regroup" and explain the final plan to the other half.

Summary

A good Working Agreement isn't about control—it’s a shield against chaos. It protects the developers' focus, the Product Owner’s roadmap, and the customer’s need for reliable software.

Your action item for tomorrow: Share this with your team. At your next Retrospective, ask: "Which one of these rules are we breaking the most?"

Fix that one thing first. Your velocity will thank you.

Stop Starting. Start Finishing.

How to Make Your Agile Process More Predictable (and Save Your Sanity)

Let’s be honest for a second.

How often do you hear—or ask—these questions?

• “When will this feature actually be done?”
• “How many features can we ship next release?”
• “Why does everything feel chaotic even though we’re ‘doing Agile’?”

If that sounds familiar, you’re not alone. But here’s the hard truth: most teams struggle with predictability not because they work slowly, but because they start too much.

It’s time to stop starting, start finishing.

Your Agile Process Is a Queue (Really)

Every Agile process—Kanban, Scrum, or hybrid—can be modeled as a simple queuing system:

Arrivals → System (work being done or waiting) → Departures

That’s it. But here’s the catch:
To make that system predictable, you need two crystal-clear moments:

1. A clear arrival point (when work is truly “started”)
2. A clear departure point (when work is truly “finished”)

Without those, you’re flying blind.

The Three Metrics That Matter

You don’t need 27 dashboards. You need three core metrics:

Metric	What it means
WIP (Work in Progress)	Count of items started but not finished
Cycle Time (CT)	Time from start to finish for one item
Throughput (TH)	How many items you finish per day/sprint

And one powerful formula:
WIP = CT × TH

Want shorter cycle times? Lower your WIP.
Want higher throughput? Lower your WIP.
WIP is the lever that controls almost everything.

Cycle Time vs. Age – A Critical Distinction

• Cycle Time applies to finished items. It’s the total elapsed time from start to finish.
• Age applies to unfinished items. It’s how long a started item has been sitting in progress.

Why does this matter?
Because aging is bad. Every day an item ages without finishing, you delay customer feedback. And delayed feedback is wasted learning.

Cycle time isn’t just a metric. It’s a measure of how fast you get validated feedback from real users.

Two Ways to Prevent Aging

You can’t stop aging once an item is in progress… unless you do one of two things:

1. Finish it (obvious, but hard when you’re overloaded)
2. Don’t start it (less obvious, but more powerful)

That second one is the secret sauce.
Don’t start work unless you are truly ready to finish it quickly.

This is why controlling WIP isn’t a micromanagement trick.
The real reason to control WIP is to prevent unnecessary aging.

Throughput, Not Velocity

A quick but important note:
Many teams track velocity (story points per sprint). But story points are subjective. Throughput is not.

Throughput = number of work items completed per unit of time
(e.g., “We finished 7 stories last sprint”)

Throughput is honest. It doesn’t care if a story was a 3 or an 8. It just counts finished work.

And throughput, combined with cycle time and WIP, gives you something priceless: predictable outcomes.

What Should You Track?

You don’t need a complex data science project. Start here:

• WIP – Keep it small
• Cycle Time – Measure it per epic/story/task
• Throughput – Count finished items (epic/story/task) per sprint
• Age – Watch for aging items like a hawk

When you control WIP, cycle time becomes reliable.
When cycle time is reliable, throughput becomes predictable.
When throughput is predictable, your team stops guessing and starts delivering.

The Bottom Line

You can’t answer “when will it be done?” with wishful thinking.
You answer it with data. And that data comes from finishing work, not starting more.

So take a hard look at your board today.
How many items are “in progress”?
How many have been sitting there for over a week?
How many did you start but never finished?

Then say it out loud:

Stop starting. Start finishing.

Your team (and your product owner) will thank you.

---

Want to dig deeper? Start tracking your WIP, cycle time, and throughput for two sprints. You’ll be amazed at what you learn.