Two floors, one portal: reading the culture at a merged IT function
Two teams deliver the same customer portal. The 11-person development team and the 7-person infrastructure team sit on different floors and communicate almost entirely through tickets; average handoff time between them is 3 days. At the last two post-incident reviews, discussion turned into identifying 'who pushed the bad change', and the infrastructure manager has since asked for pre-approval on all development changes. Three of the seven infrastructure engineers have resigned in the past year. The newly appointed CIO suggests a monthly all-staff town hall to 'fix the culture'.
1. Classify the culture using Westrum's typology, cite the evidence, and say what would have to change to move it.
Read the worked answer
This is a pathological culture with bureaucratic features - the evidence is specific:
| Westrum signal | What is happening here |
|---|---|
| Information is withheld / used politically | Handoffs via tickets instead of conversation; 3-day latency creates deniability |
| New ideas and failure are punished | Post-incident reviews turn into attribution of blame |
| People suppressed, responsibilities shirked | Pre-approval demanded on another team's changes; 3 resignations in a year |
| Low cooperation | Two teams, two floors, one product, no shared goal |
What has to change - in this order:
- Make failure safe to disclose. Convert post-incident reviews to blameless reviews with a fixed format: what happened, what conditions allowed it, what will change. Ban the phrase 'who'. Publish the outputs internally.
- Remove the structural cause of blame. Blame flourishes where teams own outcomes they do not control. If dev can deploy without infra's involvement, they own the outcome; if infra is on call for dev's changes, the pre-approval demand is rational, not toxic.
- Create a shared goal with a shared number. One portal, one lead time, one change failure rate - owned jointly, reviewed together weekly.
- Give people an outlet for agency. Blameless reviews only build trust if the recommendations are visibly acted on.
Order matters: changing the review format before changing accountability will look like an invitation to take risks, and will fail.
2. Assess the CIO's town hall proposal.
Read the worked answer
It will not work as intended, and may make things worse by signalling that culture is a communications problem.
Why:
- It targets the wrong layer. Culture is a product of what is rewarded, what is measured, and what is safe. A monthly all-hands does not change any of those. The infrastructure manager's pre-approval demand and the 3-day ticket latency are structural facts that will persist through any number of town halls.
- It risks performance theatre. In a blame-oriented culture, a town hall is a stage on which people say the safe thing. Low attendance or polite silence will be read as 'the culture is fine now'.
- The timing is bad. With three resignations in a year, staff will read a new town hall as a retention gesture rather than a change of operating model.
What I would say to the CIO: keep the town hall if you want a channel, but do not call it the culture programme. Culture is fixed by the first three blameless reviews and the first weekly joint flow review, not by the cadence of all-hands meetings. Judge the culture programme by whether people voluntarily raise problems in the review - not by attendance.
3. Identify the single structural change with the highest leverage, and justify it against two alternatives.
Read the worked answer
Recommendation: form a joint on-call and change-authority arrangement for the portal, where the infrastructure engineers who operate it are embedded in the deployment path and dev engineers take a share of the pager.
Why this and not others:
- It removes the rational basis for pre-approval. The infrastructure manager is demanding pre-approval because dev changes break their on-call week and they bear the consequence. Give them visibility and shared consequence, and the demand loses its purpose - instead of fighting a legitimate concern.
- It kills the 3-day handoff by replacing the ticket boundary with a shared one.
Alternative considered: merging the two teams into one 18-person team. Higher risk - 18 is too large for a single team, it would create internal silos and dilute accountability, and it would take months of HR and reporting-line work before any behaviour changed.
Alternative considered: a shared OKR (e.g. portal change failure rate) without changing on-call. Weaker - shared targets without shared consequences are the pattern that produced the current standoff.
Watch for: the embedded engineers must be given real authority over the deployment pipeline, not a review role; and the pager rotation must be genuinely shared, including unpleasant hours, or this becomes a symbolic gesture that deepens cynicism.