Engineering Leadership Through Extreme Change

Phase 1: The Transition from Flat to Structured

When I joined Deepnote, the company was undergoing a classic "growing pains" transition: moving from a flat structure to four distinct cross-functional teams. I was brought in to lead the largest Product Team. My mandate was clear: establish delivery predictability and satisfy key stakeholders. However, I didn't start by imposing a rigid Scrum framework.

The Observation Phase: I spent the first few weeks observing the dynamics. In a newly formed team, "process" feels like bureaucracy. My strategy was to identify where friction existed. The Problem: Engineers were burnt out from context switching; stakeholders were frustrated by opaque timelines. The Solution: I introduced rituals not as rules, but as agreements. We set priorities for delivery and defined "velocity" not as a speed metric, but as a consistency metric.

The Cultural Link: By creating a reliable process, I wasn't just organizing tickets; I was building psychological safety. The team learned that if they followed the process, they were protected from chaotic stakeholder intervention.

Phase 2: The Restructure, The Layoffs, and The "Shattered" Culture

Four months in, the ground shifted. Deepnote went through a radical restructuring and a round of layoffs. In a single day, the landscape changed:

The Human Cost: I was informed of the layoffs on the same day they happened. I had to face a team that had just lost colleagues, feeling blindsided and vulnerable.

The Scope Explosion: I was handed a second team—the Platform Team. This was diametrically opposed to my Product team. It was purely technical, infrastructure-heavy, and had no product manager.

The Leadership Anomaly: The original Team Lead of the Platform team stepped down but remained as an Individual Contributor (IC). Simultaneously, the original CTO stepped down to an IC role within that same team. Suddenly, I was managing two teams, managing my previous boss, and trying to salvage a shattered culture.

Rebuilding from the Ashes

Trust in leadership was at an all-time low. This is where the intersection of process and culture became my primary tool for survival.

1. Managing the "Technical Giants": Managing a former CTO and a former Team Lead requires high EQ. You cannot "boss" them. The Approach: I shifted to a servant-leadership model. I didn't dictate technical decisions; I facilitated them. I cleared the path for them to code, removing the management overhead they wanted to escape. The Process: We established technical RFCs (Requests for Change) as a ritual. This allowed the senior engineers to flex their architectural muscles while giving me visibility into the roadmap without micromanaging.

2. Context Switching: Product vs. Platform: You cannot run a Platform team like a Product team. I had to maintain two distinct delivery cultures simultaneously. Product Team: Driven by user stories, design reviews, user interviews, visual demos, and rigorous event tracking. Platform Team: Driven by incident response protocols, SLA definitions, and technical debt pay-down periods. The Lesson: Attempting to unify the process would have killed the culture of the Platform team, who valued autonomy over feature-factory output.

3. The Ritual of Radical Candor: Post-layoffs, the bi-weekly Retrospective became the most important meeting. It wasn't about Linear tickets anymore. It wasn't a "grief circle," but it wasn't business as usual either. The Culture Shift: I established a "No Bullshit" zone. No taboos, no harm, but absolute honesty. We stopped bluffing. We spoke about the grim reality and expressed genuine feelings. By stripping away the corporate veneer and saying things exactly as they were, we paradoxically rebuilt the team's spirit faster than any "morale building" event could have.

Phase 3: The Third Team and Systemizing Leadership

Three months after the restructure, another manager left the company. I was asked to take on a third team. I was now leading three out of the four engineering teams. I had to be very systematic, empathetic, and keep my delivery game strong to keep the board happy. This is where I learned the ultimate lesson of scaling: You cannot rely on your presence; you must rely on your systems.

Delegation is a Process: I couldn't be in every standup. I identified lieutenants in each team and instituted a "Sync of Syncs"—a high-level ritual where we discussed blockers, not status updates.

Radical Transparency: With 75% of the org under my watch, information silos were deadly. I forced a culture of documentation. If a decision wasn't written down, it didn't happen. This wasn't bureaucracy; it was the only way to maintain alignment across a fragmented organization.

Empathy is a deliverable: I realized that keeping the team intact was the deliverable. If I pushed for code while ignoring the burnout, everyone would leave. I defended the teams against unrealistic deadlines, buying them time to stabilize.

Key Takeaways for Leaders

1. Culture and Process are the same thing: Process is simply the codification of your culture. If your culture values autonomy, your process must rely on goals (OKRs), not tasks. If your culture values quality, your process must include rigorous code review, not just fast shipping.

2. Layoffs require "Wartime" Leadership: When trust breaks, you cannot "vision" your way out of it. You must "execute" your way out. You rebuild trust by being the most consistent person in the room. Reliable rituals provide a sense of normalcy in chaos.

3. Manage upwards and downwards: Managing a former CTO requires ego-free leadership. My job wasn't to be the smartest technical mind in the room; it was to unblock the smartest minds so they could deliver value.

4. Adaptability is the only metric that matters: I went from leading one team to leading nearly the entire org in roughly two quarters. The processes that worked in Month 1 were obsolete by Month 5. A great leader doesn't stick to a framework; they edit the framework in real-time to fit the reality on the ground.

Conclusion

At Deepnote, I didn't just build a delivery pipeline; I built a container strong enough to hold a team together when the company shook. Whether acting as a Fractional CTO or an Interim VP of Engineering, my approach remains the same: Observe the human dynamics, build the processes that support them, and drive delivery through clarity, not coercion. Are you navigating a transition, a crisis, or a period of hyper-growth? Let's talk about how to build an engineering culture that scales.