Published: Jun 28th, 2026 - 9 min read
One of the most expensive decisions a senior professional can make is to keep accumulating experience without asking what it should become.
Not because experience stops mattering. It is the opposite problem: after enough years, the experience itself stops being the bottleneck. What replaces it is a quieter question that most careers never pause long enough to ask: once you have it, what do you do with it?
I did not arrive at that question through reflection. I arrived at it through two unrelated efforts, the same year, that turned out to be answering it from opposite directions.
I was building a pitch slide, the kind you prepare for a cloud startup program, the kind that needs one chart that makes a stranger lean forward in the first ninety seconds.
The product was healthyCar: a predictive, preventive application that reads a vehicle's health in real time, using onboard diagnostic telemetry sent over a 4G connection to a cloud backend, and tells the owner what is about to go wrong before it does. By that point I had the OBD pipeline working. The architecture had been validated by three separate cloud startup programs, each one granting credits to keep building. What I needed now was something different: proof that people actually wanted what I had built.
So I sent out a survey. Forty-three vehicle owners answered.
Two of the questions sat next to each other in the results in a way that stopped me. The first: how could you have anticipated this breakdown? The dominant answer, by a wide margin: preventive maintenance. The second: and when the problem actually hit you, what did you do to solve it? The dominant answer, just as wide: call the mechanic.
I read that twice.
Forty-three people had just told me, in their own words, that the correct answer was prevention. And then, almost in the same breath, that prevention was not what they actually did when it mattered. Not because they didn't know better. Because knowing better and acting on it were two different systems entirely, and only one of them activated when the engine actually failed.
I had spent months validating whether the technology worked. Nobody had asked me to validate whether knowing would change anything.
Around that same period, I was teaching part-time at the public university in Piura where I had studied, years earlier, as an undergraduate.
I started noticing something in my colleagues there: professors, some of whom had once taught me and were now teaching alongside me, with a quiet intention to update their own skills, without quite knowing where to start. Nobody had asked me to fix that. I proposed something specific: the CCNA, the same certification path that had shaped the early structure of my own career.
It was not simple to organize. Schedules didn't align. Holidays interrupted the rhythm. Priorities shifted more than once across the preparation period. But they kept at it, and all three passed the exam on their first attempt.
A year earlier, I had done the same thing, informally, for eight former students from the same university. Eleven people in total, across two years, certified in something I had spent two decades using professionally.
Nobody paid me for either effort. There was no platform behind it, no app, no architecture, no pitch deck. Just the same expertise that had gone into every system I had ever designed, pointed at people instead of infrastructure.
For most of my career, the question in front of me was always some version of: how do I solve this technical problem correctly? The CCIE taught me to ask it with precision. Every architecture I built afterward, across banking, telecommunications, and enterprise technology, was an attempt to answer it well.
But somewhere between the survey results and that classroom in Piura, I noticed a different question forming, one I had never deliberately asked before: what should twenty years of experience become, once accumulating more of it stops being the point?
healthyCar was one answer. Take the experience, the telemetry pipelines, the observability instincts built across a career, and turn it into something that could read a system's health without me standing next to it. A product. The business model was straightforward on paper: a subscription for vehicle owners, a membership and commission structure for the mechanical workshops that joined the network. The target was modest and concrete: one hundred new vehicle owners a month and twenty partner workshops in the first year. None of that mattered yet, because the survey had just shown me that the harder problem wasn't the subscription model. It was the gap between knowing and doing.
The CCNA effort was a different answer to the same underlying question. Take the same expertise and place it directly inside people, so that what I knew did not depend on a platform to keep existing. Not a product. A shortened learning curve for someone else, paid for in time rather than money.
It took me years to realize that both were attempts to make experience outlive the moment I was personally present.
healthyCar needed a survey to tell me what was missing: a relationship reliable enough to earn an ordinary Tuesday, not just a correct prediction. I had built a diagnostic system. I had not built a reason for anyone to check it before something broke.
The CCNA effort never needed that survey, because the relationship already existed before the exam did. I wasn't introducing a tool to strangers who had to be convinced. I was someone they already knew, in a hallway they already walked through, asking them to spend a few more months becoming who they already wanted to be.
That is the same gap, seen from two directions. With healthyCar, I had the architecture and had to go looking for the trust that would carry it. With the CCNA group, I had the trust already in place, and it carried eleven people through an exam, on the first attempt, without needing any system to enforce it.
Neither direction was smaller than the other. They were the same expertise, solving the same underlying problem, through completely different mechanisms.
In large organizations, I rarely had to make someone care about the outcome. The stakes did that before I ever arrived. A hospital boardroom already knew what was at risk in its network. A mobile operator already knew the cost of a degraded service.
Building healthyCar and teaching that classroom both removed that scaffolding. Nobody's mandate was doing the caring for me. And in the absence of a mandate, I learned something that twenty years inside institutions had never forced me to learn: experience only compounds when it is converted into something that keeps creating value without requiring my continued presence, a product that runs without me watching it, or a person who no longer needs me once they have crossed the certification line.
That is descubre.pe, in full. Not one company with one product, but the same expertise solving the same underlying question through different mechanisms. healthyCar turns experience into a product. The classroom in Piura turns it into people who carry it forward on their own. Different mechanisms. Same underlying answer to the same question.
For most of the last twenty years, I measured my own growth the way most technical careers measure it: by depth. Another certification. Another architecture. Another system that worked because I understood it better than the person who built the one before it.
That measure stopped being sufficient the moment I read those forty-three survey responses and stood in front of that classroom in Piura in the same year. Depth answers a different question than the one I had started asking. Depth tells you whether you understand the system. It does not tell you whether anyone is better off because you do.
I do not think this realization belongs only to founders or to people building a startup on the side. Most senior professionals eventually reach a point where they know more than the immediate problem in front of them requires. What happens to the surplus is rarely a deliberate decision. It defaults, quietly, to more depth, because depth is what got rewarded for the first fifteen years. Nobody hands you the second question. You have to notice it yourself, usually because something forces the comparison, the way a survey and a classroom forced it for me, in the same year, without my having planned it that way.
Twenty years of experience is not valuable because it accumulates. It is valuable because of what it becomes once you stop being the only place it lives.
That is the kind of impact I want to spend the next twenty years building.
What have you built that no longer needs you to keep working?
Edwin Martin Salazar Vega
Helping organizations make better decisions through technology, observability, and complex systems thinking.