Expert Generalists

Why Generalism Is Becoming a Core Engineering Skill

Writing sophisticated software requires a lot of detailed knowledge. Build in Java and you need the syntax, the library ecosystem, and the toolchain for verification and packaging. Switch to Python and you face a different syntax, differently named libraries, and a separate build-and-run ecosystem. Faced with this depth, many organizations respond by hiring narrowly: job postings demand “at least three years of Java” or specific experience with particular frameworks. But what use is a skilled Python programmer to such a team?

In our experience, the traits that separate effective software developers from the rest are not tied to specific tooling. What matters is knowledge of core programming concepts and patterns, a knack for decomposing complex work into small testable pieces, and the ability to collaborate with both programmers and the people who will benefit from the software. Throw a strong Python developer into a Java team and expect them to prosper. They will ask plenty of questions — “how do you do this here?” — but those questions get answered quickly, and the Java-ignorance soon ceases to be an impediment.

This is part of a long debate about specialists versus generalists. Specialists have deep skill in one subject; generalists have broad but shallow skills. The idea of the “T-shaped person” tried to bridge the gap: deep in one topic, broad but shallow in many others. In practice we've seen many such people quickly grow additional deep legs — which makes the “T” name less apt but the outcome highly successful. Exposure to different environments often produces what looks like innovation at home: people who have worked in multiple technological neighborhoods are less likely to lock themselves into a single knowledge silo. The best business analysts, developers and user experience folks we have worked with routinely step outside their “lanes” to contribute broadly. This ability has long been an essential, if unacknowledged, quality of our best colleagues.

Yet the industry increasingly pushes for narrower specialization. Over the past year or so we have started to resist that push by naming and calling out this quality: the Expert Generalist.

What Defines an Expert Generalist

Real expertise has two sides. The familiar one is depth: detailed command of one domain's inner workings. The second, crucial in a fast-moving field, is the ability to learn quickly, spot the fundamentals beneath shifting tools and trends, and apply them wherever you land. Developers who roam across languages, architectures and problem spaces may look like “jack-of-all-trades, master-of-none,” but repeated dives below surface differences build durable, principle-level mastery. Over time, such generalists dissect unfamiliar challenges, recognize first-principles patterns, and make confident design decisions with the assurance of a specialist — and often faster. Being an Expert Generalist is itself a sophisticated expertise.

Several traits separate those who succeed as Expert Generalists from those who do not.

Curiosity

A persistent desire to understand systems deeply and to look across boundaries. Expert Generalists explore topics that are not directly required by their day job, and they connect their findings back to their work. They ask questions about other teams' domains and seek to understand the “why” behind a technology or design, not just its mechanics.

Collaborativeness

They work well with specialists in other areas. Crucially, they listen more than they assert. When moving into a new domain, the fast route to credibility is respectful inquiry, not assuming that a generalist view maps directly onto the specialist's context.

Customer Focus

Software exists to solve organizational problems. Effective Expert Generalists keep the goal front and center and understand how the pieces — people, process and technology — fit together toward it. In a software context this is everything from testing and deployment to interacting with non-technical stake-holders.

Favor Fundamental Knowledge

Expert Generalists orient toward the underlying principles of a discipline rather than its transient forms. For a software developer, this looks like knowing the fundamentals of networking, operating systems and database design, so that when a new tool emerges it is quickly classified against known fundamentals. This ease gives them confidence in front of novel technology and a willingness to probe for deeper structure.

Blend of Generalist and Specialist Skills

While breadth and fast learning are hallmarks, genuine Expert Generalists tend also to have built deep expertise in one or more areas. Their specialty is frequently their home base — the workplace where they have their deepest history and where their knowledge supports their confidence when moving elsewhere.

Sympathy for Related Domains

Expert Generalists often develop an affectionate working familiarity with a neighboring specialties, such as data engineering, user experience or product management. The sympathy is not an encyclopedic vocabulary for those fields but rather a “knowledge of and enormous respect for” them, and a feel for how to negotiate and collaborate with those practitioners.

Assessing and Hiring for Expert Generalists

Traditional hiring practices often screen for narrow expertise first. To assess for the broader quality, organizations should look for evidence of the traits above. Interview questions should probe curiosity, attitudes toward learning, collaboration and ability to grasp fundamentals.

A useful way to interview for an Expert Generalist is to avoid a single predictable question such as “what is your favorite language?” and instead probe less straightforward material. Candidates might be asked to teach us a subject — narratively, covering context all the way down to implementation — or to trace a design decision from a project ledger. What matters is not the specific technology but the shape of their explanation: the mix of practical knowledge and first principles, and whether they can locate themselves in the landscape of trade-offs and unresolved questions. We also look for signs of intellectual humility, comfort saying “I don't know” while immediately offering a way to find out, and evidence of commitment by collaboration rather than by dominating a room.

Growing Expert Generalists

Expert Generalists can be deliberately developed. Once organizations name the skill and the traits beneath it, they can shape learning programs, hiring filters and career paths around it. Thoughtworks has been informally cultivating this skill for over two decades.

From Tools to Fundamentals

Training should aim at foundational and transferable know-how rather than today's specific tools. A course on data-intensive systems, for instance, teaches replication, partitioning and transactions — ideas whose shelf life is far longer than a given framework. The aim is not the absence of tools but the heavy orientation of the curriculum toward the durable fundamentals and the encouragement of hands-on exploration of richer tool sets.

A sensible sequence for a generalist training path might begin with the durable core: algorithms, data structures, architecture and design principles. Then move on to domain-model patterns across genres such as event sourcing and transactional integrity, and only then examine specialized but portable tooling such as Kafka, Kubernetes or Spark. The final stage can introduce tool-adjacent proprietary systems, positioning them clearly so the learners know where near-term work actually happens.

Broader context is also important, and this is where parts of the workshop venture beyond software: how software interacts with human psychology, how to speak the discipline of any sector's core concerns, and how engineers can think about economic and political forces that shape the environments they build for.

Structure for a Generalist-Raising Workshop

Workshops that seek to build generalist competence tend to succeed when they are built around an engaging miniature of a real sociotechnical problem, one with no clean boundaries and no single correct answer. The exercise pushes participants to face demands across a wide technical and domain waterfront — building a miniature called, for example, “the fulfillment system” — where participants feel the presence of the many slices these disciplines separately own: UX journey maps, sequence diagrams for systems thinking, customer-service call note analysis sparking ethnographic sensitivity.

The heart of the exercise is an organization simulation where cross-functional teams negotiate priorities and architecture, then disintegrate into code sprints; desks reorganize, product managers, UX analysts and engineers pair up. The exercise derives vitality by having teams actually feel the full organizational surface across more traditional boundaries: fast-flow event logs to DB constraints; design docs to code — often rapidly, under sixty minutes.

A miniature is a great teaching vehicle because, for the scale of the problem chosen, details stay visible and multi-layered. The simulated business context provides enough complexity — a rewarding simulation of every region's impossible-to-avoid trade-offs and overlaps. The facilitation rhythm is important: sessions that begin with navigation by questions and a first-person narration of the context beats lectures. After one round of structured exploration, groups loop through reflective pauses: silent individual sketching, pauses for in-group comparison, then whole-room replaying of decisions as the miniature becomes enriched.

Specialists Remain Essential

Naming and growing Expert Generalists does not diminish the need for deep specialists. Our aim is not a company of generalists but a better tension between breadth and depth. Many products and ideas are born in, and survive because of, the deeper penetration of specialists, and any smooth-working organization will contain both groupings. A sure way to kill that balance is employment policy that pushes individuals into only one groove. Specialists who feel forced to overvalue breadth lose some of the passion of their groove, and generalists who cannot find their groove never glow. Managers can help us move across groupings, protecting that professional commitment.

Expert Generalists in the Age of LLMs

This is a good moment for an Expert Generalist's adaptability to shine. The arrival of large language models affects our profession's day-to-day but has arguably sharpened the value of this ability. AI tooling shifts the kinds of things software engineers can ignore and raises the value of competence across many specialties to keep a demanding system healthy. With coding ever cheaper, the core engineering act shifts even further toward problem shaping and broad responsibility: decomposing tasks into small testable pieces that can be safely delegated to an individual's own judgment and review. Crucially, LLMs themselves behave as Generalists and are frequently unevenly reliable across technical and domain fronts; thoroughly engaging such tools requires the breadth of an Expert Generalist to quickly triage fact patterns at every turn. An engineer narrowly attuned to a single narrow platform is at a handicap compared with one able to spot, earlier across a fast-moving a landscape, which alternative solves their actual problem. The gaps in an LLM are best tuned by people who can hold a system's entire surface together and spot where coherence is missing across that entire surface.

Why Organizations Need Expert Generalists

Generalists in an organization provide the connective tissue across domains that allows specialists to knit their contributions together. Their role includes maintaining the map of the landscape and integrating disparate disciplines and vocabularies while honoring each community, interlocking pieces that specialists could not fit into comprehensible form. Specialists deliver individual frames; generalists deliver belonging and coherence. Where complex software must support our human worlds, thoughtful synthesis is already inseparable from careful, satisfying specialization.

Takeaways

• Expert Generalists are valuable, identifiable and developable: an important software skill, distinct from being merely a specialist or a generalist. We should recognize, name and cultivate it explicitly in hiring, careers and training.
• Core Expert Generalist traits include curiosity, a collaborative orientation, customer focus, and durable knowledge of fundamental principles.
• Nurturing this skill means pointing training at the fundamentals and teaching with cross-domain miniature reproductions of real contexts rather than command-line trivia.
• An Expert Generalist is not a generalist-in-training but itself a sophisticated expertise.
• Full organizations still need narrow domain experts.
• The human versatility of Expert Generalists grows more valuable as expertise is democratized and automated — humans should keep their own specialist flame where ethics and taste intersect.

What Sets Expert Generalists Apart

Observing Expert Generalists in action reveals a set of recurring characteristics that define how they approach their work.

A Driving Curiosity

A defining trait of the Expert Generalist is an insatiable curiosity. Confronted with a new technology or domain, their instinct is to explore it, eager to understand how it might be used effectively. They find genuine pleasure in learning new topics, regardless of whether the knowledge has immediate application to their current tasks. This curiosity extends to the answers they seek. Rather than mechanically copying code from a forum, they are motivated to understand why the solution works, verifying its appropriateness while expanding their own knowledge. The same mindset shapes how they pose questions, striving to elicit deeper understanding without steering the conversation.

Collaboration as a Learning Tool

Curiosity alone is not enough to master a new field, which is where another vital trait emerges: collaborativeness. Expert Generalists are wise enough to know they can never learn everything they encounter. Their skillset, while broad, will never span the entire landscape of what they need to know, let alone what they want to know. Teaming up with people who possess those deeper skills is therefore essential. In a partnership, the generalist contributes while the specialist spots more effective paths only they would know. This dynamic allows the generalist to learn both about the domain and about where their own primary contributions are useful versus where they need to defer to the specialist. A key part of this is their willingness to ask for help, acknowledging that their ignorance is vast and that involving experts is the most effective way to navigate it.

Effective collaboration of this kind requires humility. When an Expert Generalist encounters behavior that seems odd, their first reaction is to understand the context, recognizing there is usually a good reason behind it. Sometimes that reason is outdated or was flawed from the start, and a fresh perspective can add significant value by challenging it. More often, however, the reasoning remains valid, and humility prevents the generalist from challenging things before they grasp the full picture. This humility also extends to architectural design, where they are comfortable with the reality that different trade-offs are appropriate in different circumstances, a comfort gained through exposure to a wide variety of systems.

Keeping the Customer in Focus

An unchecked curiosity carries a risk: chasing every new and shiny technology. This is where customer-focus serves as the essential lens. Expert Generalists consistently evaluate unfamiliar technology by asking how it helps the customer become better at what they do. This perspective focuses their attention on learning about their users' needs and how to improve their work, which in turn prioritizes only those technologies that contribute to those goals. Customer-focus also energizes collaboration, driving a productive exchange of information between customer and technologist.

Prioritizing Long-Lasting Knowledge

In a field as vast as software development, no one can know everything, so priorities must be set. Expert Generalists favor fundamental knowledge that remains relevant long after specific platforms and tools have changed. This knowledge is often expressed through patterns and principles and tends to age slowly, making it highly portable when they move into new environments. The basic moves of refactoring, for instance, are the same regardless of the language being used, and the core patterns of distributed systems reappear with regularity.

More Than a Single Deep Skill

This preference for fundamentals often means Expert Generalists hold deep knowledge in a few distinct topics. They combine a broad skillset with areas of expertise usually acquired while working on products, propelled by a curiosity to understand things that puzzle most people. A person who claims to be a generalist without possessing several areas of deep understanding should be viewed with suspicion. The "T-shaped" metaphor, with its single deep vertical stroke, is misleading. In practice, these individuals have a few specialties of varying depth. The vertical strokes of their skill set represent broader, long-lasting domains rather than specific frameworks or tools. For example, they might develop depth in distributed-data systems, exploring partitioning, replication, fault-tolerance and consensus algorithms, rather than solely mastering one vendor's notebook software.

Developing Mechanical Sympathy

Expert Generalists frequently find themselves in new territory, and they succeed by developing a perceptive sense of how a new environment works rather than seeking exhaustive detail at the start. This allows them to make choices that align with the grain of the new context, even when that differs from their past experience. This idea, championed in software by Martin Thompson, borrows from the concept of "mechanical sympathy"—how a driver or engineer needs an intuitive sense of how a car will respond. In software, it means cultivating a sympathy for all adjacent domains. For example, a database designer needs a sense of the user interface to create a design that integrates smoothly, while a user-experience designer must consider engineering constraints when choosing between otherwise equivalent workflows.

This sympathy is evident when Expert Generalists join new teams. Rather than imposing familiar workflows, they listen to established ways of working and introduce changes thoughtfully. Even in a leadership role, they avoid tearing things up by default. Their curiosity extends to understanding why other people work differently, leading them to try unfamiliar styles and develop practices that improve upon the existing state.

Spotting and Growing Cross-Disciplinary Talent

Expert generalists rarely announce themselves through a familiar tool list. That makes two moments especially important for finding and developing them: the hiring process and the path to promotion once they’re on board.

Hiring beyond the product quiz

Many interview loops still lean on stack-specific questions, such as “Explain Spark’s shuffle stages” or “How does Databricks Delta time-travel work?” A candidate who hasn’t worked with those exact products may still fit perfectly—if they can pick up unfamiliar concepts quickly, break down complex systems, and cooperate across teams. Anchoring the interview to one framework or cloud provider risks filtering out exactly those people.

To uncover that potential, steer the conversation away from recall and toward real experience. Useful prompts include:

• How did they handle a particularly hard problem?
• When did they step into a domain they didn’t know, and how did they get up to speed?
• How do they work with people in other disciplines or organisations?

Their answers expose learning velocity, systems thinking, and collaboration—the core traits of an expert generalist.

Example · Process-control engineer. One engineer’s entire résumé was industrial PLC work: no general-purpose language, no web, no cloud. But a history of diagnosing control-system failures, combined with sharp questions in the interview, made for remarkable learning agility. Hired for those qualities, the person became a respected technical leader and later a product owner. Passing on them for not knowing “our” tools would have been an expensive error.

Progress that rewards range

Inside a company, narrow career tracks can halt growth. When UI, QA, data, and cloud roles each follow their own vertical ladder—UI Engineer to UI Architect, or Data Engineer to Principal Databricks Guru—the implicit message is that straying outside your lane stalls your career.

The alternative is encouraging experimentation, letting people make mistakes while learning adjacent disciplines. A business analyst coding for curiosity, a front-end engineer taking on DevOps, a data engineer dabbling in product analysis: each crossover strengthens both the person and the team.

Example · Medical-domain analyst. A hired business analyst with a healthcare background, but no formal technical role, was drawn into code reviews and pairing sessions out of curiosity. Over time they became a strong tech lead, and a broader strategic thinker than many engineers who had stayed in a single “pure” path.

Both cases come down to the same point: evaluating people strictly on a tool checklist means missing brilliant, adaptable colleagues—and limits the organisation’s capacity to innovate.

Why Tool Expertise Keeps Winning

Every major technology wave follows a similar arc: a foundational invention creates new business possibilities, vendors rush in with products, and the industry’s attention settles on mastering those tools and frameworks rather than the underlying principles. In the 1990s, two-tier GUI architectures put Object-Oriented Programming at the center of software design, but the conversation revolved around Rational Rose, C++, and Microsoft Foundation Classes. When the Web arrived, the real challenges were in Web architecture and global-scale caching, yet the hype attached to J2EE. Today’s cloud-native world runs on microservices, big-data pipelines, and elaborate DevOps toolchains—but the foundational discipline of distributed systems is routinely overshadowed by certification tracks for specific products.

This fixation becomes especially damaging when it hardens into organizational structures. Teams get formed around tool expertise, and boundaries stiffen until people in one group can’t easily pick up skills from another. The silo effect is visible in the three dominant software verticals—Application Development, Data Engineering, and DevOps. Labels like these seem like harmless shorthand, but once they become career lanes they cement the very hand-offs that Agile and DevOps culture was meant to dissolve. All three verticals share the same distributed-systems foundations; someone who masters those fundamentals can move across all three without drowning in each vertical’s growing toolset. That is precisely what an expert generalist does—makes a deliberate choice to invest in the fundamentals rather than the latest product.

The drift toward tool expertise isn’t a character flaw. The fundamentals are genuinely hard to see beneath piles of product documentation, vendor blogs, and conference talks. At one extreme sit dense academic papers; at the other, single-product certifications. Bridging that gap takes deliberate effort. The language of patterns—reusable problem-solution pairs stripped of brand names—is one proven aid. When we invest in exploring, distilling, and sharing those patterns, the industry question can shift from “which tool should I learn next?” to “which underlying principles must I master?”

A shared vocabulary of patterns also changes the nature of product-service partnerships. Today the relationship is often one-way: product teams ship features, service teams consume APIs. Vendors frequently require a certain count of “certified professionals” before recognizing a service provider as competent, yet our experience shows little correlation between certification and actual performance. An engineer who understands the Raft consensus algorithm can unravel a Kubernetes control-plane stall that might stump several certified administrators. A Delta Lake write anomaly becomes tractable through first-principles reasoning about optimistic-concurrency control rather than searching vendor docs. When developers across roles speak the same language of system internals, the partnership becomes bidirectional—both sides can diagnose, propose, and refine solutions together. Engineers grounded in fundamentals can partner across multiple product teams without needing product-specific training for each one.

Teaching the Generalist Skill

If Expert Generalist is a first-class skill, it deserves first-class training—but that kind of training barely exists in our profession. Mentoring and exposure to varied ecosystems help, but they’re not a substitute for structured development. We’ve started filling the gap with workshops deliberately designed to build the Expert Generalist competence, and we think more such training is overdue.

The workshop format we use aims at developers who want to connect Application Development, Data Engineering, and DevOps. It views all three through a distributed-systems lens, shifting attention to shared building blocks and establishing a common language across teams. The specific example is developer-centric, but the same principle adapts to any role that benefits from cross-disciplinary insight.

Each discipline faces the same distributed-systems realities: they must replicate state, tolerate partial failures, and still guarantee consistency to end users. Yet they lack a shared way to talk about these problems. A catalogue of patterns covering partitioning, replication, consistency, and consensus gives every team a way to discuss fundamentals without tool-specific jargon. A single workshop won’t turn anyone into an expert generalist, but it provides a head start and a window into the challenges peers face daily—lowering the barrier to cross-discipline work and deepening everyone’s understanding of the products they use.

The Workshop Structure: Building a Miniature

Teaching abstract patterns is hard because developers must mentally map each pattern to the product in front of them. We chose to ground the workshops in specific products while keeping the focus on the patterns those products exemplify—using the product as a window into broader concepts.

Our approach is to code pocket versions of Kafka, Kubernetes, and Delta Lake from scratch. The idea is to pick a flagship product from each specialty, then build it step by step. Implementing a flagship system in only a few hundred lines flips the perspective from user to builder—an essential mindset shift. To keep the exercise realistic, we write the miniature in the product’s own language, mirror its file and method names, and rely on real infrastructure like ZooKeeper, etcd, an on-disk log, or live sockets. The result stays close enough to the original to reveal pivotal design choices while still offering a safe canvas for experimentation. Because every target is open source, once the miniature works a developer can open the full codebase on GitHub, recognize the directory structure, and feel confident submitting a patch. The miniature is not a toy; it is a gateway.

Build Your Own Kafka

Written in Java, this miniature uses ZooKeeper for membership and stores every message in a single append-only log. Even on one node you encounter the classic fsync dilemma—flush every write for durability or batch for speed. Add a second process and the decisions multiply: partition leader election, quorum acknowledgements, an in-sync replica list, and a high-water-mark so consumers never read uncommitted data. A cluster-wide controller comes later once multiple partitions appear. Each mechanism maps directly to a production feature in Kafka, and after walking through the code you understand why a broker stalls when a replica slows—and which metric to graph next time it happens. The takeaway: an append-only log guarded by quorum replication, a design you will find throughout modern distributed systems.

Kubernetes from the Inside Out

The second miniature starts with a controller that watches a JSON document in etcd, then calls reconcile() until the local Docker daemon reaches the desired state. You quickly face choices about how to list running containers, queue events, and keep spec and status distinct—exactly the concerns that dominate the Kubernetes codebase. Add real failure scenarios and it gets harder. What should the controller do when a container exits? How does a Postgres container retain its data? Each decision forces you to reason about restart policies and persistent-volume claims. After that exercise, the dense Go structs in kube-controller-manager feel like a natural continuation of a model you already understand. The core learning: the power of reconciling a declarative desired state—the common pattern of orchestration in modern systems.

ACID on Object Storage

The third miniature builds a Delta Lake clone step by step. Start with a directory of Parquet files paired with a text log—each data change appends a JSON file naming the new data file. Move the setup into a miniature object store and every append becomes its own key-value write, with the Parquet file as the value. To handle concurrent writers, wrap the append in an optimistic lock that retries if the log tail changes. After a dozen commits, start-up time drags, so you add a checkpoint file and learn first-hand why Delta Lake emits one every N transactions. Time-travel queries then fall out naturally from the log-plus-checkpoint design. The key takeaway: achieving ACID guarantees on eventually consistent storage through an immutable transaction log, optimistic concurrency, and periodic checkpointing—a pattern vital for modern data lakehouses.

Each miniature leaves you with a concrete pattern—append-only log, reconcile loop, optimistic commit—that carries far beyond its original context. When the next new tool arrives, you will recognize the pattern first and the product name second. That habit is what turns professionals into expert generalists.

When Generalist Breadth Needs Specialist Depth

Praise for Expert Generalists should not be mistaken for an argument against specialization. Teams still need deep expertise in the core technologies they work with daily. A generalist facing an unfamiliar platform can lean on pattern knowledge and solid research skills, but they will still take longer than someone who already knows the terrain. Worse, they may not realize what they don’t know—a blind spot that a specialist is far less likely to have. A team made up entirely of Expert Generalists will usually finish the job, but it will do so noticeably slower than a team with targeted specialist strength.

The practical answer is balance: for every core technology a team works with, at least one deep specialist should be present. Often a single specialist, or maybe two, is sufficient—provided the team collaborates well. That specialist fields questions as generalists hit depth-requiring tasks, and reviews the work of less experienced colleagues to catch wrong turns early. This person should be a full-time member of the team, not someone pulled in occasionally. Much of their value is responsiveness: questions must be answered as they arise. The metric that matters here is the Cost of Delay, not the specialist's utilization. If you are unsure whether you have enough specialists, measure how long questions go unanswered—a direct application of Reinertsen's advice on monitoring queue sizes.

Collaboration requires a particular temperament on both sides. Specialists need to enjoy teaching and be approachable, while Expert Generalists must be willing to show their ignorance and accept feedback about mistakes in unfamiliar environments. Psychological safety is a prerequisite. Many specialists are themselves Expert Generalists, with their depth forming one leg of the "T." Conversely, an all-specialist team is risky in its own way: a data engineering group staffed purely by data engineers can easily overlook non-data concerns such as release management, quality strategy, or value articulation.

Large Language Models Favor the Broad

The emergence of LLM-based tools has shifted the value equation in favor of Expert Generalists. In some ways an LLM functions like a specialist on demand—ready to answer questions about a new domain, lowering the barrier to exploring unfamiliar tools. But the generalist’s edge comes from how they use the tool. They can ask sharper questions, evaluate generated code against architectural principles, and test answers against their broader mental model because they are not merely seeking a snippet. Their curiosity pushes them to understand why a proposed solution works, which is precisely the skepticism required to counter the unreliability inherent in LLM output.

Expert Generalists also prompt differently: rather than hunting for a single correct answer, they ask for questions, mechanisms, examples, and exploratory tools. Given the young state of this technology, it appears that LLMs will increase—not decrease—the importance of people with this skill set. Organizations that identify and train Expert Generalists will be better positioned to take advantage of what the tools make possible.

Why the Organization Needs Crossing Skills

Restricting hiring or staffing to a narrowly defined specialist profile shrinks the candidate pool. Usually an Expert Generalist with access to specialist guidance performs as well as—and often better than—an additional specialist. That flexibility matters beyond recruitment. Modern software delivery cuts across many competency boundaries and waits on other teams slow feature flow. Expert Generalists unblock these pipes either by smoothing hand-offs with overlapping knowledge or by doing dependent tasks themselves. Driven by customer focus, they will cross boundaries and acquire depth as needed. There is a risk of overreach, but that capacity to bring features to completion is often decisive.

Breadth is also crucial for diagnosis. Failures frequently surface not within a single technology but in the interactions between systems. A specialist who cannot see the wider picture will miss failures that live in the gaps. Generalists spanning boundaries also improve knowledge transfer between competency groups and encourage specialists to develop their own breadth.

A generalist’s tool selection tends to be more contextual—they are less likely to reach for a hammer simply because it is familiar. Yet they should weigh tool proliferation carefully: a superior but complicated tool that becomes a burden after its introducer moves on may be worse than sticking with an inferior but universally understood alternative.

Broad skill naturally points Expert Generalists toward leadership. Explaining disciplines to one another builds communication skill; collaboration builds relationships; customer focus and delivery discipline build credibility with business leadership. Organizations that deliberately cultivate Expert Generalists grow technologists with strategic perspective without forcing them into management tracks. All the same, assessment of this skill remains hard—unlike years-on-the-job or certifications, it usually requires intensive evaluation by known-capable Expert Generalists. Without those deep skills for central platforms, an all-generalist team is simply less productive until the generalists acquire the missing depth.

The colleagues we have learned from, the people clients approach with complex problems and new opportunities, have often honed this exact capability without ever having a name for it. Recognizing "Expert Generalist" as a first-class skill rather than a default could improve hiring, training, and ultimately the practice of the profession.

Takeaways

• An Expert Generalist is marked by curiosity, collaborativeness, customer focus, a preference for fundamentals, blended skills, and sympathy for related domains.
• Teams work best as a mix: predominantly Expert Generalists with a few key specialists embedded full-time.
• LLMs make Expert Generalist capabilities more, not less, valuable.
• Expert Generalists keep complex work moving and surface cross-system failures.
• They deserve first-class treatment: deliberate assessment in hiring and promotion cycles, plus dedicated training.

What Shape Describes an Expert Generalist?

Several metaphors attempt to capture the profile of an expert generalist. Kent Beck’s “paint drip people” is memorable, but paint drips aren’t usually something one aspires to be. The “π-shape” acknowledges two deeper skill areas, yet implies an arbitrary ceiling on breadth that doesn’t hold up in practice. A “comb-shaped” profile suggests many deep skills, which is closer, but it falsely implies those skills are all equally deep. No single shape quite fits; the reality is messier, with multiple skills of varying depth that grow and shift over time.

Missing Specialists on a Team

There’s a practical way to gauge whether a team is short on specialist expertise: measure how long it takes to answer questions. This follows Reinertsen’s advice to monitor queue sizes as a leading indicator of bottlenecks. If questions linger unanswered, that’s often a signal that the deep knowledge needed to resolve them isn’t resident on the team.

Acknowledgements

Santosh Mahale contributed to shaping this concept through many discussions. Chris Ford pushed for the section on why organizations need expert generalists. Andrew Thal, Andy Yates, Ankur Dang, Bilal Fazlani, Bill Codding, Bonifacio de Oliveira, Brandon Garlock, Chakrit Riddhagni, Dan Anthony, Fernando Kabas, Florian Sellmayr, Giles Edwards-Alexander, Jim Gumbley, Jimmy Nilsson, Kapil Dube, Kathy Gettlefinger, Ketan Soni, Lauris Jullien, Lovish Pahwa, Lucilene Breier, Michael Strasser, Michaël Le Barbier, Mushtaq Ahmed, Premanand Chandrasekaran, Rick Kick, Steven Peh, Sushant Joshi, Suzi Edwards-Alexander, Swapnil Phulse, Tex Albuja, and Vanessa Towers discussed drafts across various email and chat channels.