Yeah. This gets to a weakness of engineering leveling systems. We rightly encourage high level engineers to seek out work that is a challenge at their level...

But there isn't always enough of that highly difficult or tech lead work to go around.
When level-appropriate work comprises a lot of your performance review, you get something very dangerous: roving bands of skilled, restless engineers competing for vanity projects and systems that should never, ever have been built, but which you now have to maintain. 😬
One way to prevent this is to *not* over hire, especially very senior engineers. Hire juniors and mid-levels with room to grow.

Most engineering work is not rocket science, and mid levels in particular are often the most prolific and productive engineers you have.
Be mindful of your ratio. You will grow more and more top heavy over time as engineers progress, unless you feed the funnel.

A team with 20% distinguished engineers, 50% staff engineers, 30% senior engineers and 20% mid-level or junior engineers...
...is a restless team where (assuming you haven't inflated their levels) most of your team isn't getting enough lead work or technical work that challenges them enough to continue growing.

And I'm dead serious about over hiring. Everywhere I look I see inflated orgs.
People think if they have too many engineers it will manifest as light workloads.

Bzzzzt! It manifests as everyone being busy, busy busy solving internal problems they brought upon themselves years before they should have had to.
Overhiring manifests as, if you really look closely, only maybe 30% of your engineers are actually spending most of their time solving problems that move your strategic business priorities forward.
Overhiring can manifest as too many people acting in their own best interest and playing politics or empire building.

I'm not sure why. Maybe bc it's easier to put ego+cynicism aside when you know your work matters, and you see very little make work or self imposed problems?
Anyhow...we were talking about how to avoid the roaming hordes. 🙃

The second way is, simply, not to punish them for doing the right thing. Make it clear that the priority is doing what's right for the business. Sometimes it won't be "appropriately tough" work. So be it.
Also...I would love to hear the telltale symptoms others look for to spot engineer over-hiring.

I think this is an all but invisible condition which is way, WAY more common than people realize. 🤔

• • •

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

19 Sep
YES. Great section. The edges of tool adoption create silos.

Also: ultra relevant to the thread on software to sabotage your org, and the ~50% of responders who replied, "Jira."
Communication pathways are sooo hard to get right, and inspire such frothing, unreasonable rage when they get it wrong.

The last time I used jira was well over a decade ago, and I thought it was impenetrable spaghetti at the time. I can't imagine it's gotten any simpler...
But it's kind of an impossible problem, of course it's going to turn into feature soup when you've been making bank on enterprise for this long.

Every team starts out trying to replicate and "improve" on how a squintillion people and teams interoperate,
Read 5 tweets
12 Sep
I was just editing the o11y book chapter on build vs buy and ROI, and this sentence jumped out at me:

"High-performing organizations use great tools."
It's true, right? Behold all the FAANG engineers who leave their cushy perches and are shocked by the amount of tooling they had come to take for granted. It's almost like having to learn to engineer all over again

Big companies know how critical good tooling is, and pay for it.
I'm going to say two very contradictory things, both of which are true:

1) Tools are getting better and better, and you should try to keep up

2) Switching tooling is hard, and you should only do it when the gain is ~an order of magnitude better than what you've got.
Read 15 tweets
10 Sep
Another great point that many of us struggle with.

First of all, sure, there *should* be no bad jobs, but that injustice is likely to exceed your personal capacity to resolve. 🙃
You don't owe it to your employer to fix all the ways they are fucked up. Before going to battle, ask yourself:

* how much power do I have here?
* is the problem within my domain of responsibility or influence?
* who are my allies?
* do I have a reasonable chance of success?
and also: are they worth it? Is your employer fundamentally worth you staying and fighting? Is their product a net good for the world? Are your leaders decent, ethical people who care a lot?

If so, sure, pick some battles. See what happens. ☺️
Read 7 tweets
7 Sep
Ah! This is a very good point. Good recruiters are outnumbered by bad ones, which are indistinguishable from spam. And yes, the more you put out the more you'll get.

Here's how to tell who is worth speaking to:
1) is the person reaching out to you the hiring manager or some other non-recruiting leadership role? Always talk to them. These are golden and rare.

Even if you don't take a job there, it will be an interesting conversation and perhaps a valuable new connection.
2) has the recruiter read your fucking profile? Shout out to the recruiter who just emailed me about a hot new entry level javascript role. 🙋‍♀️

3) did the recruiter just send you a list of companies and jobs? 🚫
Read 8 tweets
7 Sep
Here we are, now going on the fourth straight month of headlines all about how a record number of people are quitting their jobs.

There's a lot of pain behind that statistic, but also a strident, activated edge to labor that feels unlike anything seen in my lifetime.
I am *all for* more people quitting their jobs. I am *all for* employers needing to compete for employees by treating them better, increasing their wages, and offering more flexibility and support.

Most people in our industry stay at jobs they don't love, far too long.
So here's a piece of advice that I find myself giving over and over again, to senior folks who are daunted by the prospect of having to go out and search for the right role, the right team, the right company ... it's like looking for a needle in a haystack, right? 😰
Read 10 tweets
6 Sep
This is 100% true. What always jumps out at me is that there's always "the tracing expert(s)" that everybody goes to for help on the rare occasions when they need a trace. Fluency rarely transcends the few to reach the many.

I have a different diagnosis, tho.
I don't think it's this so much as it is that ... tracing is *inherently* a niche use case. A tracing-first approach to observability turns the world on its head for no good reason.

What most people want is the ability to slice and dice their requests,

and occasionally trace one.

A lot of the munging engineers get so good at doing with logs is to make up for the fact that they didn't capture them as events in the first place.

The fact that they inevitably end up implementing some form of rudimentary

Read 15 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

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

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(