This guide assumes:

• Familiarity with Conway’s Law. Read What Is Conway’s Law? first if “communication structure shapes system structure” sounds new.
• You work on or with a platform team. This means a team that owns shared infrastructure consumed by multiple product teams.
• Visibility into platform PR queues, product-team workflows, and meeting calendars. Without these signals, you cannot measure friction.
• Influence over platform priorities, or a partner who has it. The fixes below require changing what the platform team does, not what product teams ask for.

Measure the friction budget

Platform teams own shared infrastructure that many product teams depend on. Heavy edit volume across multiple teams is normal. Slow shipping and burned-out engineers are not.

This guide assumes:

• Familiarity with Conway’s Law. Read What Is Conway’s Law? first if “communication structure shapes system structure” sounds new.
• Access to git history. You will read commit patterns over the last quarter.
• Visibility into the org chart. You need to know which engineers belong to which teams.
• Influence over team boundaries, or a stakeholder who has it. The fixes below require organizational change, not technical work.

Read the alignment

Conway’s Law works both directions. Observe the code, and you can infer the organization. Use that to understand where the org is healthy and where it is broken.

This guide assumes:

• Familiarity with Conway’s Law. Read What Is Conway’s Law? first if “communication structure shapes system structure” sounds new.
• Concrete evidence from your own org. A diagnosis from How Do I Diagnose Delivery Friction? or a deployment decode from How Do I Decode a Deployment? gives you the artifacts to point at. Without evidence, the pitch sounds like opinion. Start there if you have not yet.
• An audience. Architects, product leaders, your own team, an open-source community, or conference attendees. The pitch shifts with each.

Bring both halves to every conversation

Most conversations about software architecture skip the organizational layer entirely. Engineers debate microservices versus monoliths. Leaders debate team structure in isolation. The two conversations rarely connect. Use Conway’s Law to make the connection explicit.

This guide assumes:

• Familiarity with Conway’s Law. Read What Is Conway’s Law? first if “communication structure shapes system structure” sounds new.
• A local clone of the repository you want to analyze. The diagnosis below is a git query.
• A POSIX shell with awk, sort, uniq, and cut. Standard on macOS and Linux.
• Visibility into the org chart. You need to map author emails to teams.

Rank the congestion candidates

Start by looking at the slowest, most contentious modules. Files with commits from many different authors over the last quarter signal congestion.

This guide assumes:

• Familiarity with Conway’s Law. Read What Is Conway’s Law? first if “communication structure shapes system structure” sounds new.
• Access to the deployed system. You need to see the service list, runbooks, and on-call rotations.
• Visibility into pipelines and release boundaries. You need to know which services ship together and which ship separately.
• A blank document or whiteboard. You will sketch a map as you go.

Walk the deployment

Treat deployed software like a fossil record. Every service boundary, API contract, and deployment pipeline carries the imprint of the people who shipped it. Walk the deployment in this order:

You redraw the org chart. Six months later, the codebase has grown new seams along the new team boundaries. The teams reshaped the software without intent.

That pattern has a name: Conway’s Law. Any system you ship will reflect the communication structure of the people who built it. Modules align with teams. Interfaces form along reporting lines. Coordination friction shows up as code friction.

This matters because technical leaders keep treating organizational problems as technical problems. A microservice split fails when two teams still own a single service. A monorepo grows congested because four teams edit the same file. The architecture is doing exactly what the org chart told it to do.

Cloud bills are scrutinized to the cent. AI coding tool spend analysis is complex, with token-based pricing, multiple subscriptions, and quick pilots hiding total costs until reviewed by finance.

I first heard about Ollama when a colleague mentioned running GPT-like models on a laptop. My first reaction was the same one most engineers have: you can do that?

The short answer is yes. Ollama makes it possible to run large language models locally on consumer hardware. You need only a Mac, a PC, or even a Raspberry Pi and a few minutes to pull a model.

Ollama is an open source tool for running large language models on your own hardware. It wraps llama.cpp, a highly optimized C++ inference engine, and exposes a simple API that mimics the OpenAI chat endpoint. You pull models with a single command, talk to them with curl or any SDK, and the system handles GPU acceleration, memory management, and model loading automatically.

Why do some technical teams ship great work while others stall in indecision, drama, and rewrites? The difference is rarely talent. It’s leadership.

Technical leadership is the practice of using deep technical judgment plus people skills to set direction, make hard calls, and help a team do its best work. A technical leader is not always a manager. The role can be a tech lead, staff engineer, principal, architect, CTO, or a founder who happens to write code. What unites them is influence rooted in credibility, not authority handed down from an org chart.

Then I found fzf, and file selection stopped being a chore. fzf is a fuzzy finder that turns file selection into a fast, interactive search.

Then I installed zoxide, and cd started reading my mind.

What zoxide actually is

Zoxide is a smarter replacement for cd. It watches where you go in your terminal, ranks those directories by how often and how recently you visit them, and lets you jump to any of them by typing a fragment of the path.

Claude Code works at a different level. It runs in my terminal, reads my files, runs my commands, and talks back in plain language. When I ask it to fix a failing test, it runs the test, reads the failure, finds the bug, edits the file, and runs the test again to confirm. The result feels less like autocomplete and more like delegating a small task to a teammate.

What is Nwave?

Nwave is an agentic AI software delivery methodology that runs inside Claude Code. It slices the work of shipping a feature into six ordered waves, assigns a specialized agent to each wave, and stops for a human review between waves.

Most of the math powering today’s large language models comes from the 17th and 18th centuries. Calculus, linear algebra, probability theory. The machines caught up to the math, not the other way around.

I picked up Why Machines Learn by Anil Ananthaswamy because I wanted to understand what actually happened, not the hype version. The book traces the mathematical lineage from early pattern recognition through deep learning with the kind of rigor and storytelling that made me rethink how I understood the whole field.

I spent years thinking about accessibility as a human problem. Semantic HTML for screen readers. Keyboard navigation for motor disabilities. Color contrast for low vision. Then agents showed up, and I realized they have the same problem users with assistive technology have always had: your software wasn’t built for how they interact with it.

Agent accessibility means making your APIs, interfaces, and software products usable by AI agents. Not just “technically callable,” but genuinely usable: discoverable, predictable, and self-describing. An agent hitting your API faces the same fundamental challenge a screen reader faces on a webpage. Both need structure, semantics, and predictability to do their job.

Distributed systems fail at the boundaries between services. A single user request crosses many network hops, each with different latency, failure behavior, and ownership. Without shared traffic controls, every team invents its own retry logic, timeout values, routing rules, and access policy. That creates inconsistent behavior, hidden coupling, and outages that are hard to contain.

This is the problem control planes and service meshes are built to solve. A control plane gives teams one place to define traffic policy, and the data plane enforces that policy on real requests. Sidecars and mesh proxies make resilience and security rules consistent across services without forcing every application team to reimplement network logic.

If I’d ridden a bucking bronco like I fantasized about as a kid it would serve as a clean overlaid transposition of my mind with my ass. 🐂 🤠

I first used a GenAI coding tool in October 2021, when I was added to the GitHub Copilot Technical Preview. It was interesting, but barely better than IntelliSense—which is a tool collecting dust in my garage now that I think about it. I continued using it and as its performance improved it became my daily driver while continuing to use Neovim to get my digits dirty.

Early in my career, I led a team that performed repetitive file updates for customer web servers, consuming their entire day. I had a bright idea and asked our local Perl developer to automate their tasks. A couple of weeks later, a few magical scripts emerged, saving hundreds of hours, and my love of programming was born.

Software automation replaces manual, repetitive tasks: building code, provisioning servers, testing, deploying. Machines run the repetitive steps; people keep judgment calls. That cuts cost and the errors humans introduce in rote work.

Clippy would pop up on the first run of Microsoft Word and Excel, with a friendly intent of helping you use the products. Its most consistent features included being wrong and unhelpful. If the software industry had used user behavior metrics back then, the Clippy disable button would likely have been the most-used feature in Microsoft products.

Most programs start as a single sequence of instructions. That works until the program needs to wait for something (a network response, a disk read, user input) or until the work is large enough that a single processor core can’t finish it fast enough.

Concurrency and parallelism are different responses to that problem. Concurrency is about managing multiple things at once. Parallelism is about doing multiple things at once. They overlap in practice, but confusing them leads to designs that are either needlessly complex or slower than expected.

You add more cores. The program gets faster. Keep adding, and gains shrink. Eventually, speed stops rising.

That ceiling has a name: Amdahl’s Law. It gives the maximum speedup from parallelizing a program, given how much work must still run sequentially.

This matters because it prevents wasted effort. Teams add hardware expecting a linear speedup, then hit diminishing returns. Amdahl’s Law explains why and points you to the bottleneck that actually needs work.

Why do some organizations connect five systems in a week while others spend months wiring up two? The difference is rarely the technology. It is understanding how integration actually works and choosing the right approach for each situation.

Software systems integration connects separate systems, so they exchange data and coordinate behavior. Every non-trivial organization runs multiple systems, and those systems need to talk to each other. A customer record created in one system should be visible in another. An order placed on a website should reach the warehouse. A payment processed by one service should update the ledger.