Becoming a manager is one of the hardest shifts in any individual contributor’s career. As IC, most of the time you write code: functions, classes, APIs that accept a set of inputs and return an output. As a result of the predictability that comes with writing code, you can write test cases with confidence that they will continue to work as planned. But as an engineering manager, you deal more with people topics which are not that predictable. You can’t push a change and instantly go to look at logs to see the impact of the change and revert when necessary. Even worse! Managers of several teams don’t have the luxury of a short feedback loop. Feedback from change may come in days, weeks, or months to managers– long enough to have a consequential impact on the team, delivery, culture, and more. The further you go up from the software team, the more you’re removed from the team’s day-to-day challenges, activities, and flow. But to steer your teams in the right direction, guard culture, and improve team health and engagement, you need visibility (observability). You need to be able to infer the state of your teams from the outside and be able to understand the state of things by looking at data.
The holy grail of leading with visibility is to be able to answer yes to all of the questions below:
1. Can you understand how stuff is being built?
2. Can you understand how stuff gets built on time and within budget?
3. Can you understand if the stuff built will continue to run?
4. Are the people building the stuff engaged and happy to take part in building the stuff being built?
5. Are your users getting value and satisfaction from what is being built?
In this talk, we’ll ground discussion on obtaining and measuring data that matters to give you visibility into your teams whilst drawing on my experience at TIER.