On 'Expert Generalist' — an influence on how I describe my work

For a long time I did not have a good answer to the question that most often gets put to engineers who have been around for a while: what are you, exactly? The honest answer — "I learn the next thing quickly, I have several deep stripes, I move comfortably between platform work, regulated systems and AI/ML, and I prefer to design with the people who live in the domain" — does not fit on a CV line. The shorter answers are all a little wrong. "Full-stack engineer" undersells the platform and architecture work. "Platform engineer" undersells the time spent in clinical, financial and retail domains. "Architect" sounds like someone who has stopped writing code. "Principal engineer" is a title, not a description. None of these say what the job actually is.

The phrase I have started using — and the one I am putting on this site — is Expert Generalist. I borrow it directly from Martin Fowler, Unmesh Joshi and Gitanjali Venkatraman's Expert Generalists, published on martinfowler.com in July 2025. Their argument is that the engineers who keep producing value across two decades of shifting tools are the ones who can learn fast, recognise the patterns running underneath whichever platform is currently in fashion, and apply those patterns wherever the work lands. Generalism, treated seriously, is itself an expertise. That framing finally matched the shape of the work I have actually been doing, and the relief of having a name for it is what prompted this post.

What follows is an attempt to walk through the six characteristics they describe and pin each one to a moment in my career where it cost me something to learn — or where, more rarely, it paid off because I had already learned it. I do not claim to have invented the framework. I align with it.

What the authors actually say

Fowler and his co-authors push back on the old T-shape sketch of engineering careers — one deep stripe of specialism, a wide bar of general knowledge across the top. They observe, accurately, that the careers they admire do not look like that. They look like combs: several deep stripes alongside the breadth, not one. Or, in a metaphor borrowed from oil-painting, like paint-drips — strokes of real depth in unexpected places, accreted over time.

The six characteristics they list travel together:

Curiosity — learning a new domain is its own reward.
Collaborativeness — humility on entering unfamiliar territory; work with specialists rather than around them.
Customer focus — curiosity steered by user and business need, not by the next shiny tool.
Favour fundamental knowledge — patterns and trade-offs over tool-specific recipes.
A blend of generalist and specialist depth — multiple stripes of genuine depth, not one.
Sympathy for related domains — an intuitive grasp of adjacent fields you don't own (UX, infra, data, ops), borrowed from Jackie Stewart's mechanical sympathy.

The original article is the canonical reference and is worth reading in full. What I want to do here is not summarise it again — they have already done that better than I could. What I want to do is walk through each trait with a story attached, because the framework only becomes useful when it stops being a list and starts being a way of recognising what you are doing while you are doing it.

Curiosity — Just Eat, 2010, and the EPOS printers

I joined Just Eat as one of the first twenty technical hires, when the platform was being rebuilt out of its student-prototype origins. The headline work was the kind of re-architecture engineers like to put on a CV — moving an ASP.NET WebForms estate over to MVC 3, layering it properly, putting in a Ruby-and-Jenkins deployment pipeline, internationalising for new markets. That work was real, and I am still proud of it. But the part I remember most clearly is the bit nobody else wanted to look at: the EPOS printers.

A restaurant's electronic point-of-sale terminal is a stubborn little box behind the counter that prints receipts, takes card payments and decides what the kitchen is cooking next. For Just Eat to actually function as a marketplace — for a customer's online order to land in the right kitchen at the right moment, without someone hand-keying it into the till — the platform needed to put orders directly onto those terminals. There are dozens of different printer models. They speak proprietary serial protocols. The vendor documentation, where it exists, was written for someone integrating a single installation, not a marketplace.

I found the problem unreasonably interesting. Not because integration is glamorous — it isn't — but because the work was a chain of small puzzles I had no business solving and therefore wanted to solve. I sniffed packets. I matched them against half-translated Japanese protocol PDFs. I sat with restaurant operators on Friday nights and watched what the till actually did when a chef shouted at it. I learned the difference between an "order" on the marketplace side of the wire and an "order" in the kitchen, which is nothing like the same thing.

This is what the authors mean by curiosity as its own reward. Nobody asked me to find the printer problem interesting. I had been hired to do the .NET work. But the printers were a doorway into a domain — restaurant operations — that I would still be drawing on a decade later when I worked on retail analytics, clinical workflows, and even, eventually, agentic-coding feedback loops. Curiosity that is steered, that does not chase the shiny thing, lays down stripes you only notice later.

Collaborativeness — Philips, 2019, and the radiologists

A decade and several companies later I was at Philips, leading the architecture for what we called the Clinical AI App Store — a container-based platform that ran third-party machine-learning models inside more than three hundred hospitals, on air-gapped VMware estates, using Kubernetes operator patterns to do the lifecycle work that in a less regulated world you would do with a kubectl and a coffee. The constraints were technical (ISO 13485, IEC 62304, HA clusters, HL7/FHIR integration with PACS/RIS and imaging equipment), and the geography was global. The platform piece looked, on paper, like a problem I had solved variations of before. Kubernetes is Kubernetes.

The piece that taught me something new was the diagnosis feedback loop, and the lesson was not technical. It was collaborative.

A model running on a CT image in a hospital is not a benchmark. It is a recommendation a clinician will accept, override, or quietly disagree with. We wanted to capture all three, so the model could be validated against real-world results, and the mechanism on the wire was HL7 lab messaging — when a patient was later given a diagnosis, the message came back into our platform and was correlated against what the model had said. I drew the first version of that architecture from the engineer's side: inference produces a structured output, the diagnosis is a structured output, match them on patient identifier and study, accumulate, report. Done.

The first time I sat with a radiologist, I learned that almost every word in that sentence was hiding something. A "diagnosis" is not a moment — it is a process. A "patient identifier" is several identifiers, depending on message and source system. "Matching" is a clinical decision dressed up as a technical one. The version we eventually shipped was the same Kubernetes and HL7 and FHIR I would have built either way — but the seams were drawn by people who had spent careers in radiology, not by someone who had spent two weeks reading the HL7 specification.

What I took away is not that you have to be humble for soft reasons. You have to be humble for engineering reasons — because the design you would draw without the domain experts will be subtly wrong, and subtle wrongness in clinical software is the kind of wrongness an audit catches three years later. Collaboration in this sense isn't soft. It is the cheapest way to not be wrong.

Customer focus — Yagro, and the farmer with the tablet

The trait that took me the longest to internalise is also the one Fowler and his co-authors list third: customer focus, the discipline of steering curiosity by user and business need rather than by the next interesting problem. I think it took me longer because it sounds, on first reading, like a thing a product manager says. It isn't. It is an engineering discipline about where you let your attention go.

The moment it crystallised for me was at Yagro, building agricultural analytics for UK arable farms. The platform had clean Go services, a respectable data pipeline, dashboards that did everything a good analyst would want them to do. The dashboards lived on a laptop in an office. The farmers, for their part, lived on a tractor in a field, often without a reliable signal, often holding a muddy tablet with one hand while doing something with the other. The audience for our analytics — the audience who actually had to act on it — was not the audience we had been designing for.

That is the kind of mistake that is invisible from the engineering side of the wire. You can build a faster query, a tidier schema, a more elegant service mesh, and never close in on the actual question, which is: what does the person looking at this need to decide, where, when, on what device, with what attention? The answer reframes which performance numbers matter, which screens are worth building, and which clever features are worth not building. Curiosity left to itself would have kept us deepening the dashboards. Customer focus made us thin them down.

I think the test for this trait is uncomfortable but useful: when you are midway through a piece of interesting technical work, can you say out loud, in one sentence, whose Tuesday it improves? If you can't, the work is probably yours, not theirs.

Favour fundamental knowledge — patterns across stacks

The fourth trait is the one I find most professionally consequential, and the one that is most undersold by the way we usually hire and promote. The authors call it favouring fundamental knowledge — patterns, principles and trade-offs over tool-specific recipes. In my own working memory, it is the quieter observation that when you have been doing this for long enough, the same handful of patterns keep reappearing under different brand names, and the engineers who can see that are the ones who do not have to start over every five years.

Distributed messaging is a clean example. I have used MSMQ, RabbitMQ, Kafka, NATS, Amazon SQS, Google Pub/Sub, Azure Service Bus and a couple of in-house buses across employers. The marketing pages talk about each as if it were a new thing. The underlying decisions — at-least-once versus exactly-once, partitioning strategy, consumer-group semantics, retry and dead-letter design, ordering guarantees, idempotency keys — are not new things. They are the same handful of trade-offs, reskinned. An engineer who has internalised that does not need a week to ramp up on the next bus. An engineer who hasn't will keep building the same subtle bugs in each one.

The same is true of state. CQRS, event sourcing, reconciliation loops, GitOps, controllers, agentic feedback loops — I wrote about how often I keep finding the last of those in Reconciliation loops everywhere — all of them are variants of one idea: separate the intent from the observation, let a controller close the gap. Once you see the pattern you do not need to learn the next operator framework from scratch.

The reason this matters, beyond personal productivity, is that pattern-level fluency is what makes you portable across stacks and across decades. I have shipped production code in C#, F#, Java, Kotlin, Swift, JavaScript, TypeScript, Python, Go and Rust. The languages were not the point. The patterns were the point. The languages were how the patterns happened to be spelled that year.

Comb-shaped depth — BrightInsight and the DSL

The fifth trait — multiple stripes of real depth, comb-shaped rather than T-shaped — is the hardest to claim about yourself, because it is the one that depends on having actually done the depth, not just having read around it. It is also the one I think the industry mis-rewards. We compensate specialists for narrow depth and generalists for breadth, and we under-pay the engineers who have, slowly and stubbornly, built several stripes.

The piece of work I think of when I think about my own comb is the indemnity-insurance DSL at BrightInsight. The legal constraint there is unusual and severe: given the same answers to an indemnity questionnaire, the system must produce the same decision over a specified period. Reconciling that determinism requirement with a continuous-delivery practice required the rules to live somewhere other than the application code. The team's instinct, and mine, was to design the rule engine first. The underwriters' rules refused to fit. So we slowed down, sat with them, watched them build a product on paper, and let a JSON configuration grow toward what they were actually trying to say. By the end it was a domain-specific language — a language for the underwriters' domain, not ours — and the underwriters owned it the way analysts own SQL.

That single piece of work touched three of my stripes at once: platform and continuous-delivery engineering (so the cadence didn't break), regulated-systems engineering (so the determinism was provable under audit), and language and protocol design (so the rules read like English to the underwriters). It would not have happened if I had only had one of those stripes, however deep. Comb-shaped is not a vanity description; it is what made the work possible at all.

I have since written more directly about why I think pattern-driven design only works once you understand the domain it serves — learn the domain before the abstraction — but the BrightInsight DSL is the one I keep returning to when I am asked what comb-shaped means in practice.

Sympathy for related domains — Vodafone and mechanical sympathy

The last of the six characteristics is borrowed, in the original article, from a phrase Jackie Stewart used about racing drivers: mechanical sympathy. The driver who understands what the engine is doing under the bonnet does not need to be a mechanic; they need an intuitive feel for what the machine is and is not willing to do. Fowler's co-authors extend the metaphor to engineering. The backend engineer who has a feel for UX. The infrastructure engineer who has a feel for data. The application developer who has a feel for ops. None of them are specialists in the adjacent field. All of them know enough to design with that field in mind, rather than against it.

I learned this most explicitly during the Vodafone platform-engineering years, working on developer platforms that sat between application teams and the operations function. The temptation, as a platform engineer, is to treat ops as a downstream consumer of your abstractions. You build a paved road, you let teams self-serve, you measure adoption. The work goes sideways when the platform team treats ops, security, design and data as problems to abstract away rather than disciplines to design with.

What changes when you have mechanical sympathy for those adjacent disciplines is that the design choices subtly shift. The runbook is not an afterthought; it is a first-class artefact you co-author with the on-call. The threat model is not a security gate at the end; it is a constraint you fold into the design. The data contract is not "what the lake team needs"; it is part of the shape of the service. The cost of these moves is small and the alternative is the platform that gets built three times, once for each discipline that was ignored the first time.

The bit of this trait I find easiest to test for in myself, when I am about to design something, is the small question: who is this design going to surprise? If the answer is "the people who run it in production," or "the people who depend on its data," or "the people who have to defend its security posture," I have not done the sympathy work yet.

Where the traits cut against each other

The six characteristics travel together, but they also pull against each other, and pretending they don't is part of why the framework can read as aspirational. The honest version is that you spend most of your career managing the tensions.

Curiosity pulls against customer focus. Left alone, curiosity will follow the interesting problem; customer focus has to be the constant gentle hand on the steering wheel. There is a particular failure mode — common in senior engineers — of being unable to leave a fascinating side-problem alone when the work the team is actually being paid to do sits next to it. Knowing which problem is yours to chase, and which is someone else's, is the part of the job that does not get taught and does not get cheaper with experience.

Comb-shaped depth pulls against the cost of staying current. Every stripe of real depth has a maintenance cost. Languages move on, paradigms shift, the cloud provider's preferred way to do the thing changes between KubeCons. The realistic version is that some stripes will drift while you are concentrating on others, and you have to be honest about that — both when you describe yourself and when you decide which stripe to refresh next.

Collaborativeness pulls against decisiveness. The instinct to ask the specialists first is right almost always, but there are moments where a generalist's job is to make the call, take the heat, and move on. Knowing when those moments are — and being willing to be visibly wrong — is the non-obvious cost of the trait.

These tensions are not a bug in the framework. They are the framework. The six traits are not a checklist you tick. They are a set of forces you balance, and the balance shifts with the work, the team, and the decade.

What this means day-to-day

The reason any of this matters, beyond CV vocabulary, is that the framing shapes the work I take, the way I describe it, and the way I pair with specialists. Concretely:

I look for work that has at least two of my stripes in it, not just one. The single-stripe roles tend to under-use what I am actually for; the work where platform engineering meets regulated systems, or where AI/ML platform work meets domain language design, is where I am most useful and most engaged.

I describe myself, in conversation, by the traits and the stripes — not by the title. "I learn new domains quickly and I have stripes in platform engineering, regulated systems, AI/ML platforms and language design" is a truer sentence than "I am a principal engineer," and it gives the person asking enough surface area to find out whether what they need is in there.

I pair with specialists deliberately rather than competing with them. The radiologist, the underwriter, the on-call engineer, the data analyst, the designer — these are the people whose expertise the platform has to respect, not abstract away. The job of the generalist, in that pairing, is to translate, to find the patterns, and to give the specialist a medium — a DSL, a contract, a paved road — through which their expertise reaches production.

And I try, in writing pieces like this one, to make the framework legible to the next engineer in this shape, because the thing I most wish someone had said to me earlier in my career is that generalism — done seriously, with stripes — is not a fallback. It is a craft of its own.

A closing note

I have linked to the original Fowler, Joshi, and Venkatraman article a couple of times in this post and I will do it once more, because it is worth reading on its own terms: Expert Generalists. The framework is theirs. The career stories are mine. The reason I have put the phrase on this site is that, after twenty-five years, Expert Generalist is the closest name I have found for the shape of the work I have actually done — and a shape that, if you recognise it in yourself, is worth claiming.

— Madu