Expert Generalists

Curiosity

Expert Generalists display a lot of curiosity. When confronted with a new technology or domain, their default reaction is to want to discover more about it, to see how it can be used effectively. They are quite happy to spend time just exploring the new topic area, building up some familiarity before using it in action. For most, learning new topics is a pleasure in itself, whether or not it's immediately applicable to their work.

This characteristic is noticeable when Expert Generalists get an answer to a question. Rather than just typing in some code from Stack Overflow, an Expert Generalist's curiosity usually motivates them to ensure they understand the answer, taking the opportunity to expand their knowledge, and check that the answer they got is appropriate. It's also present when asking a question. There is an art to asking questions that elicit deeper answers without leading the witness.

Collaborativeness

Learning about a new topic area may require reading, watching videos, and prototyping. But we see the greatest aid here is another vital characteristic: collaborativeness. A wise Expert Generalist knows that they can never really learn about most of the things they run into. Their T-shape will grow several legs, but never enough to span all the things they need to know, let alone want to know. Working with people who do have those deeper skills is essential to being effective in new domains.

Working with an otherly-skilled worker allows the generalist to contribute while the skilled collaborator spots more effective paths that only a specialist would know. The generalist appreciates these corrections, learning from them. Learning involves both knowing more about the new domain, but also learning to differentiate between areas where the generalist can do primary contributions and areas where the generalist needs help from the specialist. We notice Expert Generalists are never afraid to ask for help, they know there is much they are ignorant of, and are eager to involve those who can navigate through those areas.

An effective combination of collaborative curiosity requires humility. Often when encountering new domains we see things that don't seem to make sense. Effective generalists react to that by first understanding why this odd behavior is the way it is, because there's usually a reason, indeed a good reason considering its context. Sometimes, that reason is no longer valid, or was missing an important consideration in the first place. In that situation a newcomer can add considerable value by questioning the orthodoxy. But at other times the reason was, and is still valid - at least to some extent. Humility encourages the Expert Generalist to not leap into challenging things until they are sure they understand the full context.

This humility extends to recognizing the different trade-offs we see across architectures. An architecture designed to support large volumes of simple transactions will differ from one designed to handle a few complex interactions. Expert Generalists are comfortable in a world where different trade-offs make sense in different circumstances, usually because their travels have exposed them to these differences.

Customer Focus

This curiosity and eagerness to collaborate with people with different skills does raise a danger. Someone driven by curiosity can chase every shiny object. This is where the characteristic of customer-focus comes into play. We are often impressed with how an Expert Generalist takes each unfamiliar technology and questions how it helps the customer. We are fans of Kathy Sierra's notion that our purpose as software developers is to help our customers become “badass” at what they do.

Customer-focus is the necessary lens to focus curiosity. Expert generalists prioritize their attention on the things that will help them help their users to excel. This encourages learning about what their customers do, and how they can improve their work. It focuses attention on technologies that contribute to building those things. Customer-focus energizes collaboration, encouraging the exchange of information between customer and technologist, and allowing the Expert Generalist to coordinate other technologists towards enabling the customers' excellence.

Favor Fundamental Knowledge

Software development is a vast field, where nobody can know everything, or even a reasonable fraction of everything, so we all need to prioritize what topics we learn. Expert Generalists favor fundamental knowledge, that doesn't become outdated with changes when platforms update. These are often expressed as patterns or principles. Such knowledge tends to age slowly, and is applicable when folks move into new environments. For example the basic moves of refactoring are the same whatever language you are programming, the core patterns of distributed systems reappear regularly (and it's no coincidence that's why we wrote books on those topics - we like book sales that last for many years).

Blend of Generalist and Specialist Skills

Thus generalists often have deep knowledge of fundamentals, and we usually see them have deep knowledge of a few other topics too. They combine a broad general skill with several areas of deeper knowledge, usually acquired as it's necessary for products they've worked on, coupled with the curiosity to dig into things that puzzle most people. These deeper areas may not be relevant to every engagement they work on, but is a signal for their acumen and curiosity. We've learned to be suspicious of people who present as a generalist yet don't have a few deep specialties.

We mentioned before that a common name for this skills profile is that of the “T-shaped” person, implying a blend of specialist and generalist skills. While the T-shape moniker did catch on, it comes with a major problem in the metaphor, we don't find such folks have only a single deeper skill. They usually have a few, of varying depth. We're not the only people to identify this problem, and there have been several other names proposed to describe this skill-set, although the alternatives all have their own problems. 1

The vertical stroke of a skill set represents broader, long-lasting domains, not specific tools or frameworks. An expert generalist therefore pursues depth in distributed-data systems—partitioning and replication strategies, fault-tolerance mechanisms, consistency models, and consensus algorithms—instead of mastering only Databricks notebooks. In the cloud, they focus on cloud-native architecture: auto-scaling heuristics, multi-region fail-over etc rather than focusing on AWS-specific configuration syntax. On the front end, they study browser-based UI architecture—rendering pipelines, state-reconciliation patterns, and accessibility primitives—instead of the latest React APIs.

Sympathy for Related Domains

Expert generalists often find themselves in unfamiliar territory—be it a new software stack, a new domain, or a new role. Rather than chasing exhaustive detail from day one, they cultivate a rough, perceptive sense of what works in the new environment. That helps them make choices that go with the grain—even when it differs from their previous experience.

Jackie Stewart, a triple Formula 1 world champion (1969-93), described how, while he wasn't an engineer of the cars he drove, he still needed a sense of how they worked, how they responded to what the driver was trying to do, a sense he called mechanical sympathy. Martin Thompson brought this concept into software, by talking about how a similar knowledge of how computer hardware works is vital to writing high-performance software.

We think that the notion of mechanical sympathy has a broader sense in software, in that we do need to cultivate such a sympathy for any adjacent domain to the ones we are working on. When working on a database design, we need such a sympathy for the user-interface so we can construct a design that will work smoothly with the user-experience. A user-experience designer needs such a sympathy with software constraints so when choosing between similarly valuable user flows, they take into account how hard it is to build them.

This also shows itself with new teams. When joining a new team, expert generalists tend to listen to the established ways that a team works, introducing different approaches thoughtfully. Even when coming in as leaders, they don't default to tearing up existing workflows in favor of those more familiar to them. Their curiosity extends to understanding why different people work in different ways, trying out unfamiliar working styles, then incorporating their experience to develop practices to improve from the current state.

Hiring

Traditional interview loops still revolve around product trivia—“Explain Spark’s shuffle stages,” “How does Databricks Delta time-travel work?” A candidate who has never touched those tools can still be exactly the kind of person we need: someone who quickly grasps unfamiliar concepts, breaks complex systems into manageable parts, and collaborates across functions. Focusing on a single stack or cloud provider risks filtering out such talent.

To surface that potential, widen the conversation beyond tool recall. Ask candidates to talk through past experiences:

• How did they approach a particularly challenging situation?
• When have they ventured into an unfamiliar domain, and how did they get up to speed?
• How do they collaborate with people inside and outside their own organisation or discipline?

These stories reveal learning velocity, systems thinking, and people skills—the raw material of an expert generalist.

Example · Process-control engineer We once met an engineer whose entire résumé was industrial PLC work—no general-purpose language, no web, no cloud. Yet his record of diagnosing control-system failures and the questions he asked during the interview showed exceptional learning agility. Hired for those qualities, he grew into a respected technical leader and later a product owner. Rejecting him for not knowing “our” tools would have been a costly miss.

Career progression

Inside the organisation, narrow verticals can freeze growth: UI developers, QAs, data engineers, or cloud experts seldom step outside their lanes. The growth paths map one-to-one with vertical silos: UI Engineer → Senior UI Engineer → UI Architect, or Data Engineer → Senior Data Engineer → Principal Databricks Guru. The unintended message is, “wander outside your lane and your progress stalls.

We have found that encouraging people to experiment—letting them make mistakes and learn in adjacent disciplines—yields remarkable benefits. A business analyst writing code out of curiosity, a front-end engineer dabbling in DevOps, a data engineer trying product analysis: each cross-pollination broadens both the individual and the team.

Example · Medical-domain analyst A non-technical professional from healthcare joined us as a business analyst. His passion for tech pulled him into code reviews and pairing sessions. Over time he became an outstanding tech lead and a broader strategic thinker than many traditional “pure” engineers.

From Tools to Fundamentals

IT trends get triggered by pivotal inventions that enable new business opportunities. Product providers and tool vendors quickly build products, and the industry focus often shifts to expertise in tools and frameworks rather than the underlying technical trends. For example, in the 1990s, when graphical-user-interface two-tier architectures were popular, the essential skill was mastering Object-Oriented Programming — its iterative, collaborative design — yet most attention centred on tools like Rational Rose, the C++ programming language, and frameworks such as Microsoft Foundation Classes. When the Web arrived, understanding Web architecture and global-scale caching was crucial, but early hype gravitated toward technologies like J2EE. In today's cloud era, with complex microservice based architectures, big-data technologies, and expansive DevOps toolchains, the foundational discipline of distributed systems is often overlooked while certifications in specific tools dominate.

One of the biggest problems with excessive focus on tools and framework expertise is when it is cemented into organizational structures. Teams and organisations get structured around tool expertise, with hardened boundaries making it difficult for people from one team to acquire skills from others. Beyond language preferences like Python or Java, you can see this crystallise in the three most common software verticals—Application Development, Data Engineering, and DevOps. Are labels like “Application Development,” “DevOps,” and “Data Engineer” just harmless shorthand for the work we do? Not really. Once these words harden into career lanes, they solidify the very silos that the Agile and DevOps culture was meant to dismantle. The labels become an organisational anti-pattern—turning flow into a series of hand-offs when it should be a cross-functional sprint. All three share the same distributed-systems foundations, and anyone who masters those fundamentals can navigate all three without getting lost in each vertical's ever-growing toolset. An expert generalist recognizes this and makes the deliberate effort to master those fundamentals.

Why does our attention keep drifting toward tool expertise? It isn't because people are shortsighted or lazy; it's because the fundamentals are hard to see amid the noise. Key ideas hide under stacks of product docs, YouTube tutorials, vendor blogs, and conference talks. At one end of the spectrum lie dense academic papers and university courses; at the other, vendor certifications tied to a single product. Connecting these dots — cutting through the surface to reach the essentials — takes deliberate effort. One proven aid is the language of patterns: reusable problem-solution pairs that capture the core principle without the brand labels. That's why we belive in investing in exploring, distilling, and sharing such patterns — so the industry conversation can shift from “Which tool should I learn next?” to “Which underlying principles and patterns must I master?”

In our experience, the good grasp of this common language of patterns and principles also strengthens the product-service partnership. Today the relationship is often one-way: product teams ship features, service teams consume APIs. Product teams decide how to certify an engineer as an expert in a product and service teams aim to do those certifications. Cloud providers and tool vendors often demand a certain number of “certified professionals” before they will recognise a service provider as a competent partner. Yet our experience shows little correlation between certifications and competence. The focus on fundamentals pays off when competence is most needed: an engineer versed in Raft can untangle a Kubernetes control-plane stall that might puzzle several certified admins, and a Delta Lake write anomaly can be resolved from first-principles reasoning about optimistic-concurrency control instead of searching vendor docs. Once developers across roles share the lingua franca of a system's internals, the partnership becomes bidirectional — both sides can diagnose, propose, and refine solutions together. Better yet, the engineers who have a good grasp of the fundamentals are able to partner well with multiple product and platform teams, without needing to have product specific training for each product

An Example Workshop: Breaking silos and building partnerships

We've seen that we can grow the Expert Generalist skill through mentoring and exposure to varied ecosystems, but one of the consequences of recognizing Expert Generalist as a first-class skill is that we should provide training in a similar way that we do with specialist skills. Such training currently barely exists in our profession. We've begun to fill that gap with workshops that are deliberately focused on developing the Expert Generalist competence, and we think there should be more training along these lines.

To help stimulate thinking about this, here's the details of such a workshop, aimed at developers to connect Application Development, Data Engineering, and DevOps. The workshop views this work through a distributed systems lens, shifting attention to shared building blocks and establishing a common language across teams. Although this example is developer-centric, we think the same principle can be adapted just as effectively to any role that benefits from cross-disciplinary insight.

As we saw earlier, each discipline—Application Development, Data Engineering, and DevOps—faces the same distributed-systems realities, yet we still lack a shared language. The key challenges of these systems are the same. They must replicate state, tolerate partial failures, and still offer consistency guarantees to end users. A catalogue of patterns around the implementation of partitioning, replication, consistency, and consensus—that lets every team talk about the fundamentals without tool-specific jargon is a good start. One workshop will not turn people into expert generalists, but it does give them a head-start and a clear window into the challenges their peers tackle every day. That visibility lowers the barrier to cross-discipline tasks and deepens everyone's understanding of the products and platforms they use.

The workshop structure - Building the miniature

One of the challenges in teaching the abstract patterns is that the developers need to do some mental mapping to connect the pattern to the product in use. This is why we chose an approach to structure the workshops around specific products, but then focus on the patterns that are most relevant and using the product as a window into the broader concepts.

The way we structured the workshops to teach distributed-system patterns, is by coding pocket versions of Kafka, Kubernetes, and Delta Lake. The idea is to pick a flagship product from each broad area of specialty, and build it step by step. Implementing a flagship system in just a few hundred lines flips your perspective from 'a user' of a product to 'a builder'. An important mindset shift. To keep the exercise grounded in reality, write it in the product's own language, mirror its file and method names, and rely on real infrastructure — ZooKeeper or etcd, an on-disk log, live sockets. The result stays close enough to the original to highlight the pivotal design choices while still giving you a safe canvas for experimentation. This approach is powerful, because each target is often open source, the moment the miniature works, you can open the full codebase on GitHub, recognise the directory structure, and feel confident submitting a patch. The miniature is not a toy; it is a gateway.

We have three workshops, one for each of the three systems.

Each miniature leaves you with a concrete pattern — append-only log, reconcile loop, optimistic commit—that travels well beyond the original context. When the next new tool arrives, you'll recognise the pattern first and the product name second, which is precisely the habit that turns professionals into Expert Generalists.