Thiago Ghisi outlines capability framework

Thiago Ghisi’s April 2, 2023 post lays out a compact framework for assessing engineering-team maturity that shifts attention away from raw output and toward operating behavior. In the thread, Ghisi lists five capabilities he says exceptional product engineering teams repeatedly show: navigating ambiguity, broadcasting state, negotiating dependencies, understanding their levers, and responding to incidents. The post was published on X and includes images designed for use in leadership reviews. The framework matters because it gives managers a vocabulary for discussing how teams work under pressure, not just what they shipped. Ghisi presents the five areas as observable behaviors that can be reviewed, compared over time, and discussed with senior leaders. That makes the post less a motivational note than a template for performance conversations. ### Why does Ghisi start with ambiguity? (x.com) “Navigate ambiguity” sits at the top of Ghisi’s list, and that placement points to a common management problem: many teams perform well only when scope, ownership and sequencing are already clear. In Ghisi’s framing, stronger teams reduce uncertainty themselves. They clarify goals, identify missing information, and move work forward without waiting for every decision to be made for them. (x.com) Thiago Ghisi has described similar themes elsewhere in his public work. In a 2023 Dev Interrupted episode, he said, “A bad decision is better than no decision,” a line that fits the same bias toward action under incomplete information. That does not define the X thread by itself, but it helps explain why ambiguity appears as a core capability rather than a side skill. (x.com) ### What does “broadcast state” mean in practice? “Broadcast state” is Ghisi’s shorthand for making progress, risk and blockers visible before leadership has to ask. In practical terms, that means teams communicate status clearly, surface changes early and avoid forcing managers to reconstruct reality from scattered updates. That behavior is especially useful in leadership reviews because it turns communication into evidence. (linearb.io) A team that consistently shows what changed, what is at risk and what help is needed gives senior leaders something more concrete than velocity charts or anecdotal impressions. Ghisi’s post frames that visibility as a capability in its own right. ### Why are dependencies and levers grouped with incidents? (x.com) “Negotiate dependencies” and “Understand its levers” move the discussion from execution to control. A team that negotiates dependencies well can push work across organizational boundaries, secure decisions from partner teams and avoid being stalled by unclear ownership. A team that understands its levers knows which architecture, process, staffing or product choices most affect outcomes. (x.com) “Respond to incidents” rounds out the list by testing whether those capabilities hold under stress. Incident response exposes communication quality, decision speed, ownership and technical judgment in a way routine delivery often does not. Ghisi’s framework treats that response as a visible measure of maturity, not only an operational necessity. ### How should a manager use this in a review? (x.com) Ghisi’s thread is aimed at managers preparing stronger leadership reviews, and the images in the post suggest a practical use: review teams against the five behaviors, collect examples, and discuss gaps in capability rather than only gaps in output. That approach lets managers show where a team is improving, where it is brittle, and what support it needs next. (x.com) Ghisi’s public profile identifies him as an engineering leader with experience at Nubank, Apple and ThoughtWorks. That background helps explain why the framework reads like an operator’s checklist for scaling teams across product, platform and cross-functional work. The original post, with its images, remains available on X for managers who want to use the framework directly in review preparation. (typefully.com) (x.com)