How to bridge the gap: I’ve always been a frustrated engineer
Why non-technical leaders struggle to understand engineering teams.
For most of my career, I’ve worked with engineering teams without being an engineer.
At Google.
At Yahoo.
At Idealista.
In roles where technology decisions shaped the trajectory of the business, but where I was not the one writing the code.
That experience is more common than we admit.
And it comes with a certain kind of frustration.
Close, but not quite there
At Google, I was one of the few product managers without a technical background.
At the time, that was unusual. Most product roles were reserved for engineers, and for good reason. The complexity of the systems required a level of understanding that was difficult to fake.
But even surrounded by exceptional people, I always felt there was a layer I couldn’t fully access.
You could understand the roadmap.
You could discuss priorities.
You could align on outcomes.
But when it came to the actual dynamics of how work moved through the system, things became less clear.
Why something was delayed.
Where quality was breaking down.
How teams were really performing.
You relied on translation.
Managing through interpretation
That pattern didn’t change much as I moved into more senior roles.
At Yahoo, leading larger teams, the stakes were higher, but the dynamic was similar.
You listened carefully, you asked questions and you tried to connect technical signals to business outcomes. But there was always a gap.
Not because the teams lacked data. But because the way that data was expressed was not designed for decision-making at a business level.
So you managed through interpretation.
And over time, you develop intuition:
You sense when something is off.
You feel when execution is slowing down.
You recognize patterns in how teams operate.
But intuition has limits: It is hard to explain, even harder to prove and impossible to scale.
A structural limitation
For a long time, I assumed this was just part of the job.
If you were not technical, there was a ceiling to how deeply you could understand engineering. You could get close, but never fully there.
And that created a tension in leadership. Either you delegated completely to your CTO and accepted a certain level of opacity or you pushed harder on delivery without fully understanding the system, which often created more friction than progress.
Neither approach felt right but there was no real alternative.
What changed
What has changed recently is not just the technology itself, but the ability to observe it.
For the first time, we are starting to see a way of understanding engineering work without relying on translation.
Not by simplifying or abstracting it further, insted it works by connecting directly to the work and expressing it in a way that is understandable across roles.
Delivery, quality, focus, rework, efficiency are measured not as isolated metrics, but as part of a system that can be observed and reasoned about.
That changes something fundamental.
The end of the handicap
I no longer think of being a non-technical leader as a handicap.
Not because the complexity of engineering has decreased, but because the visibility into that complexity has improved.
For the first time, it is possible to engage with engineering performance without relying on intuition or second-hand narratives.
To understand not just what is being built, but how effectively it is being delivered.
To connect effort with outcome in a way that is grounded in evidence.
That creates a different kind of conversation. One where technical and non-technical leaders are no longer operating from different realities. Pensero make it possible to see how work moves, how teams operate, and how outcomes are produced.
Why this matters now
Technology is not a support function, it is the core engine of most companies.
And yet, many leaders still operate without a clear line of sight into how engineering effort translates into business impact.
That gap becomes more visible as systems become more complex, teams become more distributed, and AI starts to change how work is produced.
The cost of not understanding increases, and so does the need for clarity.
Why I care about this (and why you should care too)
I’ve spent years operating one step away from that reality.
Close enough to feel the impact, but not close enough to fully understand it.
And once you realize that this gap is not inherent, that it can be addressed, it becomes difficult to accept it as part of the job.
For a long time, managing engineering without being an engineer felt like a structural limitation. I don’t see it that way anymore. What used to be a handicap is becoming a solvable problem.
And that changes something fundamental, not just in how teams are managed, but in how decisions are made at the highest level.
For most of my career, I’ve worked with engineering teams without being an engineer.
At Google.
At Yahoo.
At Idealista.
In roles where technology decisions shaped the trajectory of the business, but where I was not the one writing the code.
That experience is more common than we admit.
And it comes with a certain kind of frustration.
Close, but not quite there
At Google, I was one of the few product managers without a technical background.
At the time, that was unusual. Most product roles were reserved for engineers, and for good reason. The complexity of the systems required a level of understanding that was difficult to fake.
But even surrounded by exceptional people, I always felt there was a layer I couldn’t fully access.
You could understand the roadmap.
You could discuss priorities.
You could align on outcomes.
But when it came to the actual dynamics of how work moved through the system, things became less clear.
Why something was delayed.
Where quality was breaking down.
How teams were really performing.
You relied on translation.
Managing through interpretation
That pattern didn’t change much as I moved into more senior roles.
At Yahoo, leading larger teams, the stakes were higher, but the dynamic was similar.
You listened carefully, you asked questions and you tried to connect technical signals to business outcomes. But there was always a gap.
Not because the teams lacked data. But because the way that data was expressed was not designed for decision-making at a business level.
So you managed through interpretation.
And over time, you develop intuition:
You sense when something is off.
You feel when execution is slowing down.
You recognize patterns in how teams operate.
But intuition has limits: It is hard to explain, even harder to prove and impossible to scale.
A structural limitation
For a long time, I assumed this was just part of the job.
If you were not technical, there was a ceiling to how deeply you could understand engineering. You could get close, but never fully there.
And that created a tension in leadership. Either you delegated completely to your CTO and accepted a certain level of opacity or you pushed harder on delivery without fully understanding the system, which often created more friction than progress.
Neither approach felt right but there was no real alternative.
What changed
What has changed recently is not just the technology itself, but the ability to observe it.
For the first time, we are starting to see a way of understanding engineering work without relying on translation.
Not by simplifying or abstracting it further, insted it works by connecting directly to the work and expressing it in a way that is understandable across roles.
Delivery, quality, focus, rework, efficiency are measured not as isolated metrics, but as part of a system that can be observed and reasoned about.
That changes something fundamental.
The end of the handicap
I no longer think of being a non-technical leader as a handicap.
Not because the complexity of engineering has decreased, but because the visibility into that complexity has improved.
For the first time, it is possible to engage with engineering performance without relying on intuition or second-hand narratives.
To understand not just what is being built, but how effectively it is being delivered.
To connect effort with outcome in a way that is grounded in evidence.
That creates a different kind of conversation. One where technical and non-technical leaders are no longer operating from different realities. Pensero make it possible to see how work moves, how teams operate, and how outcomes are produced.
Why this matters now
Technology is not a support function, it is the core engine of most companies.
And yet, many leaders still operate without a clear line of sight into how engineering effort translates into business impact.
That gap becomes more visible as systems become more complex, teams become more distributed, and AI starts to change how work is produced.
The cost of not understanding increases, and so does the need for clarity.
Why I care about this (and why you should care too)
I’ve spent years operating one step away from that reality.
Close enough to feel the impact, but not close enough to fully understand it.
And once you realize that this gap is not inherent, that it can be addressed, it becomes difficult to accept it as part of the job.
For a long time, managing engineering without being an engineer felt like a structural limitation. I don’t see it that way anymore. What used to be a handicap is becoming a solvable problem.
And that changes something fundamental, not just in how teams are managed, but in how decisions are made at the highest level.
