Skip to content(if available)orjump to list(if available)

Ratchet effects determine engineer reputation at large companies

drfloob

I work at a "large company", and I don't agree with most of this. Your write-up is highly subjective, and fairly pessimistic.

Some people hit the ground running, and teams/organizations/companies can thrive if they find ways to embrace that. Sometimes people get hired at the wrong level, and everyone benefits if some sort of work demonstrates that quickly. I have seen promotions happen based on prudent choices around one's individual strengths, simply by choosing to do a bit of the right work and getting eyes on your capabilities. There is no "one size fits all" prescription for what someone should work on.

Having a "shadow lead" can be one of the best situations for your growth, too. Not only do you get the experience leading a thing (for most of what that means, anyway), you may end up with a very strong ally when you knock it out of the park. I had a version of this experience, and I've watched others have it as well.

I'm guessing most of the negatives here are based on your personal experience, and for that I'm sorry. Hopefully you can encourage positive changes in your company's engineering culture.

trgn

> Having a "shadow lead" can be one of the best situations for your growth,

In a successful company with high retention, many senior engineers who would fill these roles as shadow lead, often have their ego turned down, less to prove, and will encourage you to succeed. In companies with a lot of churn, or always on the brink of disaster, you don't get that support.

overall though, I do agree with the article. orgs run on reputation, and it's slow to change, and snap judgements sadly matter.

janalsncm

> you may end up with a very strong ally when you knock it out of the park

I imagine this will be determined by the culture and the system of rewards which are out of your control. A shadow lead could be an ally, or they could pin any deficiencies on you. The author’s comment is sound in my opinion: depending on altruistic behavior is a bad position to be in.

000ooo000

The author's resume says he was a tech lead at Zendesk after 2.5 years of software development, with no formal software development qualifications. I'd be taking his perspectives with salt.

bgribble

I ran face-first into this effect at a successful startup where I started as employee number 9.

When everyone can sit around one big table, you don't have to consciously polish your "brand" all the time -- most people have direct experience with you and base their opinions on that. You do good work and you will have a good reputation. If you have a conflict with someone who is a jackass or have a project that fails to launch, people know enough about the context to judge pretty fairly.

When there are hundreds of people on the engineering team, especially in a remote-heavy workforce, most people don't have direct experience with you and can only base their opinion of you on what they hear from others, i.e. your reputation. This goes for peers as much as leadership.

You have to be aware of how an org changes over time, and how things that were once not important are now essential skills for success.. and decide if any new essentials are skills that you are interested in developing.

somekyle2

This seems generally true in my experience. Another aspect of this, from personal experience: while it may be easy to move around in a large organization, you risk losing reputational capital. I had a habit of building reputation in some team/platform, then after I no longer found it engaging or there was enough turnover/focus shift, I'd ask to transition to a wildly different team for a new challenge. It _is_ fun, but if you opt to start as an IC and work your way up, you're sorta letting the ratchet slip, and if you do it every couple years you may have broad experience, but your reputation (and likely level) will be well below where it could be.

Thus, unless you can ramp to expertise really quickly to leverage your skills developed elsewhere, I'd recommend (perhaps obviously) to try to move to peripheral teams where your skills and relationships transfer as much as possible.

hinkley

There is a time honored tradition of blaming the last person for all of your problems, or at least any they had proximity to.

Somewhat awkward if you later see them in a meeting.

somekyle2

Quite true! Having been fairly instrumental in a few areas that I'd eventually moved on from, it was always interesting to see some of my trademark accomplishments become The Old Thing We're Trying To Replace (or even just The Big Thing We Have To Maintain); gave me a lot of empathy for prior contributors of code I ended up inheriting. I tend to assume that the old thing seems dumb because of the constraints when it was written and changing requirements over time; if a tool made by one person in a few weeks seems hopelessly naive to the medium sized team investing a few quarters in replacing it a few years later, that seems to be a rousing success for the original author.

Terr_

>replacing it

Over the years I've come to say "design for deletion" when it comes to internal code. This means meaning more emphasis on making things straightforward to rip and out and replace, as opposed to stuff that is "configurable" or "extensible" etc.

As a junior developer, I know I spent too long on some things thinking that I could make a piece of Forever Art by adding ways for future developers to tweak its behavior.

xenity7

I’m engineering adjacent (analytics / data sci) but my experience has been the best engineers pitch and pick their own projects rather than being assigned out weeks in advance.

Just recently an engineering manager told me “I trust [IC7 engineer] to go where he is most impactful”

So this isn’t the only model, and successfully identifying and pitching working on high impact projects is a seniority marker that will lead to rapid promotion. In any organization. The pitch may look different in different places but I promise you - if an engineer is successfully pitching and delivering high impact projects promotion WILL follow.

Identifying and pitching high impact projects is a combo of technical and soft skills though, and the way this happens depends on the org.

kridsdale1

IME what you describe is considered a base expectation of L6 and above.

polishdude20

Problem for new hires is the onboarding process is very critical to determine if you'll be doing good work or not. Fighting against a code base all the time as you're left to your own devices is an uphill battle.

hinkley

A lot of places end up selecting for their own brand of crazy because of that.

The people who think, "this is fine" tend to fit in better. From a team stability perspective that's fine? But echo chambers eventually eat themselves and new perspective can lead to new features or bug fixes.

polishdude20

Last place I worked was like that. "Just embrace the chaos" but also "your new ideas aren't welcome here"

darth_avocado

Unfortunately when you go to a party, you can’t change the music until you’ve told a few jokes that everyone laughed at.

malfist

There's a very delicate balance to walk between chaos that works and a new idea that might be better or it might be worse or bring it's own type of chaos.

oefrha

Often times your new ideas aren’t new after all. Been there done that, only realized my stupidity as I grew more experienced.

darth_avocado

Problem for new hires is also whether your manager will support the onboarding. If you get throw n to the wolves with 1 month of “onboarding”, you’ll fail even with straightforward codebases. I’ve seen managers who bring you in and ask you, what the you and the team should be doing. And that’s never ended well.

zeroonetwothree

This seems to assume that engineers have no agency in the work they do—they are merely “assigned” tasks and they mindlessly carry them out. I don’t know what the authors experience has been but it doesn’t match mine in any of the places I’ve worked. Engineers typically have a lot of input about what they work on and if they are motivated can take on bigger projects right away. They can also extend the scope of assigned work to be much bigger than it was initially. All the best engineers I’ve worked with do this type of thing regularly.

wavemode

Well, yeah. If an engineer offers to do extra work, a businessperson isn't gonna say no.

If an engineer asks the businessperson for extra time... that's when things get dicey.

But, that's what nights and weekends are for, right? Go get em tiger.

ldjkfkdsjnv

After a decade plus in top tech:

Be the same ethnicity as engineering leadership in your org

horns4lyfe

Haha yep. And that’s only going to get worse, for reasons I doubt anyone wants to get into

deadbabe

Maybe applies for gender too?

readthenotes1

Something advice that I received that seemed truthy and actionable was:

Build your reputation by helping others get their job done while you do yours.

That was a part of the plot of Rand's _Fountainhead_, but you don't have to do it so selfishly, and doing it selflessly is possibly more effective in a non-stick workplace.

Is also contrary to football team advice, "stay in your lane and just do your job"; however, football teams are actually more like co-acting groups, where one may succeed while others, including the overall group, may fail so I'm not sure how applicable football advice is to the corporate world.

tantalor

This is a lot of words to describe hysteresis.

svnt

How is a ratchet effect hysteresis?

Jensen321

Able to talk like execs with those bombastic meaningless words get you more and faster result than what you describe here. You assume ratchet is always grinding thru within a company. Study mba then move out of the company after a few years then boomerang back still will achieve higher status than say your ratcheting. Stephen Elop was a good example. I doubt anyone will comment he was strong engineer. You need luck and significant talking skill. Strong or not strong technical skill, you can use chatgpt.

HumanOstrich

I was kinda with you in a cynical way until you pulled in AI/ChatGPT. Not helpful.

deadbabe

I don’t think author names need to be in the title

QuiCasseRien

ohoh, nice article. ohoh, there are others and they seems to be high quality. fucking ohoh, a rss feed, no add.

In my feed and bookmarked.

very good writer, experienced dev.