As their organization grew, Thiago Ghisi’s work as director of engineering shifted from being hands-on in emergencies to designing frameworks and delegating decisions. He suggested treating changes as experiments, documenting reorganizations, and using a wave-based communication approach to gather feedback, ensuring people feel heard and invested. This iterative process helps create sustainable growth and fosters buy-in from the team.
Thiago Ghisi presented lessons learned from growing an engineering organization at QCon London.
Ghisi explained how the growth of his organization impacted his work as director of engineering:
When we were around 30 engineers, I could still be in all the crucial standups, help new managers fill gaps, and solve emergencies directly in Slack. But once we passed 50, that just didn’t scale. My role switched from “heroic firefighting” to shaping frameworks and delegating crucial decisions to develop the leadership team.
Ghisi mentioned that he had to stop being the go-to “person” for everything and start being the designer of their broader system, so teams could operate autonomously without waiting for him to approve every move. That shift was challenging but ultimately unlocked more sustainable growth, he added.
Approaching 100 engineers, success is all about designing an environment where others can operate effectively without his constant involvement, Ghisi stated. It is all about building organizational resilience.
Ghisi mentioned that organizations evolve like living organisms. Even if nothing’s “on fire,” a small structural adjustment can be the difference between merely functioning (treading water) and truly flourishing (innovating), he said.
A big part of getting changes to stick is treating them as experiments first in a subtle way, not final mandates, as Ghisi explained:
For instance, I’ll often spin up a “temporary” or “interim” task force before making it official, exactly like when a leader appoints someone as interim manager to see how it goes.
In parallel, once the most senior leaders in our organization agree on a rough plan, we bring in waves of staff engineers and engineering managers to stress-test it, Ghisi said. They surface hidden corner cases or improvements that the core leadership group might have missed, and they get to feel like true co-creators of the new setup rather than mere recipients of a top-down organization chart.
This wave-based approach helps everyone feel heard, which makes them more invested, Ghisi said. He suggested to let people know reorganizations aren’t set in stone:
If something sparks more trouble than it solves, we iterate again. Linking every change back to our short- and long-term priorities helps them see the “why,” not just the “what.”
When leaders demonstrate they’re actively listening and adjusting, people are far more willing to adopt the new structure or process and give feedback, Ghisi concluded.
InfoQ interviewed Thiago Ghisi about what he learned from scaling up.
InfoQ: What is your approach for reorganizing and scaling up?
Thiago Ghisi: I always start with a simple one-pager that spells out motivations and goals: maybe we’re addressing overlapping ownership, or maybe a historically underfunded team is now mission-critical, or maybe staffing a new team for a new scope.
From there, I use an iterative approach:
- Create a Draft (in writing): Outline reasons, high-level roadmap, and potential outcomes.
- Whiteboard new Organization Structure: Share the draft with a small leadership circle (ideally your senior leadership team) for initial feedback.
- People Managers’ Feedback: They’re closest to day-to-day pain points—factor in their corner cases.
- Staff-Plus Review: Let senior ICs stress-test the plan. They’ll spot hidden risks. Iterate and incorporate their suggestions.
- Leadership Sync: Bring senior leadership team + managers + staff engineers together for one final pass, refining and locking the structure.
- Comms Plan: Announce changes in waves—people directly impacted first, next indirectly impacted, then the broader org, finally a town hall for Q&A and reiterate the same message that was shared in writing.
- Roll Out & Monitor: If the new structure truly reduces friction or speeds up a key OKR, we keep it. If issues arise, we iterate fast instead of waiting for a “next-year meltdown.”
By treating reorganizations as iterative design—rather than a once-a-year monolith—we keep them from becoming dreaded events. It’s less “big bang” and more continuous improvement, validated by how smoothly teams deliver or how much friction we eliminate along the way.
InfoQ: What have you learned?
Ghisi: Some of the things that I have learned are:
- Managerial cost is real: You can’t just form a new squad on paper; you need a dedicated manager or lead who can truly own it.
- Structured communication plan: Rolling changes out in at least two or three waves is critical to avoid chaos.
- Your own leadership must evolve: Doing everything yourself at 30 engineers might work, but by 60 or 100, it will collapse. You need to empower a leadership bench, focus on system design, and let go of old “hero” behaviors.
In short, scaling to 100+ has less to do with adding headcount and more to do with systematically building leadership, designing topologies, and iterating on my own role. Every doubling of team size demands a doubling of leadership maturity.
