Top
Best
New

Posted by tuckerwales 11 hours ago

Calibrate Before You Accelerate: Bias Toward Action in a New Role(tucker.wales)
132 points | 55 commentspage 2
beaker52 7 hours ago|
This article is great advice that I should take if I ever get a role where I’m not going to be pressured into delivering some kind of low-value BS during Phase 2 that causes me to hasten the delivery the most useful organisational changes I can. I can’t help myself when the wick gets turned up.

As a result, after 15 years as a software engineer, I’m genuinely considering leaving the industry altogether because the only roles available to me are ones where I’m expected to deliver features rather than organisational change and growth. It’s like my heaps of experience have navigated my career into a cup-de-sac, and the only way out is backwards. I’m so jaded. Hopefully it’s a phase. I need a coach. Help.

nswango 6 hours ago|
Maybe your responsibility is to push back against the pressure put on you to deliver short-term.
mettamage 6 hours ago||
This whole conversation reminds me of the Career Cold Start discussion [1]. I remember looking it up at some point when I started a new job. It was somewhat useful, but a lot of this is also hard won knowledge once you understand what actual "working at a company" entails. I'm only beginning to get that sense after 7 years work experience at different companies (small startups, scaleups and now F500).

[1] https://news.ycombinator.com/item?id=16550270

hinkley 9 hours ago||
Nobody talks about SEI anymore but their Capability Maturity Model informed and/or aligned with how I approach new-to-me projects whether that 'new role' is internal or a new employer.

CMM says that an engineering team whose processes aren't written down is level 0, and writing them down, even if they are batshit, gets you to level 1. Which leads to a fun bit of catharsis with the older employees where they get to say things like, "and then a miracle occurs".

Also writing things down gives someone else a peek into what's going on in your head and they can correct bad assumptions you have before they get cemented and take more effort to dig out of your thought processes.

So I always start with fixing the documentation, the runbooks, the CI process. It's a deliverable you can engage in without breaking production, it demonstrates mastery, it fixes a pain point that the more professionally mature members of the team care about, which gets you brownie points with the right sort of people. And it makes it easier to onboard the next person, or pick back up a project that has been on the back burner for several quarters.

TODOs emerge from the documentation or get explained away as unnecessary or wontfix. By the time you're touching something you have a better idea of why things are like they are, so you make up for 'lost' time.

gsnedders 7 hours ago||
It's also, inevitably, the newest people who are often the best at fixing basic documentation — because they're the ones who don't already know it.
hinkley 2 hours ago||
Yes, the curse of knowledge. The new person only has industry jargon that everyone else will have and so they will describe any new concepts that way instead of with the circular logic the team has established. And that is often something I have to explain to the new person when they look dubious at the notion that they have any right to be touching the docs at all. They have more right than just about anyone.

It takes a really good teacher to be able to explain as easily to an intern as to a principal, and often the intermediate people have to take the beginners aside and reframe your explanations anyway. Whether you witness it happen or they do it where you cannot see, it happens.

lobofta 8 hours ago|||
I do the same. You work your way around the edges and get a genuinely good feel for the workflow while improving on it as you go.
hinkley 7 hours ago||
I also repeat the process with people that I'm responsible for onboarding. But it becomes my responsibility to compliment their contributions to the project in those early days so that it quells their nervousness about me tapping the brakes on their Bias Toward Action.

This is action, just not action that can tarnish both of us by shipping bugs to production.

Edit to add: I used to take ex coworkers out for coffee or beers around their last day and ask for a rundown of all the reasons they left. What you generally find if you let them keep talking is that they will run through the problems in reverse chronological order. The last thing they will mention is almost always what a joke the onboarding process was.

Last straws are the most recent thing that set the person off. All the straws before it add up, and if a person is already questioning the maturity of the organization on day 2 on the team, then I believe that multiplies your turnover rate. The longer you can go before a new employee says "what the actual fuck", is a multiplier on how long they will stick around.

Effectively, I think "the first 100 days" rule of thumb goes both ways. You get 100 days to show you're useful as an employee, but everyone already on the team is being held to the same yardstick by new employees. And if you're hiring at a high enough rate, having 20% of the team think the old employees are a waste of oxygen is not good for consensus building.

Ozzie-D 4 hours ago||
[flagged]
iSloth 11 hours ago||
Solid approach, although I’ve certainly seen many managers/staff that never actually break out of Phase 2

It’s critical to start showing some Phase 3 impact, even if not with a sledgehammer, before peers quickly loose faith

chessucation 4 hours ago||
i consult startups and i am regularly surprised to see how poorly-structured their employee onboarding is across all levels.

a new hand who doesn't have to wonder what the body is doing will be much more effective than one feeling around for other limbs.

austin-cheney 7 hours ago||
My experience as a long time corporate software developer is an exceptionally heavy bias towards inaction. There always seems to be fear and hesitation towards any kind of pivot or new initiative outside the rails of comfort. For example most corporate software developers cannot write an original new application from the ground up no matter how tiny or simplistic.

In such environments the people that do demonstrate a bias towards action tend to fall into one of two camps: those that wish they hadn't and those that are chasing attention.

The corporate developers who do have an overwhelming bias towards action, not the sociopath attention chasers, just end up contributing to open source projects unrelated to employment tasks.

nlawalker 6 hours ago|
I think a bias towards inaction often creates better outcomes for everyone, but a bias towards action creates better career results. Most of these places evaluate performance based on impact, and it's way easier to spin any kind of activity or impact as positive impact than it is to spin inaction as positive impact.
austin-cheney 4 hours ago||
I think the opposite. The best outcome for everyone is continuous growth and accomplishment of goals. Inaction only solves one important problem: comfort. The focus on comfort as a primary objective tends to be the quest of high neuroticism.
cindyllm 4 hours ago||
[dead]
antisthenes 9 hours ago||
This is why I like to build analysis tools first.

Making the ultimate visibility tool isn't just helpful to me as a newcomer. It may be useful to many veterans and people who haven't had the time to make this tool for themselves.

But I'm also somewhat biased towards laziness/observation.