Charity Majors Profile picture
Apr 9 12 tweets 3 min read
I've been in NYC all week for #LeadDevNewYork #LeadingEngNewYork #StaffPlusNewYork, and it strikes me just how many stories and questions I've been hearing about career pendulum issues. 🤔 Problems with comp, ladders, recruiting, accountants etc.

This is GREAT. This is progress.
When all you hear is happy stories about people swinging back to engineering work after management, you can assume it's a rare and curious event. You're bucking the system, not changing it.

Friction and cranky accountants are a sign the status quo is shifting, tho. 🙃
We talk a lot about how powerful you become as a contributor with both skill sets. We talk less about the detoxifying effect it has on team dynamics, when you drain the authoritarian elements and respect management like any other function.

(do read the whole thread ☺️)
One question that came up twice was that of equal pay for managers and engineers of the same level bracket.

"What do you do when the finance team tells you they've run the numbers and it's harder to hire managers, therefore managers must be paid more than engineers?"
My instinct is to say, pound sand. ☺️ Pay brackets aren't just a matter of supply and demand, they are also a statement of values.

If you say that the IC & manager tracks are of equal value and prestige, if people regularly swing between the two, equal comp seems mandatory.
1) you can't decrease the salary of a manager who goes back to engineering,

2) you don't want people to become managers for comp reasons (and people WILL make these decisions for comp)

3) if you must raise the mgr bands to successfully hire, I get it. Raise the eng bands too.
The "worst" effect this is likely to have is to exhibit some downwards pressure on engineering promotions to staff+.

This is probably a good thing? Most companies promote to staff+ too liberally in my exp.. they promote based on individual "merit" rather than business need.
which feels good, and definitely helps retain individuals, but sets up a load of organizational debt down the line if there isn't enough staff+ level work to go around.

Still, this all works pretty well for senior eng <-> EM roles. What I'm curious about is director+ folks.
What if a director or VP wants to go back to being an IC, after having switched to management from the position of senior engineer?

Level wise, they are supposedly the equivalent of a staff, principal or even distinguished engineer, but they are self-aware enough to know better.
I have only ever seen these treated like one offs, so I'm just curious to hear how others have handled this in any systematic way.
I guess the converse of this is also interesting -- what if a principal or staff level engineer wants to try management, and the parallel tracks mean they would start out as a director or VP? ☺️

Parallel bands are a good idea, but they get real complicated around the 90th %ile.
It feels really objectionably stupid for great people to have to leave companies they love because of org chart inflexibility.

But every exception and one-off creates it's own organizational debt, and often cynicism and equity issues over special treatment.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Charity Majors

Charity Majors Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @mipsytipsy

Mar 28
This might seem like an odd question, but I hear it a lot: "If I'm not running microservices or doing anything extreme, do I still need observability?"

I compare it to the difference between flying with instrument rating (IFR) vs visual rating (VFR). I like this metaphor a lot.
as @mononcqc pointed out.. IFR is more challenging to learn and do up front than VFR. it also requires special telemetry and receivers down near the runway. receivers are highly environment-aware & transmit you lots of env data you wouldn't get by looking out the windows.
So yeah -- a boring app might need less telemetry, if you already have a very accurate model of the environment inside your head.

But if your app starts deviating from the standard, then you'd need that richer context and more information in order to make reliable decisions.
Read 4 tweets
Feb 26
Alright, this is a fun question: given just a few hours to invest before launch, should you invest them into improving apm/tracing with custom spans or composing your own wide structured events?
Like most questions, "it depends". But in general I would say, invest in adding custom spans.

Yes, arbitrarily-wide structured data blobs (bundled up at one per request, per service) are the substrate of observability. But a wide event with span id & trace id is...a custom span.
Don't underestimate the work it would take to roll out high quality bundled wide events. You can't just cough it out manually in a few hours. (No one should do this, anyway, not when starter code exists.)

Good instrumentation evolves over time, accruing wisdom as it goes.
Read 7 tweets
Feb 19
Let's talk about OpenTelemetry, or "OTel", as the kids like to call it.

I remember emitting sooo many frustrated twitter rants back in 2017-2018 about how *behind* we were as an industry when it comes to standards for instrumentation and logging.

Then OTel shows up.
For those of you who have been living under a rock, OTel is an open standard for generating, collecting, and exporting telemetry in a vendor agnostic way.

Before OTel, every vendor had its own libraries, and switching (or trying out) new vendors was a *bitch*.
Yeah, it's a bit more complicated to set up than your standard printf or logging library, but it also adds more discipline and convenience around things like tracing and the sort of arbitrarily-wide structured data blobs (bundled per request, per event) that o11y requires.
Read 15 tweets
Feb 17
I want to give this a slightly longer treatment. ☺️ (Gergely and I *just* talked about it, so it's all rustling around in my head.)

I think it's a ✨great✨ idea for every engineer to spend at least a couple years at both a big company and a startup (series B or earlier).
It's hard to formulate career goals in your first decade or so as an engineer; there is just SO MUCH to learn. Most of us just kinda wing it.

But this is a goal that I think will serve you well: do a tour of duty at a startup and another at a bigco, in your first 10y as an eng.
Besides the obvious benefits of knowing how to operate in two domains, it also prevents you from reaching premature seniority. (charity.wtf/2020/11/01/que…)

The best gift you can give your future self is the habit of regularly returning to the well to learn, feeling like a beginner.
Read 20 tweets
Feb 10
Several people asked this. It's a good question! I will share my thoughts, but I am certainly not religious about this. You should do what works for you and your teams and their workflows. 📈🥂☺️
1) "assuming you have good deduplication"... can a pretty big assumption. You never want to be in a situation where you spend more time tweaking dupe, retry, re-alert thresholds than fixing the problem.
2) having to remember to go futz with a ticket after every little thing feels like a lot of busywork. You've already committed some code, mentioned it in #ops or wherever, and now you have to go paste all that information into a task (or many tasks) too?
Read 12 tweets
Feb 9
a caviar-quality rant on deployment, security, testing ... actually more like five rants stuffed into a single trenchcoat. via @beajammingh

mumble.org.uk/blog/2022/02/0…
@beajammingh the title particularly caught my eye. for the past month or two i've been sitting on a rant about how i no longer associate the term "devops"** with modern problems, but with fighting the last war.

** infinitely malleable as it may be
yes, if you have massive software engineering teams and operations teams and they are all siloed off from each other, then you should be breaking down (i can't even say it, the phrase is so annoying) ... stuff.

but this is a temporary stage, right? a bridge to a better world.
Read 18 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

:(