Artwork

Contenuto fornito da Jamison Dance and Dave Smith, Jamison Dance, and Dave Smith. Tutti i contenuti dei podcast, inclusi episodi, grafica e descrizioni dei podcast, vengono caricati e forniti direttamente da Jamison Dance and Dave Smith, Jamison Dance, and Dave Smith o dal partner della piattaforma podcast. Se ritieni che qualcuno stia utilizzando la tua opera protetta da copyright senza la tua autorizzazione, puoi seguire la procedura descritta qui https://it.player.fm/legal.
Player FM - App Podcast
Vai offline con l'app Player FM !

Episode 436: Paralyzed by checkboxes and I'm on a "must keep happy" list

33:34
 
Condividi
 

Manage episode 451879864 series 1314025
Contenuto fornito da Jamison Dance and Dave Smith, Jamison Dance, and Dave Smith. Tutti i contenuti dei podcast, inclusi episodi, grafica e descrizioni dei podcast, vengono caricati e forniti direttamente da Jamison Dance and Dave Smith, Jamison Dance, and Dave Smith o dal partner della piattaforma podcast. Se ritieni che qualcuno stia utilizzando la tua opera protetta da copyright senza la tua autorizzazione, puoi seguire la procedura descritta qui https://it.player.fm/legal.

In this episode, Dave and Jamison answer these questions:

  1. Marcus Zackerberg asks,

    I work at a megacorp whose recent focus has been on reliability. The company already has mature SLO coverage outage response standards, but my org has taken it to the extreme this year. For example…

    There is now a dashboard of “service health” that is reviewed by engineering leadership. In it, services are marked “unhealthy” permanently upon a failing check (think HTTP /health). To return to a “healthy” state, one must manually explain the failure with an entry in a spreadsheet, which must be reviewed and signed off.

    Increasingly I feel this has the opposite effect, discouraging nuanced work to improve reliability and instead becoming “checkbox driven development”, as well as impacting our ability to ship on our existing roadmap items. Additionally, our tech lead is fairly junior and frequently fails to communicate the org’s expectations to the team, leading to us being under the gun of the reliability dashboard often.

    Any advice on how to make the best of this situation?

  2. Hi Guys! I’m a senior engineer at a mid sized software company. The company has had a couple of high level departures recently, and during that process I’ve come into the knowledge that my name is one of a handful on a list of “engineers to keep happy”. I feel like this information should be of use to me, but I’m unsure on how I should leverage it.

    On one hand it’s nice to know I’m valued, but I think I’d rather be explicitly told that or better yet, receive dollars in lieu of praise. I’m also at the point in my career where I’m looking for staff roles, and the topic of promotion has come up several times with my manager. He supports me (and I believe him), but we agree that it would be difficult to make the case to the business.

    What do I do with this new knowledge, and is there a way to benefit from it without accidentally triggering a preemptive search for my own replacement?

  continue reading

443 episodi

Artwork
iconCondividi
 
Manage episode 451879864 series 1314025
Contenuto fornito da Jamison Dance and Dave Smith, Jamison Dance, and Dave Smith. Tutti i contenuti dei podcast, inclusi episodi, grafica e descrizioni dei podcast, vengono caricati e forniti direttamente da Jamison Dance and Dave Smith, Jamison Dance, and Dave Smith o dal partner della piattaforma podcast. Se ritieni che qualcuno stia utilizzando la tua opera protetta da copyright senza la tua autorizzazione, puoi seguire la procedura descritta qui https://it.player.fm/legal.

In this episode, Dave and Jamison answer these questions:

  1. Marcus Zackerberg asks,

    I work at a megacorp whose recent focus has been on reliability. The company already has mature SLO coverage outage response standards, but my org has taken it to the extreme this year. For example…

    There is now a dashboard of “service health” that is reviewed by engineering leadership. In it, services are marked “unhealthy” permanently upon a failing check (think HTTP /health). To return to a “healthy” state, one must manually explain the failure with an entry in a spreadsheet, which must be reviewed and signed off.

    Increasingly I feel this has the opposite effect, discouraging nuanced work to improve reliability and instead becoming “checkbox driven development”, as well as impacting our ability to ship on our existing roadmap items. Additionally, our tech lead is fairly junior and frequently fails to communicate the org’s expectations to the team, leading to us being under the gun of the reliability dashboard often.

    Any advice on how to make the best of this situation?

  2. Hi Guys! I’m a senior engineer at a mid sized software company. The company has had a couple of high level departures recently, and during that process I’ve come into the knowledge that my name is one of a handful on a list of “engineers to keep happy”. I feel like this information should be of use to me, but I’m unsure on how I should leverage it.

    On one hand it’s nice to know I’m valued, but I think I’d rather be explicitly told that or better yet, receive dollars in lieu of praise. I’m also at the point in my career where I’m looking for staff roles, and the topic of promotion has come up several times with my manager. He supports me (and I believe him), but we agree that it would be difficult to make the case to the business.

    What do I do with this new knowledge, and is there a way to benefit from it without accidentally triggering a preemptive search for my own replacement?

  continue reading

443 episodi

Όλα τα επεισόδια

×
 
Loading …

Benvenuto su Player FM!

Player FM ricerca sul web podcast di alta qualità che tu possa goderti adesso. È la migliore app di podcast e funziona su Android, iPhone e web. Registrati per sincronizzare le iscrizioni su tutti i tuoi dispositivi.

 

Guida rapida

Ascolta questo spettacolo mentre esplori
Riproduci