Teaching Engineers to Think Like Founders

Every year at Harbour.Space University in Barcelona, I stand in front of a room of development and data science students and tell them something they do not want to hear: being a great coder is not enough. Not if you want to build things that matter. Not if you want to lead.

I created the "Developer to CTO" module to bridge the gap between what engineering programs teach and what the industry actually demands. The module runs as a daily intensive. We cover project management, system design, business strategy, and venture building. Students form teams and build real ventures from scratch during the course.

Here is what I have learned from teaching it.

The First Surprise: Nobody Teaches You to Say No

The first exercise I give students is simple. I hand them a product brief with fifteen features and tell them they have the budget to build three. They need to pick which three and explain why.

Almost every team struggles with this. They have spent years in environments where the goal is to solve every problem, pass every test, implement every requirement. The idea of deliberately leaving features on the table feels wrong to them.

But this is the most important skill a technical leader needs. At Cantoo, we reached profitability specifically because we said no to features that did not directly generate revenue. We could have built a beautiful dashboard. We could have added analytics. We could have supported more protocols. Instead, we built a voice routing engine, a billing system, and an API. That was it. And it was enough.

Students are shocked when I tell them that saying no to a good idea is harder and more valuable than saying yes. By the end of the module, they get it.

Business Models Before Code

I start the module with business models, not architecture diagrams. This confuses students initially. They signed up for a technical course. Why are we talking about unit economics?

Because every architecture decision is ultimately a business decision. The choice between a monolith and microservices is not just technical. It determines how fast you can ship, how many engineers you need, and how much your infrastructure costs. If you do not understand the business context, you will optimize for the wrong thing.

I walk them through real examples. At OneRagtime, we built three separate products (Platform, Core, Deepdive) because the VC business had three distinct user groups with different needs and different usage patterns. A single monolith would have been simpler to build but impossible to iterate on independently. The architecture followed the business, not the other way around.

At Cantoo, we chose a monolithic approach initially because we were two people and needed to ship fast. The business context demanded speed over elegance. We refactored later when the business grew.

Students who understand this make better architects. They do not pick technologies because they are interesting. They pick technologies because they serve the business.

The Team Simulation

The most transformative part of the module is the venture project. Students form teams of four or five and have to build something real. Not a prototype. Not a mockup. A working product with a business model, a target market, and a plan for sustainability.

I have watched brilliant individual coders completely fall apart in this exercise. They want to write all the code themselves. They resist delegating. They spend three days perfecting a feature that nobody asked for while the core product remains unfinished.

This is exactly what happens to first-time engineering managers in the real world. The transition from individual contributor to leader is painful because it requires letting go of what made you successful in the first place.

I tell my students: your job is not to write the best code anymore. Your job is to make sure the best code gets written. That is a fundamentally different skill.

What Surprises Students Most

Three things consistently catch students off guard.

Cost awareness. Most students have never thought about how much their technical decisions cost. When I show them the AWS bill for a real startup and explain how architectural choices directly impact burn rate, something clicks. Suddenly, that extra microservice or that real-time feature is not just a technical decision. It is a financial one.

The communication gap. Students discover that explaining a technical decision to a non-technical stakeholder is genuinely difficult. I make them present their architecture choices to me as if I were an investor. No jargon allowed. If you cannot explain why you chose PostgreSQL over MongoDB in terms a business person understands, you probably have not thought it through clearly enough.

Shipping beats perfection. I give tight deadlines deliberately. Teams that spend too long on architecture never finish. Teams that ship something imperfect and iterate always produce better outcomes. This mirrors what I have seen in every startup I have built or advised. The teams that win are the ones that get something into users' hands fastest, then improve it based on real feedback.

The Founder Mindset

The module is called "Developer to CTO," but what I am really teaching is the founder mindset. Not everyone will start a company. But everyone benefits from thinking like someone who has to ship a product, serve customers, manage costs, and grow a team.

At Kamina.io, my consulting studio, I work with 40+ teams across Europe. The engineers who stand out are never the ones with the deepest technical knowledge. They are the ones who understand why they are building what they are building. They ask questions about the user. They push back on requirements that do not make sense. They think about maintainability because they know someone, maybe them, will have to live with this code for years.

This is what I try to instill in my students. Technical skill is the baseline. It is what gets you in the room. What determines your trajectory after that is your ability to think beyond the code.

The Hardest Lesson

The hardest lesson I teach is about trade-offs. Not technical trade-offs, those are relatively straightforward, but the human ones.

As a CTO, you will make decisions that frustrate your team. You will choose the boring, reliable solution over the exciting new one. You will prioritize paying down technical debt over building the feature your best engineer is passionate about. You will say no to someone you respect because the business needs something else right now.

I was the CTO at OneRagtime, managing a team in Barcelona while the business operated across Europe. I had to make calls about what we built, what we delayed, and what we killed entirely. Those decisions were never purely technical. They involved people, expectations, and relationships.

Students expect the CTO role to be about making the big technical calls. It is, partly. But it is mostly about making the calls nobody else wants to make, and doing it in a way that keeps the team motivated and aligned.

Why I Keep Teaching

I keep teaching because it makes me better at my day job. Every cohort of students forces me to re-examine my assumptions. They ask questions I have not considered. They challenge patterns I have taken for granted.

At Consentio, I lead a team of ten engineers. The frameworks I use to explain concepts to students are the same ones I use to align my team on technical direction. If I can make a 22-year-old student in Barcelona understand why we architect systems a certain way, I can make anyone understand it.

Teaching is the best feedback loop I have found. It forces clarity. And clarity is the single most underrated skill in engineering leadership.