Newsletters

Latest news in your inbox

Webinars

See all our upcoming events

Videos

From our archives

Reports

Unique engineering research

For you

Find content specific to your role

Berlin

November 4 & 5, 2024

New York

September 4 & 5, 2024

London

June 16 & 17, 2025

Meetups

Leading software teams with context (visibility)

In this talk, James will ground discussion on obtaining and measuring data that matters to give you visibility into your teams.

By James Samuel

James Samuel Berlin 2022
November 21, 2022

Measure data that matters, drawing on experience at TIER.

View speaker slides

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?

 

About the author