PostHole
Compose
Login
Lessons from Growing a Software Leadership Team
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. By Ben Linders
InfoQ Homepage
News
Lessons from Growing a Software Leadership Team
Culture & Methods
Lessons from Growing a Software Leadership Team
Feb 26, 2026
min read
Ben Linders
Write for InfoQ
Feed your curiosity.
Help 550k+ global
senior developers
each month stay ahead.Get in touch
Listen to this article - 0:00
0:00
0:00
- Reading list
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.
About the Author
****Ben Linders****
Show moreShow less
This content is in the Culture & Methods topic
Related Topics:
Culture & Methods
Coaching and Mentoring
Social Skills
QCon Software Development Conference
QCon London 2025
Leadership
Culture
Collaboration
Related Editorial
Popular across InfoQ
Anthropic Study: AI Coding Assistance Reduces Developer Skill Mastery by 17%
Google Brings its Developer Documentation into the Age of AI Agents
Uforwarder: Uber’s Scalable Kafka Consumer Proxy for Efficient Event-Driven Microservices
Vercel Releases React Best Practices Skill with 40+ Performance Rules for AI Agents
Kubernetes Introduces Node Readiness Controller to Improve Pod Scheduling Reliability
Software Evolution with Microservices and LLMs: A Conversation with Chris Richardson
A round-up of last week’s content on InfoQ sent out every Tuesday. Join a community of over 250,000 senior developers.
We protect your privacy.