and part of that means consistently giving them feedback, constructive as well as praise.
*ask* how they prefer to receive feedback. give it gently, give it timely, give with a true spirit of "trying to help each other become better". don't let things snowball into badness...
and *solicit* their feedback for you with equal vigor. solicit often, receive it gracefully, show that you heard it and are making changes.
trust is built in part by being willing to say awkward things, by showing up to discuss the hard things with care and sensitivity.
if somebody only ever hears you say good stuff to them, they're going to be very wary of you. it's a relief to know you can count on your manager to show up for you and have your back when things are tougher, including always giving you the feedback you need to improve.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
First: if it's sapping your essence over an extended period of time, just leave. You're no good to us dead.
It's worth persevering through some difficult times when you:
* believe in the mission, that the world is a better place if it succeeds
* have real power to effect change, formally or informally
* can see green shoots, or the wheels beginning to turn, however slowly
if you are working at a place where you are being actively mistreated, i actually think you have a moral responsibility to leave (if you can do so).
caveats abound, of course.. it is not YOUR job to fix shitty companies, many are not fortunate enough for this to be an option, &c
but companies are out there feeling complacent about their employees and blind to their pain. i guarantee you nearly every leadership team is like "this is a great place to work" *pats self on back*
by staying, you vote with your feet and your labor for shitty companies to win.
when people start leaving and being straight up with their leadership teams about why they're leaving, it's one of the only things that can shock a company into changing course or trying to do better.
when someone turns in their notice, you should not respond with:
🍄 silence
🍄 stony stares
🍄 retaliation
🍄 pressure
🍄 guilt tripping
🍄 ignoring them
🍄 failing to meet their eyes
🍄 saying "we're better off without them anyway" TO ANYONE
-- my subtweet of the day
if you really are better off without them, that's a problem with *your* managers, not their fault. saying so is sour grapes, and making it about them inappropriately.
if you loved working with them, by all means tell them how much you will miss them, and you hope to work with them again someday! this is a small industry, and you very likely will.
don't leave them with a lingering sour taste about you.
Once someone has experienced how much easier it is writing code with real observability, you cannot pull it out of their cold dead hands. It's like getting glasses for the first time, and realizing you could barely see the world around you.
This is partly a generational thing. Those of us who grew up writing software with metrics and logs have a lot of unlearning to do, a lot of trauma and frustration to unwind.
Engineers who never learned to navigate monitoring tools actually have it much easier picking up o11y.
I would actually argue that, with the right tooling, production is *exactly* the most effective place to take chances, make mistakes, and get messy. 🙃 Otherwise you're like this guy.
Here are the slides for a talk of Liz's that I modified slightly and delivered on Wednesday for the O'Reilly InfraOps superstream. speakerdeck.com/charity/observ…
We walk you through the honeycomb backend, some of the ways we perform chaos engineering, and some infamous outages,
to show just how swiftly, accurately, and powerfully you can manipulate systems with modern tooling (feature flags, fast delivery, superb observability) and do whatever the fuck you want in prod without hurting your users.
LARGE SYSTEMS USUALLY OPERATE IN FAILURE MODE, via @dangolant
Or like I used to say, your distributed system exists in a continuous state of partial degradation. There are bugs and flakes and failures all the way down, and hardly any of them ever matter. Until they do.
This is why observability matters. SLOs make large multitenant systems tractable from the top down, but observability makes them comprehensible from the bottom up.
Maybe only .001% of all software system behaviors and bugs ever need to be closely inspected and understood, but that tiny percentage defines the success of your business and the happiness of your users.
And you CANNOT predict what will matter in advance.