"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 ended up playing in a folklore group that, after a few years of medals of every color, won the province-wide youth games and a trip to Europe (apparently there was still something left in the province's coffers in the '90s). As part of the prize, we got to play for Pope John Paul II. 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, until I hit the limits of customization and started digging into how those ERPs were built. I ended up switching careers to study information systems.
By twenty-five I had tried multiple roles and industries. I led tech projects across LatAm, and out of necessity I'd 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 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). 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 discovered that managers aren't supposed to code and that tech leads have no business talking to sales. Nobody liked the person skipping around the org chart. 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.
But mind you, this kind of career is rarely up and to the right. Mine sometimes goes sideways, or even 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.
Had I followed a specialist's path, things would have been obviously different. Specialization would have pushed me deep into a single area. And, in a stable world, that expertise pays: reliable returns, a career ladder, a raise every year.
But the part that goes unnoticed is that it's a concave bet. When your entire edge is knowing one domain better than anyone else, any disruption to that domain is an existential threat. Imagine dedicating your whole life to driving a horse-drawn carriage, or operating an elevator.
A generalist career is the opposite bet. 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.
Some detours never paid directly. 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. He answered, 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. That endeavor didn't pan out.
But the stack and architecture didn't disappear. I repurposed the project to allow people to search for cars nearby. It became the first version of the prendo.ar marketplace. The wine project failed; the work didn't.
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 technical problems. I missed sharing the pain with the team. 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.
So I spent long nights learning enough about it to be dangerous and engaged in debates with the strongest technical people on my teams. That helped me adjust scope, negotiate deadlines, and explain delivery risks. I wasn't trying to match their knowledge. I needed enough depth to ask useful questions and stand behind the answer.
And if you're building a compiler, designing an airplane, or operating on a brain, you don't want the renaissance man. You want the person who has done this 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 when should we value specialization over generalization?
David Epstein gives a useful distinction in Range: some environments are "kind" and others are "wicked."
Malcolm Gladwell popularized the idea that mastery requires 10,000 hours of practice in one domain. In the debate below, Gladwell conceded that the principle 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
Depth isn't the problem. 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 getting very good at that. But we still need to decide which problem to solve when the rules aren't clear.
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 you more than additional knowledge; it gives you 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 moves 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.
As a generalist, I've worked hard all my life to be as good as the specialists at any given subject. AI hasn't changed that. It just lets me get into a topic faster. I still need to know enough to notice when the answer doesn't make sense, and there are still times when I need actual specialists. The edge isn't knowing everything. It's recognizing which kind of problem I'm dealing with, and who or what I need to solve it.
No one searches for a generalist
But there is a problem with the expert generalist approach: explaining what I 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 a useful answer for either of them.
"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 if you've made it this far, I'd like you to go back to the beginning of this article and read Heinlein's quote. 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.
