The book lays out four team types (stream-aligned, enabling, platform, and complicated subsystem), three interaction modes (close collaboration, X-as-a-service, and facilitating), and a core principle: cognitive load should drive how you scope a team's mission. Most of it mapped to things I'd already lived through.

Architecture first, then teams

On one project, a team collaboration product, I was one of the founding engineers and helped decide how the squads were drawn up. Instead of letting the org chart shape the system, we identified the business domains first (messaging, notifications, user profiles, spaces, search) and built cross-functional squads around each. Every squad owned their domain end-to-end: front-end, back-end, deployment. No hand-offs to another team. Microservices were the implementation detail, but the real decision was aligning team boundaries to business domains. The team structure followed from that, not from the org chart.

We didn't call it the reverse Conway manoeuvre at the time. We just knew that if teams formed around the existing hierarchy, the architecture would inherit those same rigid boundaries. Org charts are designed for reporting lines and budgets, not for how software delivery flows. Let teams follow the hierarchy, and that's exactly what you get in the code.

I've also seen the opposite. On another project, what should have been a single coherent product experience was spread across four separate product teams, each with their own reporting line and priorities. Nobody owned the end-to-end user experience. The result was exactly what Conway's law predicts: the architecture mirrored the team splits, not the user's mental model. It's a common pattern in large organisations, not a failure of any individual team, but of a topology that doesn't match the product boundaries.

Cognitive load as a design constraint

Team Topologies puts a name on something that's easy to feel but hard to explain: teams have a finite cognitive capacity, and you should design around it.

On the collaboration product, we had a separate mobile squad rather than embedding a few mobile engineers in each stream-aligned team. If every squad had to hold mobile platform specifics in their heads on top of their domain, the cognitive load would be too high. Not every team member could keep everything in mind, and that's when things start falling through cracks.

I've found this to be a good litmus test. When scoping a team's mission, the question isn't just "what needs to be built?" but "can every member of this team reasonably understand the full scope of what we own?" If the answer is no, the boundaries are wrong.

The enabling team that was one person

The book describes enabling teams as groups that help stream-aligned teams acquire new capabilities. I've seen this work with a single senior person.

A security architect I worked with operated exactly this way. They didn't just produce guidelines. They worked directly with stream-aligned squads, embedding temporarily to help them implement specific security outcomes, whether that was JWT token handling, secret management, or threat modelling. They transferred knowledge, then moved on. That's the enabling model in its purest form: build capability in other teams, don't create a dependency.

From collaboration to service

Three interaction modes: collaboration, X-as-a-service, and facilitating. The thing that clicked for me is that you move through them. I've lived through that evolution in multiple organisations, and it's always the same pattern.

In one organisation, recurring incidents across many services followed common patterns. These weren't individual team failures. They were systemic gaps that no single team had the bandwidth or mandate to solve alone. I led a reliability-focused team to tackle this. Rather than building a centralised response function, I embedded my team with one service team at a time, worked closely alongside them on their biggest reliability gap, and built the fix as reusable tooling from the start. Automated secret rotation, safe infrastructure update workflows, continuous deployment with progressive rollouts, reusable infrastructure-as-code modules for common cloud patterns. Each built as a general solution, validated in one team's environment before others picked it up.

Once a solution was proven in production with a real team, the interaction mode shifted. What started as close collaboration graduated to X-as-a-service: other teams could consume the tooling independently, and get updates on it, with minimal coordination. Without embedding first, we wouldn't have understood the problem well enough to build something that actually worked. Without graduating to self-service, it wouldn't have scaled.

We were strict about quality. Every piece of reusable tooling had documentation, tests, and worked out of the box. If the consumer experience is poor, adoption doesn't happen. Once a few solutions were running in production and engineers across the organisation were joining regular community calls, things started moving on their own. Less personal push needed, more gentle steering.

Much of this work followed an inner source model. We didn't expect many pull requests from other teams, and we didn't get them. Stream-aligned teams have their own delivery to focus on. The real value of inner source was something else: working in the open built trust, attracted like-minded people across the organisation, and grew a community around the topic instead of a top-down mandate. Some of that work eventually became open source.

The collaboration trap

Team Topologies describes close collaboration as an interaction mode for early exploration. Two teams working tightly together to discover something new.

I've seen what happens when this mode is skipped. Sometimes teams skip early collaboration for understandable reasons: time pressure, uncertainty about direction, or wanting to move fast without too many voices in the room. But when architectural decisions get made without involving the teams who'll build on them, the downstream cost is real. People don't feel they "disagreed and committed." They feel they were never part of the conversation. The long-term impact on trust and buy-in is hard to recover from.

The glue between teams

Team Topologies would probably say that if you need someone working the seams between teams, your topology isn't right. Fix the boundaries, clarify the interaction modes, and the need for glue disappears. In theory, that's correct. In practice, even a well-designed topology assumes every team can fully deliver on their mission and will proactively coordinate when needed. Neither assumption always holds.

Some teams lack the skills to match their responsibility, whether through outsourcing, rapid growth, or being assigned work outside their expertise. Others have the capability but not the inclination to reach out. Autonomous teams can become insular, and collaboration doesn't happen just because the interaction mode says it should. Someone ends up bridging those gaps informally: orchestrating work across squads, testing a dependency that needs more attention, connecting things that would otherwise fall through the cracks.

But the glue role isn't only about compensating for gaps. Someone with visibility across multiple teams can spot patterns and risks that are invisible from inside any single boundary. Engineering maturity always varies across teams in a large organisation, and that cross-boundary perspective is how you keep the overall system healthy.

Tanya Reilly calls this being glue and frames it as legitimate technical leadership. Good organisations recognise this work and value the people doing it. Others don't, because it sits outside any team's formal scope, and that's how they lose the people who were holding things together.

Teams shape the people inside them

There's an aspect of team design that goes beyond delivery efficiency. Small, autonomous squads create space for engineers to grow. A squad lead with genuine autonomy and full visibility of their work to the broader organisation gets something that large hierarchical teams rarely offer: real ownership and room to develop. People I brought onto the team grew into leadership roles they wouldn't have got near in a traditional structure, because the squad structure gave them room for it. That was deliberate. How you draw team boundaries shapes careers, not just architectures.

What the book gave me

Team Topologies didn't change how I think about teams. It gave me a shared vocabulary for patterns I'd already seen work, and a clearer understanding of why some structures fail. Cognitive load, interaction modes, Conway's law as a design tool rather than an inevitability. These are the kind of things that turn gut feeling into something you can actually discuss with other people.

If you've spent years building teams, you'll recognise most of this book. It does for organisational design what Design Patterns did for object-oriented software: gives you shared names so you can stop talking past each other.

Skills look simple: markdown instructions, optional scripts, maybe some reference files. In practice that usually means front matter, a core SKILL.md, and supporting docs or code. The Agent Skills specification turned this into a shared format with progressive disclosure, so assistants can read metadata first and only load the full body when needed. Anthropic introduced it in December 2025, and major coding assistants adopted it quickly.

That speed makes one thing urgent: quality and governance. The first serious, customer-facing skills are only now starting to show up.

Creating a skill is easy. Creating a good skill is hard

A skill can be just markdown, and that is the appeal. A compact way to package procedural knowledge. The buzz around Anthropic's contract-review skill for Claude Cowork showed this well: it rattled legal tech stocks, and it is a couple hundred lines of markdown. Not a product. A SKILL.md file.

But low creation cost creates noise. Catalogs and registries have multiplied. skills.sh alone lists tens of thousands of skills. That proves demand, not quality. Maybe 90% of published skills are not really useful, not well designed, or just some guy building their own workflow opinions and packaging them as reusable assets. Discovery and filtering can end up costing more than just doing the task directly.

The hard part is not writing instructions. The hard part is designing a reliable flow with clear boundaries and good triggers, with gates that reduce failure rates. Good skills checkpoint risky branches, force validation steps, avoid ambiguous handoffs.

A slightly more technical aside, but worth mentioning: skills are not the only way to augment an assistant. Slash commands (user-triggered instruction sets) and MCP servers (external tools and data sources the assistant can call) are converging with skills into a similar pattern: reusable instruction bundles, often with optional scripts. Frameworks like spec-kit lean into that convergence. Skills also compose well with MCP servers, which can provide information in a more token-efficient format than raw API calls (compact representations like TOON instead of full JSON payloads). And MCP gateways like MCP Context Forge can add governance and security between the assistant and the data source, which is harder when a skill instructs the assistant to make direct calls.

Are skills documentation, or are they software?

I have started to see them as software. At least for skills we want to push to customers and be able to support. That is the main takeaway from these last couple of weeks: if it needs to be supportable, treat it like a software artifact.

Start with static analysis in CI. Tools like skills-ref validate check structure and naming against the spec, but that is just one check among many: markdown linting, context budget enforcement (startup metadata around the ~100-token footprint, recommended thresholds for SKILL.md size), and whatever project-specific rules make sense.

Then handle lifecycle. Versioning helps, but semver alone is not enough. Skills should include ownership and last-updated metadata. This gets harder in monorepos that hold unrelated skills, and many installers still do not provide a clean update path for already-installed skills.

Modularity matters just as much. Small, single-purpose skills are easier to compose and less likely to conflict. Large catch-all skills drift into ambiguity. If a skill ships Bash or Python, those scripts follow the normal lifecycle too: review, tests, security checks, clear ownership.

Testing skills needs a TDD-like loop

This is where I see the biggest gap. Most teams still test skills informally: try a couple of prompts, get one good answer, ship it. That is not enough for probabilistic systems.

There is also a real variance problem across assistants. Some trigger skills naturally from intent, others need explicit prompting. Codex often triggers on loosely related tasks. Claude Code and GitHub Copilot can need more prompt shaping depending on context. Once a skill is loaded, instruction-following quality still differs by assistant and model. Testing a skill on one assistant and calling it done is not enough.

I have been toying with a TDD-like approach to this, adapted for non-determinism.

1. Run a baseline without skill or MCP augmentation and capture failures (red).
2. Add the skill and MCP context until behavior is acceptable (green).
3. Refactor for stability and token efficiency.

Gates should be statistical, not binary. Run each scenario multiple times, track aggregate scores and standard deviation, inspect tail behavior. A good average can hide an ugly long tail. Ideally you run this across a matrix of assistants and models, so teams can publish minimum support expectations for each skill instead of claiming universal compatibility.

Scoring should mix deterministic and non-deterministic checks. Deterministic checks run assertions on outputs: files generated, content matching, expected tool calls, etc, and can also verify conversation structure. Non-deterministic checks can use semantic similarity score, or LLM-judge models, with targeted human review on high-risk workflows. Cost matters too: token usage, latency, retry count. If a skill improves quality but doubles cost and variance, that may be a bad trade.

And there is a more basic question that many teams skip: is the skill useful at all? In many cases, the base model already has the knowledge. If a skill does not measurably improve quality, consistency, safety, or cost, it should not exist. Offline evals help, but you still need a feedback loop from real users in live usage.

Security is still the wild west

Security is the least mature part of this space, and it shows.

The integration guidance says script execution is risky and should be sandboxed. That warning is justified. Skills can be pulled from many catalogs through different installers, with little shared trust model.

The most installed skill on skills.sh is one that automatically discovers and installs more skills from the internet, with a -y flag that skips user confirmation. Not an edge case. That is the default user pathway. No realistic central gate exists today. Many catalogs and installer implementations are out there, each with different review standards. Trust does not transfer across them.

Script execution is only one part of the risk though. Markdown instructions alone can encode harmful behavior: a skill could tell the assistant to ask users for sensitive information and route it to a third party. No scripts needed. Security review has to cover instruction content, not just executable assets.

I see two practical paths:

1. Curated, security-vetted catalogs or some kind of certification scheme.
2. Stronger assistant-side guardrails: sandboxing, tool allowlists, confirmation prompts for high-risk actions.

The second probably matters more in the short term because it protects users even when catalog governance is inconsistent. Many of these protections still sit outside the core skill format and depend on the assistant implementers.

Monetization comes after trust

I do think there is a monetization path for high-quality skills, especially in dense procedural domains: compliance, legal, medical, security, specialized infrastructure. Areas where there is a lot of procedural knowledge that people would pay for, if they trust the quality.

You are not selling markdown. You are selling well-maintained, tested knowledge. Closer to buying a technical playbook than a prompt file.

Monetization will probably look less like selling one static skill and more like subscriptions to curated pattern libraries, or MCP-backed knowledge systems where the skill is a thin layer over a gated database of patterns. Companies could also sell skill packs that integrate with their own products. Services like uupm.cc already point in that direction.

Where this leaves me

The format is good. Adoption is fast. Serious skills are just starting to emerge. What is missing is treating them like actual software: clear ownership, static checks, versioning, modular design, statistical evaluation, security controls, real user feedback loops. The basics we already know from software engineering, applied to a new kind of artifact.

I am still figuring out parts of this, especially around the eval tooling and how far cross-assistant testing is worth pushing for early-stage skills. But the direction feels clear. If we want skills to hold up in enterprise delivery, the bar has to go up. Otherwise they are just fancy prompts.

This year, more than most, made me think about team structure, and through that lens, about engineers and people. The patterns I've observed over the years keep sharpening as I see them repeat: anticipation and empathy change how engineers approach problems, team structures affect delivery speed and alignment with user needs. Culture shapes outcomes more than tooling or process.

The mindset difference

A pattern I've seen across engineering teams: you typically have one or two engineers who deliver multiples more value. The multiplier isn't in features they ship. It's in how their work compounds: making future development easier for other contributors, improving overall quality, preparing the codebase for future needs. I actually heard the term "10x engineer" only recently, but reflecting back across 20 years, it resonates, though not in the way the term is commonly discussed. The multiplier isn't about lines of code or features shipped. It's about fewer bugs, maintainable code, and solutions that serve the team long after the initial commit.

What this looks like in practice: an engineer implementing a capability as a reusable library rather than a one-off solution. Someone building a more generic implementation that others can extend later. The line between this and overengineering is thin. The difference is judgment: solving for the next likely step, not for every hypothetical future. These contributions have real business impact, but they're hard to see without looking at the technical details. Other engineers with the right mindset spot them immediately. What actually sets them apart is how they make their whole team more effective.

Anticipation as core skill

Anticipation is the biggest factor. Anticipating bugs, future needs, usage patterns, performance bottlenecks. Coding accordingly, not just for their own output but for other engineers working on the same codebase. For some, this becomes intuition rather than a checklist.

An engineer sees a configuration pattern that will likely need to support multiple environments. Instead of hardcoding values, they design the configuration structure to accommodate that from the start. Not because a requirement exists, but because experience suggests it will. Another engineer implements error handling that captures enough context to debug production issues, because they've been on the other end of vague error messages at 2am.

The same applies when writing documentation or tutorials: considering what readers already know and what they don't, adjusting the level of detail accordingly. Anticipating the questions someone will have before they ask them.

It also shapes how code communicates intent. Variable names that clarify purpose. Functions broken down in ways that make the next change obvious. Comments that explain why, not what, for decisions that might seem arbitrary six months later. These aren't cosmetic choices. They directly affect how quickly other engineers can understand, modify, and extend the code.

This isn't about building features you might need someday. It's about subtle choices that cost little extra: error handling that captures context, naming that communicates intent, structures flexible enough for likely next steps. The cost is minimal. The payoff compounds.

Empathy and user perspective

Seeing the product from the user's perspective comes naturally to some engineers. For many, it needs to be developed deliberately. This gap doesn't correlate with seniority. Experience in one domain doesn't automatically translate to understanding users in another. Direct interaction with users helps developers understand confusing features and behavior, making it easier to see confusion from the user's perspective.

This shows up in small decisions that shape user experience. An engineer who tests the error states, not just the happy path. Someone who questions whether a feature that makes technical sense actually solves the user's problem. A developer who considers what happens when the system is under load, when network is flaky, when inputs are unexpected. A UI developer who uses their interface from the user's perspective, testing usability rather than just building what was specified.

The absence is just as visible. Features that work perfectly in development but fail in production because real-world usage wasn't considered. Interfaces that make sense to the person who built them but confuse everyone else. Error messages that are technically accurate but give users no path forward.

Some engineers develop this naturally. Others need direct exposure to users and production systems. Some of this is innate, some learned. Training helps. For engineers where this doesn't come naturally, checklists and processes provide a pragmatic approach. I've introduced these in some teams I've worked with. Those checklists help, but they never cover everything. For some, user empathy remains a deliberate effort rather than intuition.

Pride and proactivity

Caring about your stuff. Having pride in what gets delivered. This is mindset rather than skills. Being proactive rather than reactive. Not just fixing issues when they happen, but building in ways that make future needs easier to address.

Pride in work shows up in details. Code that's clean not because someone will review it, but because it matters to the person writing it. Tests that are comprehensive because the engineer cares about correctness. Documentation that exists because the author wants others to succeed.

Engineers with this mindset don't wait for issues to be reported. They monitor production systems. They notice patterns in support tickets. They fix problems before they escalate. They refactor code that works but is fragile, because they know it will cause issues later.

There's also the opposite pattern. Engineers who do exactly what's asked, nothing more. Code that meets requirements but ignores obvious edge cases. Work that's technically complete but requires constant follow-up to actually function in production. It's a different approach to the work.

The other side of the spectrum

Some engineers have net negative contribution overall. This is uncomfortable territory, but real. I first noticed this in teams I was part of early in my career. Back then, it felt almost taboo to say it out loud. Over the years, as I saw the pattern repeat and found others discussing the same observation, it became clearer. Engineers who seem to deliver on the surface, but when you examine technical details and overall output, other engineers are fixing their issues in the background. The problems compound over time.

This isn't primarily about team friction, though I may have been lucky on that front. It's about bugs, subtle regressions, convoluted code that takes hours to understand. One developer writes unclear code in an afternoon, and several others spend far longer trying to figure out how it works.

The pattern is recognizable once you know to look for it. Code that works initially in production but starts breaking as usage grows or edge cases emerge. Code that passes review but becomes a maintenance burden weeks later. Changes that fix one issue but introduce two others. The engineer appears productive by conventional metrics. Tickets closed, code committed, features delivered. The cost shows up elsewhere.

Subtle regressions are the worst part. A change that works for the immediate use case but breaks edge cases that were previously handled. An optimization that improves one scenario but degrades others. A refactoring that simplifies the code the engineer understands but makes other parts more fragile. These issues often surface long after the original work, making the connection difficult to trace.

The DevOps model where developers write their own tests has a downside here. When engineers lack this anticipatory perspective, they tend to write happy-path tests that don't cover edge cases. A dedicated QA team with fresh eyes might catch what the original author missed. The efficiency gains from integrated testing can mask this gap.

The long-term effect compounds. Code review becomes more intensive, not because standards changed, but because trust eroded. What should be a straightforward feature takes longer because the foundation is unreliable.

AI as amplifier

AI-assisted development compounds these traits. Engineers with strong anticipation and user empathy know what to look for in generated code. They ask the right questions: does this handle the edge cases? Will this be maintainable? Does this actually solve the user's problem? They spot when something doesn't fit, when the generated solution misses context that wasn't in the prompt. They use AI to move faster while maintaining the same judgment that made them effective in the first place. Their impact multiplies.

Engineers lacking these traits just produce more. More code, faster, with the same blind spots. Code that doesn't align with real needs. Edge cases ignored. Subtle bugs introduced because generated code was accepted without critical review. The maintenance burden grows faster. More code to debug, more regressions to trace. The cleanup may never happen. Instead, the team slows down: new features take longer to build on a fragile foundation.

The variance between effective and ineffective engineers widens. What was a 10x difference becomes larger. Net negative contribution scales faster too.

Team organization matters

Individual mindset matters, but how teams are structured determines whether those individuals can be effective. I've seen projects struggle not because of technology, but because of team organization.

End-to-end ownership

What I've seen work: end-to-end squads responsible for delivering full capabilities or missions. A capability often spans multiple services, libraries, and products. The squad implements across all of them, rather than waiting for each component team to prioritize and deliver their piece.

This requires engineers willing to learn and adapt. They work across codebases they don't fully own. They understand enough of each component to make meaningful contributions, even if they're not the experts.

The ownership question still matters. Each component has owners: engineers who maintain long-term responsibility, review contributions, and ensure quality. Similar to open source, where maintainers accept pull requests from contributors. The end-to-end squad contributes, the component owners review and merge. Both roles are necessary.

This model creates velocity. The squad doesn't wait for five different teams to schedule their piece of the work. They implement, get reviews from component owners, and ship. Context stays intact because the same people carry the capability from start to finish.

When a customer complains about a feature, the squad that built it hears the feedback directly. They can adjust quickly because they understand the full picture, even across component boundaries.

The handoff problem

The alternative pattern: four or more development teams plus separate design teams. This leads to endless debates, handoff issues, lack of overall ownership. Each transition point becomes friction. Specifications get misinterpreted. Context gets lost.

The cost of handoffs is underestimated. When one development team builds a component, another team integrates it, and a third team extends it, each handoff loses context. The first team doesn't know how their code will be used. The second team doesn't understand the original design decisions. The third team inherits assumptions they can't see. Each handoff makes the codebase more fragile and harder to evolve.

Each handoff also diffuses responsibility. When something goes wrong, finger-pointing replaces problem-solving. No single person or team feels accountable for the end-to-end outcome. Handoff-heavy organizations develop defensive behaviors: extensive documentation to protect themselves, meetings to coordinate, rigid processes to prevent miscommunication. The bureaucracy is a rational response to dysfunctional structure, but it makes the dysfunction worse.

The debate trap

Too many teams also means endless debates. When four development teams need to align on an approach, each has different constraints, priorities, and contexts. The discussions become about finding consensus rather than finding the best solution.

Many architectural questions don't have clear answers in the abstract. The right choice depends on specific requirements, team skills, operational capabilities, and a dozen other factors that are hard to reason about theoretically. Building something surfaces these factors quickly.

This doesn't mean building without thinking. It means recognizing when discussion has diminishing returns. When the same points are being rehashed, when debates become circular, when decisions are blocked on hypothetical future requirements, it's time to build something and learn from reality. The teams that shipped features while others debated usually ended up with more refined solutions, improved through actual usage rather than speculation.

Different sides of culture

Mindset, team structure, and bias toward action are different aspects of software engineering culture. They don't neatly cause each other, but they're part of the same picture. AI makes the mindset gap more visible, widening the difference between engineers who anticipate and those who don't.

Some engineers bring anticipation and empathy regardless of how teams are organized. Some team structures work despite individual gaps in mindset. When teams struggle to deliver, it's usually one of these human factors: engineers who don't think beyond the immediate task, structures that diffuse responsibility, or processes where alignment takes longer than building.

As AI tools become more common, these fundamentals matter more, not less. Design, build, test, deploy. Or debate endlessly. Teams with strong foundations use AI to move faster without sacrificing quality. Teams without those foundations just accumulate technical debt faster.