Thiago Ghisi explained how he guided managers and senior ICs to build a resilient leadership group beneath him in his talk Lessons from Growing Engineering Organizations at QCon London. Regular syncs, expectation calibration, and alignment on broader goals made leaders multipliers of culture and performance. Culture is what you do, not what you say, he argued.
A major epiphany was realizing that his role wasn’t just about being part of the boss’s leadership group and rituals, but also about intentionally building a leadership group beneath him, Ghisi said. They started with an off-site where managers and senior ICs shared personal struggles, like repeated incidents or scope confusion, and also aligned on priorities and goals for the next cycle as a team in a format similar to a Lean Inception. That built empathy and trust, he mentioned.
To build a resilient leadership team, they aligned on broader organizational goals, Ghisi explained:
We set up consistent weekly or biweekly syncs where they’d hold each other accountable, reminding each other of the most important things and reallocate ICs to help on the most critical projects for the organization, even when that was not necessarily the best thing for their direct squad.
Ghisi mentioned that they do expectation calibrations. At the start of the cycle, each manager drafts expectations for their direct reports and gets peer feedback, ensuring they all agree on what "good" looks like at each level and if what they are focused on achieving is aligned with the broader organizational and company priorities.
By investing in that leadership team’s coherence with clear scopes and a sense of making their peers their first team, they became multipliers of culture and performance, Ghisi said:
Rather than me being the bottleneck, they are helping each other, giving each other feedback, deciding what to promote and what to push back, and discussing and iterating on visions & strategies for the future.
Culture is less what you say or what rituals you have and more what you do and how you react during changes or crises, what values you show, what behaviors you promote, what behaviors you push back. It’s walk the walk, not talk the talk, Ghisi argued:
Are you someone who is constantly trying to improve yourself? Are you really listening and incorporating suggestions when they make sense? Are you afraid to look bad in front of your leadership team and avoid conflicts or difficult conversations and decisions with your direct reports or with your peers?
Ghisi suggested that you shouldn’t try to reorganize without documenting it in writing and describing the "Why" first. It could be a very simple and short one-pager describing the big reasons/motivations/goals for the reorganization, before starting the brainstorming on potential topologies/organizational/structural changes:
Every time I tried to speed things up or just to tell "the vision" at a high level in repeated meetings and hope that vision would carry over into discussions, I was reminded and surprised by the telephone game with discussions going completely sideways.
Ghisi mentioned that they learned to fix people’s issues before pushing delivery. If you have a low-performing squad, address the interpersonal or skill gaps first, he said. A stressed, unsafe team can’t deliver at scale.
Not everything needs consensus, and that is a good thing, Ghisi said. Establish who the tie-breaker is if the leadership group is split, otherwise you get gridlock, he argued. The RACI matrix can help a lot here.
InfoQ interviewed Thiago Ghisi about continuous improvement and experimentation.
InfoQ: How did you establish a culture of continuous improvement?
Thiago Ghisi: We baked "lessons learned" into everything we do, in every document we write, every big reorganization, every major incident postmortem, and every leadership off-site. For instance, if we discovered that merging two squads actually caused more on-call load than expected, we’d fix it quickly. That transparency in writing showed we weren’t wedded to top-down directives if they weren’t working.
People learned that "trying something new" doesn’t mean "stuck with it forever." So it’s a mix: we have formal rituals (like retros, tech talks, skip-level feedback, monthly deep dive with each team) but also consistent follow-through in how we respond to problems—showing that we value iteration over blame and that we - as the leadership team - are always listening and always there to help.
InfoQ: How did you experiment to find the right team topologies?
Ghisi: That was a mix of my own and my direct team experience, with seeing what patterns, topologies, incentives, and processes were usually working inside the company in other groups. That usually works a lot better than trying to borrow ideas from other companies or past experiences.
At a high level, we are constantly looking for friction signals—like unresolved dependencies or managers overwhelmed by an overly broad scope—and making small, testable changes. For instance, if one domain was constantly blocking another, we’d place a staff engineer who had deep context in that domain onto the dependent team. Or if we saw two squads with a lot of overlapping roadmaps, we’d merge them for a quarter as a "task force." We’d label it an experiment from day one: if it solved the bottleneck, awesome; if it caused more chaos, we’d revert. This gave teams psychological safety to try new configurations (like unified on-call rotations across multiple squads), knowing we’d pivot if the data said it wasn’t helping.