"A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly.
Specialization is for insects." — Robert A. Heinlein
I learned the basics of programming in high school by breaking the Wang 286 my father brought home from work in 1987. It was the first computer in Lobos, the small town where we lived. It never occurred to me I could make a living out of it.
At fourteen, I started playing piano. I played in school plays, in a rock band, and in a folklore projection group that went on to win medals of every color several years in a row at the province-wide youth games. The gold one came with a trip to Europe (I know, Argentina in the '90s, huh?) and the possibility of playing before Pope John Paul II. Unreal experience. I never played again after that.
At seventeen, I moved to Buenos Aires to study economics with three guys I barely knew: my father had talked to every parent he came across with kids the same age, so we could split the rent.
I landed my first job doing customer support and implementing ERP software. That kept me busy for a number of years until I hit the limits of customization. I started digging into how those ERPs were built, and I ended up switching careers to study information systems.
By twenty-five I had tried multiple roles and industries. I had led tech projects across LatAm, and learned enough of each role around me (engineers, sysadmins, business analysts, project managers) to keep things running when someone went on vacation, quit, or got hit by the proverbial bus.
I'd also learned to change the diapers of my newborn daughter.
Two kinds of careers
I love getting obsessed with topics. Always have. I have little control over it. My daughter calls them "micro-obsessions." I like pulling at threads until most of my day goes into it. At some point I let go (something unconscious about the marginal cost of getting 1% better, I guess). But it stays there, in the background, until years later it resurfaces because it combines well with something new I pick up, or helps me unpack something more complex.
As I found out, corporations don't have a good box for this. When I worked for them, I constantly bumped into walls. Managers weren't supposed to code. Tech leads weren't supposed to talk to sales. Skipping around the org chart was discouraged by design. So startups became a better fit for me. I could move from architecture to a customer call, or from hiring to product, depending on what was broken that week.
This kind of career, though, is rarely up and to the right. Mine sometimes went sideways, and sometimes straight down. I have taken lower-paying jobs because they gave me exposure to things I didn't understand yet. FinTech, InsurTech, AgTech, BioTech, you name it.
If I had followed a specialist's path, things would have looked very different. I'd be extremely good at one thing. And, in a stable world, that expertise pays: reliable returns, a career ladder, a raise every year.
But what few realize is that it's a concave bet. Imagine dedicating your whole life to driving a horse-drawn carriage, or operating an elevator. If your entire edge is knowing one domain better than anyone else, any disruption to that domain is an existential threat.
A generalist career is the opposite. It's convex. You're wrong a lot. Some jumps lead nowhere. You take pay cuts to change jobs and you abandon skills and start over more times than you can count.
During the pandemic I noticed the growing demand for wine, so I reached out on LinkedIn to the founder of a company that organized wine events (I had seen his name in a newspaper article about wine). Not only did he respond to the message, he reached out to two more people from the wine industry, we gathered, and I ended up putting something together with Next.js, Node.js, and PostGIS that allowed people to search for wines nearby, similar to Drizly. Sadly, though, that endeavor didn't pan out.
But some time later I repurposed the project to allow people to search for cars nearby, instead of wines. It became the first version of the prendo.ar marketplace.
That's the shape of the convex bet in the chart: I lost the time I invested in one attempt, but what I got out of it paid off in a direction I hadn't planned.
Breadth still needs depth
This isn't an argument for knowing a little about everything. Being shallow has very little upside. What I'm describing is closer to what Kent Beck calls a "paint drip": you move the brush across the canvas following your curiosity, and depth forms wherever you stay long enough. You become good at several things, and the combination becomes your edge.
When I started managing larger teams, I missed understanding the details of the technical problems. I remember having to support their estimates for an obscure technology in the SAP ecosystem that I hadn't worked with before. It was impossible for me to work through the trade-offs between delivery risk, deadlines, and committing to something that meant giving my word to customers and leaders, without having the technical visibility I used to have.
So I spent long nights learning enough about it to engage in debates with the strongest technical people on my teams. That helped me adjust scope, negotiate deadlines, and explain delivery risks. Of course, it wasn't possible for me to match their knowledge, but I needed enough depth to ask useful questions and stand behind the answer.
And I understand that there are other times, say you're building a compiler, designing an airplane, or operating on a brain, when you don't want a Renaissance man. You want the person who has done that one thing ten thousand times.
At Magoya I hired someone who had specifically worked with Apache Camel integrating and orchestrating field data from John Deere, FieldView, and similar machinery. He knew about the formats from each vendor, the connection problems in the field, and the particularities of those systems. Hiring someone with that experience shortened the delivery time significantly.
So, should one specialize or generalize?
There are big proponents on each side.
David Epstein, the author of Range, speaks for the generalist side: there are rules that apply in "kind" environments, but not in "wicked" ones.
Malcolm Gladwell, in the other camp, popularized the idea that mastery requires 10,000 hours of practice in one domain.
In the debate below, Gladwell conceded that the principle he proposed works in kind environments, where the rules are clear, feedback is immediate, and patterns repeat. Chess. Surgery. Tennis.
But most of life isn't kind. It happens in what Epstein calls a wicked environment. Rules aren't clear, feedback is delayed or misleading, and you can do the right thing and still get the wrong outcome. Business is wicked. Strategy is wicked. Innovation is wicked.
The least exposed edge
So depth definitely isn't a problem. But having only one area of depth is. Deep knowledge becomes exposed when it can only be applied to problems with stable rules and known answers. AI is very good at that. But we still need to decide which problem to solve when the rules aren't clear.
And who would an increasingly exponential, AI-dominated world reward more: the specialist or the "expert generalist"?
Daniel Rabinovich, COO and former CTO of Mercado Libre, says nothing is riskier today than being a super-specialist. On top of managing 140,000 people, he's a magician, a chess player, a speedcuber, and a musician.
This Harvard study posted 166 R&D problems that specialist teams couldn't crack. About a third were solved by outsiders, and the further the solver's field was from the problem's domain, the more likely they were to solve it. Chemists solving biology problems. Physicists solving chemistry problems.
The outsiders weren't necessarily better at solving the original problem. Their distance from the field helped them see that it could be framed differently. Range gives us more than additional knowledge; it gives us more places from which to look at a problem.
At one company, my engineering team saw strange spikes in operations at the beginning of every month. Since they could affect capacity planning, the team was looking for a technical explanation. I had worked with sales teams before and knew they were paid against monthly targets. Once people hit their target, they would hold operations until the next period. There was nothing to fix (technically, anyway).
As AI makes technical execution abundant, more of the work will move upstream: deciding what problem is worth solving in the first place.
When Opus 4.5 was released around December 2025, I tested it against our take-home exercise: building an insurance quote orchestrator in Node.js and React. The model one-shotted the solution. The finished code no longer revealed how the candidate thought.
Now I provide the exercise a few minutes before the live test and we build it together during the call (allowing the candidate to use AI). I don't need to find out whether they can produce the code. I need to understand how they think while producing it.
AI is also lowering the barrier to entering a new topic faster. That gives us breadth, but we still need to know enough to notice when the answer doesn't make sense.
And there are still times when we need actual specialists.
No one searches for a generalist
But there is a problem with the expert generalist approach: explaining what you do. Nobody searches for a generalist. A recruiter searches for a specific role. A founder searches for help with a specific problem. "I've done many different things" isn't an answer either of them would find useful.
When I started working as a fractional CTO I put together a one-pager with all the things I could do to help companies. Nobody called.
Then I started posting consistently and talking to people in my network who had specific problems. A founder wanted to technically assess a platform they were about to acquire. Another wanted help understanding how to evolve an old business model into an AI play. I ended up shaping my offerings around problems I'd already tackled, which drew more founders to my page.
"Fractional CTO" by itself is still too broad. One of my actual doorways is Fractional CTO for US startups from pre-seed to Series A. One role, one company stage, one market. A founder who needs to ship a product, build a team, or prepare for technical due diligence can tell whether that page is for them.
Once I'm working with them, the title matters less. One day I may review an architecture, the next I may help with hiring or join a customer call.
The title tells people where to find me. It doesn't tell me what I'm allowed to learn next.
So that's why I like the new possibilities AI opens up for anyone willing to pursue them. It allows us to move up a layer of abstraction, and to expand our knowledge horizontally across fields.
And maybe it's time to change a diaper, plan an invasion, write a sonnet, program a computer, and cook a tasty meal.
After all, that's what humans are for.
Specialization is for insects.
