I Was Never The Best Programmer In The Room

For a large part of my career, I worked with people who were better than me at something. Better programmers. Better database specialists. People who understood a particular technology at a depth I probably would never reach. Later, I met managers, architects and product people who were better than me in their fields too.

Sometimes that was intimidating. I would watch someone solve a technical problem that I found genuinely difficult and my natural reaction was to try to catch up. Over time, though, I started noticing something. Some gaps aren't closed by reading another book or taking another course. People have different strengths, interests and ways of thinking.

I could spend another five years trying to become the best programmer in the room, but I was becoming less convinced that this was where I could create the most value.

A Little Code, A Little Business

Around the time my journey with Flash was coming to an end, I started noticing something else about myself. I could talk to developers. I understood their problems and why some things couldn't "just be done." But I could also sit down with a customer and talk about their business without turning every conversation into a technical one.

The question that interested me was slowly changing from "How do we build this?" to "Why are we building this?" I didn't stop caring about technology. I simply started adding other pieces to it: product, architecture, delivery, finance, people and business. None of them replaced what came before. The picture just became wider.

A Normal Day Became A Strange Mix Of Everything

Running a software house accelerated that process. A typical day could start with a morning briefing with one or more teams. Then coffee with my business partner to talk about plans, customers and finances. Shortly afterwards, I might be helping developers solve a problem.

An hour later, I would be explaining that same problem to a customer — why it mattered, what the constraints were and why something couldn't be delivered by Friday. Then I might look at team velocity, requirements, budget, recruitment or architecture before going back to another customer conversation.

If I had tried to be the best specialist in the room in every one of those areas, I probably wouldn't have done any of them particularly well. What I started to see instead were the connections between them. A technical decision affected the budget. The budget affected the team. The team affected delivery. Delivery affected the customer. A business requirement affected the architecture. And an architectural decision could return months later as a business cost or constraint.

They weren't separate worlds anymore.

The Most Expensive Pen

For a long time, I thought about great specialists a little like very expensive pens. A great pen is precise. Refined. In the right hands, it can produce something exceptional. And every organization needs people like that.

I eventually realized that I was becoming something different. More like a box of crayons. No single crayon needs to be the finest drawing instrument in the world. But together, they can draw the whole picture — and color it too.

That distinction took me surprisingly long to appreciate.

Breadth Can Look Like A Weakness

When you're surrounded by people with deep expertise, their value is easy to see. They can do something you simply cannot. Breadth is harder to recognize. You know something about architecture. You understand development. You can talk to the business. You know enough about product, delivery and finance to participate meaningfully in those conversations.

But you're not the best person you know in any one of those areas. For a while, that can feel like a lack of specialization rather than a strength. Eventually, I realized that value doesn't always sit inside one of the dots. Sometimes it exists between them.

Connecting The Dots

Today, that's probably the simplest way I would describe one of my strongest skills: connecting the dots. Business sees a business problem. A developer sees a technical problem. Finance sees a cost. An architect sees dependencies. Product sees the user's needs. All of them can be right.

The solution often sits somewhere between their perspectives. I don't need to understand databases better than the best database engineer. I don't need to write better code than the best developer. I don't need to understand finance better than a CFO.

I need to understand enough of each world to see how they affect one another — and to help the people inside those worlds understand each other.

Breadth Can Be A Specialization Too

For years, the technology industry has been very good at naming specialists: Backend Developer, Frontend Developer, Database Engineer, Architect, Product Manager. Each of those specializations has enormous value.

But there is another kind of role that is harder to put into a single box: people who move between disciplines, translate one world into another and notice dependencies that are easy to miss when everyone is focused deeply on their own area.

For a long time, I didn't think of breadth as a specialization. Today, I do.

Final Thoughts

If I could tell my younger self one thing, it wouldn't be to spend less time learning programming. It would be: don't limit yourself.

Learn from people who are better than you. Let them be better than you. You don't have to become every one of them. Learn enough to understand what they see — and then learn to see the whole picture.

Sometimes an organization needs the finest pen it can find. And sometimes it needs someone with the whole box of crayons.