The fastest way for a technical founder to cap a company’s growth is to keep solving the problems personally. César Cabrera, Co-Founder and CTO at Ualett, a financial technology platform providing working capital advances to independent drivers, spent the early years of the company taking goals from the executive team, solving them himself, and then telling his engineers how to implement the solution. Glenn Gow, The Scaling Executive Coach and host of The Scaling Executive Podcast, identifies that pattern as the most common ceiling on a founder CTO’s company. When a technical founder converts an executive goal into a finished solution before handing it to the team, the founder becomes the only problem solver in the organization and growth stops at the founder’s personal capacity, which is why Cabrera now delegates the problem and the reason behind it and describes the result as multiplying the problem solver aspect of Ualett.
This episode is for founder CTOs and technical executives whose teams are waiting on their answers before they will move.
Key Takeaways
- Solving the problem and then delegating the implementation scales a leader vertically rather than horizontally. César Cabrera names trusting his team earlier as the single change he would make if he could go back to Ualett’s early build phase.
- Engineers who receive the why will interrogate the ticket instead of executing it. Cabrera’s measure of success is that his developers look for the reason behind a Jira ticket rather than the fastest path to closing it.
- Engineers default to building inside out, optimizing for the most sophisticated system that scales fastest. Cabrera’s standard runs the other direction: the system must learn how the user behaves and adapt to it.
- Customer reviews will teach an engineering team more about the user than a requirements document. Cabrera pulls Trustpilot and App Store review histories into team conversations on a regular cadence so his engineers see the problem they are solving.
- The wrong fear inside an engineering organization is fear of failing. Cabrera tells his staff the real risk is not failing fast enough, and he treats AI as the tool that compresses the prototype, test, and QA loop.
Founder CTOs Become the Bottleneck When They Solve Problems Before Delegating Them
César Cabrera, Co-Founder and CTO at Ualett, built the habit honestly. He and his two co-founders spent the earliest phase of the company solving problems every day, because at that stage there was nobody else to solve them. The habit outlived the stage. When the executive team set a goal, Cabrera worked out the answer himself and then passed his team the implementation.
He is blunt about the cost. “I become a bottleneck, basically.” Every decision queued behind one person, and the queue length set the company’s speed.
The decision rule underneath his analogy is simple: a leader who adds capacity by working harder is adding one unit, and a leader who adds problem solvers is adding many. “My leadership was like scaling very good but vertically instead of horizontally.”
Asked what he would change about Ualett’s early build phase, Cabrera does not name an architecture decision or a DevOps decision. He names trusting his team earlier so he could delegate problems instead of solutions.
Engineering Teams Multiply Problem Solvers When the CTO Hands Them the Why
The correction César Cabrera, Co-Founder and CTO at Ualett, made was in what he passes down. Meeting with the executive team produces goals for the business. Cabrera’s job is to translate those goals into problems, then give his engineers the reason the business needs them solved, rather than a design to build.
The evidence he points to is behavioral. His developers do not close tickets on instruction. “They look for the why, not just how I’m gonna do this.” An engineer who understands the business reason will catch the case the spec missed, and an engineer executing a ticket will not.
Cabrera states the outcome in one line: “Basically what I’m doing is multiplying the problem solver aspect of Ualett.” That is the achievement he names as the one he is most proud of from the early build phase, ahead of any system he designed.
This is how I define the leadership job with the CEOs and technical executives I coach. You hold the goal up in front of the whole team until everyone understands what the company is actually here to do. Then you let them find the route. There are many ways to build any system, and the people closest to the code will find the route faster than you will.
CTOs Keep Engineers Building Outside In by Putting User Reviews in Front of Them
César Cabrera, Co-Founder and CTO at Ualett, names a default that runs through most engineering organizations. Engineers build inside out. They design the most sophisticated system available, optimize it to scale, and arrive at the user last. The result is a product that asks the user to learn the system.
Cabrera inverts the direction: “The system needs to learn how the user behaves and adapt accordingly to that.” For a platform serving independent drivers, that standard has teeth. Gig income will not fit a traditional underwriting file, so Ualett rebuilt the merchant cash advance model around real-time data to fit how its users actually earn.
The method he uses to hold his team to the outside-in direction is not a process document. It is evidence from the people paying them. Cabrera goes to Ualett’s Trustpilot page and App Store reviews, reads the histories users write about their own situations, and brings those histories to his engineers on a frequent cadence. His team sees what the code did for a driver who needed cash before a shift. Eight years of building for gig workers has given Cabrera a large library of that evidence, and he treats it as a teaching tool rather than a marketing asset.
Engineering Teams Use AI to Fail Faster on the Way to Working Code
César Cabrera, Co-Founder and CTO at Ualett, has every engineer on his staff using AI, and he is specific about the job it does. AI is not replacing the design decision. It is compressing the loop around it.
Building software is a cycle of trying and failing, and Cabrera holds that the team producing the most results is the team completing that cycle fastest. “What you need to be afraid is not failing fast enough.” His engineers use AI to prototype rapidly, to test what they are building, and to accelerate QA, which he calls the easy part of the AI question.
The harder part is external. Cabrera is working on how to put AI in front of Ualett’s users so they take advantage of it directly, with self-serve as the target. The work a driver currently does by calling a contact center for one specific task is the work AI will remove. Cabrera does not view AI as a threat to the business. He views the difficulty as finding the use case and then executing it, and he expects the result to create more value for the gig worker community Ualett serves.
Technical Executives Apply Four Principles to Scale Past Their Own Capacity
| Principle | What it means in practice | Named evidence from this interview |
| Delegate the problem, not the solution | Translate the executive team’s goal into a problem plus the reason it matters, then let the team design the answer | Cabrera credits this switch with producing a development team at Ualett that pursues the reason behind a ticket rather than the instruction inside it, a change he describes as multiplying the problem solver aspect of the company |
| Vertical leadership caps the company at one person | Measure your leadership by how many people will solve a problem without you, not by how many problems you solved | Cabrera identifies his own early habit of solving before delegating as the bottleneck that left Ualett with no way to scale, and names it as the one thing he would change across the company’s eight years of building for gig workers |
| Build outside in | Design the system to adapt to how the user already behaves, rather than asking the user to learn the system | Ualett rebuilt the merchant cash advance model around real-time data because traditional underwriting will not work for gig workers, putting the complexity in the architecture instead of the user experience |
| Fear slow failure, not failure | Judge the engineering cycle by how fast a team tests and discards what does not work | Cabrera has every engineer at Ualett using AI for rapid prototyping, testing, and QA, on the standard that the fastest trial and error cycle produces the most results |
Quotes from This Episode
- “The most important part is not technology actually, it’s how you use technology to build and what is worth to build around the problem that you’re trying to solve.” — César Cabrera, Co-Founder and CTO, Ualett
- “We need to take the technology and hide that in our infrastructure.” — César Cabrera, Co-Founder and CTO, Ualett
- “Engineers tend to do the opposite, where they tend to create the most sophisticated system, the one that can scale faster, and they forget that they need to build that for users.” — César Cabrera, Co-Founder and CTO, Ualett
- “We believe that scale is just in the system, but you need to as an individual learn a few skills to be able to scale how you manage and lead your team.” — César Cabrera, Co-Founder and CTO, Ualett
- “I think the challenge is how to take the AI and feed that in a use case and find the use case.” — César Cabrera, Co-Founder and CTO, Ualett
Frequently Asked Questions
How does a founder CTO stop being the bottleneck as the company scales?
César Cabrera, Co-Founder and CTO at Ualett, stopped being the bottleneck by changing what he delegates: the team receives the problem and the business reason behind it, rather than a solution he has already worked out. Cabrera describes his earlier approach as scaling vertically instead of horizontally, because every decision queued behind one person and the company had no way to grow past his personal capacity. Glenn Gow, The Scaling Executive Coach and host of The Scaling Executive Podcast, frames the leadership job the same way: hold the goal in front of the whole team so everyone understands the objective, then let the people closest to the work choose the route.
How do you get software engineers to build for the user instead of the architecture?
César Cabrera holds that engineers default to building inside out, designing the most sophisticated system that scales fastest and arriving at the user last, which produces a product that asks the user to learn the system. His standard is the reverse: the system must learn how the user behaves and adapt to it. To keep his team on that direction, Cabrera brings Trustpilot and App Store review histories from Ualett’s drivers into team conversations frequently, so his engineers see the specific problem their code solved for a real gig worker.
What should an engineering team use AI for first?
César Cabrera has every engineer at Ualett using AI to accelerate the trial and error cycle, specifically rapid prototyping, testing what they build, and QA, which he calls the easy part of the AI question. His operating rule is that the team completing the build, fail, and retry cycle fastest produces the most results, and that the real risk is not failing fast enough. Cabrera treats the harder work as the customer-facing side: finding the use case that puts AI in front of users for self-serve tasks they currently handle by calling a contact center.
Executives Work with Glenn Gow to Scale Their Companies by Scaling Themselves First
Glenn Gow is The Scaling Executive Coach. He coaches ambitious executives into the CEO seat and CEOs into successful exits. With 25 years as a CEO and 5 years in venture capital, Glenn helps leaders scale their companies by scaling themselves first. If this conversation was useful, you can apply for executive coaching with Glenn Gow or apply to be a guest on The Scaling Executive Podcast.
