Ratchet effects determine engineer reputation at large companies | Hacker News Reader

Ratchet effects determine engineer reputation at large companies

seangoedecke.com

115 pointsrbanffy41 comments

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.

> 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.

> 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.

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.

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.

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.

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.

>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.

The problem I often run into is people equating “we need to replace this” with “it never should have existed”.

Whether it needs to be replaced or not has absolutely nothing to do with how it got there in the first place. Yes, maybe the company avoiding bankruptcy due to your clever kludge. Thank you for your service. But today we are tripping over your kludge left, right, and center. So it gots ta go.

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.

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.

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

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.

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.

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

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.

One of my coworkers told me (mostly joking) I wasn't allowed to talk to any more of his team because every person I talked to left.

I was trying to recruit people to help me fix the chaos. It's not my fault they decided it would be easier to start over somewhere else once they agreed about all the things that pissed me off.

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

So fun is proportional to the extent to which the punch bowl has been spiked? Seriously asking.

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

That's the young kids. Most of us are trying to bring in solutions we already tested elsewhere, so we don't have to regress just because we got a new job. Or get rid of new things that YOU PEOPLE invented when there's a perfectly workable industry standard that isn't festooned with corner cases and no documentation.

That is incidentally one of the advantages of contributing fixes back to OSS. At least you don't have to fix the same bugs in your tools again at every job. After a few years you start to forget how you did it.

And you’re usually not the first one to have brought it up, even though you think you are. So people are wasting time shooting down what they have shot down before, not a great way to introduce yourself.

Not necessarily. Recalcitrance is the flip side of this coin. But it tends to break down when five different people are telling you in five different ways how you’re fucking things up for everybody by being stubborn.

I’ve learned to send the new guy to ask instead of parroting back why we aren’t going to be allowed to change something stupid. Because once in a while they disappear for an hour and then come back with news that we’re finally going to fix it.

We all have to look at the same code. The person who writes it specifically for their own tastes has an undue advantage over everyone else because the code exactly matches their crazy. But if you write code everyone else can also read, you only slow yourself down a little and double or triple everyone else’s productivity. Or you can keep being the selfish asshole who uses appeals to authority. Don’t be surprised if you start encountering coup attempts.

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.

> 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.

Been there. Very personality driven business, making tons of money with prebid. The whole business was a tangled mess. I lasted 3 months and the crazy thing is, the trigger to leave wasn't even the mess and the absolute lack of onboarding or technical leadership. I was willing to help them fix it. But the owner had a habit of yelling at employees and by the 3rd time I witnessed it was happening to me and I quit on the spot.

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.

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.

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.

After a decade plus in top tech:

Be the same ethnicity as engineering leadership in your org

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

Maybe applies for gender too?

This is a lot of words to describe hysteresis.

How is a ratchet effect hysteresis?

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.

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

You may not know what the words mean within the cultural context, but that doesn't mean they don't have a precise meaning.

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

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.

Sidenote. Terrible reading experience due to the background color and shiny white font. Too bad for such fine content.

Jeebus just use reader mode and move on.

I wrote the article. Thanks for the feedback!

Reply on news.ycombinator.com