For most of my career I was told to pick a side. You are either the person who decides what to build or the person who builds it. Strategy or execution. The whiteboard or the codebase. The advice is well meant, and for a long time I half believed it. I have come to think it is mostly wrong.
The split is real as a matter of org charts. It is much weaker as a matter of how good work actually happens. The best decisions I have seen were made by people close enough to the building to know what was cheap and what was expensive. The best builds I have seen were shaped by people who understood the decision the work was meant to serve. When those two kinds of knowing live in different heads, something is always lost in translation.
What you learn by crossing the line
When I built The Hub, a 0-to-1 platform we shipped to five enterprise clients, the most valuable thing I had was not a framework. It was the ability to sit in a client conversation in the morning, hear a vague worry about how a program was tracking, and that afternoon understand exactly what it would take to turn that worry into a feature. The distance between the problem and the thing was short because the same person held both ends of it.
That is the quiet advantage. Not that you are the best strategist or the best engineer in the room, but that you compress the loop. You spend less time writing documents that explain the problem to the people who will solve it, because you are also one of those people.
The point is not to be a generalist. It is to keep the problem and the solution in the same pair of hands long enough to learn something.
The cost, and why it is worth paying
Crossing the line is not free. You will be less specialized than the people who never left their side, and there are rooms where that shows. Depth is real and it matters. But specialization has a failure mode that nobody warns you about: you can become very good at producing the right answer to the wrong question.
The way you avoid that is by staying close enough to the work to feel when the question is wrong. You notice it in the friction, in the thing that should be easy and is not, in the gap between what the plan assumed and what the code revealed. You can only feel that friction if you are touching both.
So I have stopped trying to pick a side. I structure the ambiguous problem, I build the first version, and I ship it. The order changes. The instinct does not.