Three Strategies to Enable Your Team and Scale Effectively

How to delegate, encourage ownership and accountability while keeping your technical edge

👋🏻 Welcome to Lead and Scale, the newsletters for all the leaders navigating the complexity of scale-ups. Today, we’re going to address a common issue with hands-on CTOs: being your company’s bottleneck.

There has been a heated debate around Paul Graham's Founder Mode, and whether it is beneficial on the long run, or ends creating a critical bottleneck that slows down the whole company.

Founder mode is a leadership approach that emphasizes a hands on, direct management style for startup founders. Unlike traditional "manager mode", founder mode encourages executives to remain involved in the company's operations.

After inventing the personal computer, Steve Wozniak decided to structure Apple R&D around a team of engineers, allowing the company to scale. If *iWoz* had decided to remain the only one at the head of Apple R&D, the company would certainly have taken a different turn.

As a hands on CTO, I'm tempted to stay involved in the company's day to day operations. Deploying technical solutions, from choosing the technology, to pushing it to production is still a pleasure, and helps me keep my feet on the ground. As valuable my experience is, I ultimately became the bottleneck for the entire engineering team.

Creating a bottleneck in your engineering has serious consequences: it slows down progress, impedes autonomy, and frustrates people.

This is what Lead & Scale issue #2 is about: striking the right balance between executive stance and micromanagement.

Delegate to Encourage Ownership

As a CTO, it's easy to feel you're the most qualified to solve complex technical problems. Your experience allows you to take shortcuts and discard wrong solutions. Your over-involvement limits growth opportunities, and your days are only 24 hours long.

Empower leads: set clear boundaries on decision-making authority for engineering leads. I'm still designing and deploying complex infrastructures, but my head of infrastructure keeps the final word.

Use the RACI model: it's not about yet another project management methodology, but A way to structure and information. RACI stands for responsible / accountable / consulted and informed, using a responsibility assignment matrix allows everybody to be aware of who's in charge.

Having a responsibility assignment matrix helps inside and outside your engineering team. Inside your team, people own their topics and get accountable for them. Without clear responsibility assignment, everybody's responsible, which means no one is. It's also helpful outside of your team: when someone from another team need guidance or a decision to be taken on a topic, they know who to call. And it's not the CTO.

Don't be a super hero: it's tempting to bypass the team assigned to a bug or an incident to solve it yourself. Jumping in to save the day will only create frustration and a feeling of distrust.

I used to have the super hero syndrome, and it almost killed me (like in "ending at the hospital from exhaustion"). I spent years working 24/7, jumping on every topic and every incident, exhausting myself, making mistakes while frustrating my team.

Optimize Communication and Decision-Making Processes

In Why Your Teams Are Struggling to Deliver (and How to Fix it), Rafa Páez emphasizes how a bad communication structure kills team interactions. When the smallest decision requires your approval, you create useless dependencies and delays.

Be asynchronous: for daily topics and decisions, replace meetings with asynchronous tools. Slack, Jira / Trello / Notion replace 90% of the meetings you'll hold. Too many synchronous lines end in people joining but doing something else instead of actively participating.

To follow up on topics, define a set of KPIs, and have them updated by your engineering leads on a weekly basis. You're in a scale-up, which means you don't manage by the day or the hour anymore. Asking for weekly updates is enough to keep you informed about the day to day delivery while avoiding micromanagement. If a problem arises, you'll see it and will be able to jump into the action.

Document decision criteria: when we need to chose a new technical stack, we define a set of criteria for the decision making process so engineers can make autonomous choices. You can go even further by sharing playbooks for repetitive scenarios, like vendor selection.

Create escalation protocols: establish clear thresholds for when they should loop you in. I've seen several companies where the CTO had to validate every small decisions, from choosing a library to changing the way we did CI/CD. It was both inefficient and frustrating.

Combine Strategic Vision with Technical Awareness

Balancing strategy with operational knowledge ensures you provide vision without micromanaging. Whether or not you consider yourself a hands on CTO, staying aware of the technical landscape is a critical part of the job. It keeps you credible and ahead of the game when you build your strategy.

Dedicate weekly hands-on time: spend one or 2 mornings a week on technical tasks. It can be reviewing code, shadowing engineers on deployment related tasks, or doing pair programming.

Sacralize these hands-on moments. Lock these 2 mornings in your calendar and refuse any meetings during them. They are for you and no one should take them from you.

I enjoy taking over non-blocking topics. Non-blocking topics are high impact parallel tracks that won't block the team's delivery if you need to re prioritize.

To know what I can take over, I ask myself these 2 questions:

• What are my impact and added value if I take over that topic?

• Is this topic important but not urgent (on the Eisenhower matrix?)

It can be migrating a cluster in a new environment, improving automation, or working on performance issues. Whatever the task, a critical part of the job is transmission and documentation.

Join tech design reviews (as an observer): jump into critical technical discussions every now and then, but first, let the engineers drive the meeting while you observe. Engineers must feel confident in owning their topics, or they'll wait for your approval and you'll become that bottleneck you don't want to be.

Invest on ongoing learning: attend conferences (your developers will love tagging along), read and summarize white papers, or take an online course on a trending technology. I've been using LinkedIn Learning a lot for the past 3 years to stay in touch with both data engineering and frontend development. Understanding how React.js works helps a lot to understand our frontend architecture and what's going on during job interviews I attend to.

In the end, not being a bottleneck is just a matter of finding the right balance between hands-on work and leadership. It requires one of the most important skill you need to have as a scale-up CTO: being able to take a step back to adjust your stance while staying connected to the daily life of your team.

It's now your turn to stop being a bottleneck. Pick one thing you want to change in your leadership style, and start implementing it.

Thank you for reading me, and let's meet next Tuesday, 8:00 CEST.