I had a role, we got a new CTO. This man could not stop wiggling things. Almost from day one. Not just small things but larger things too (let's migrate to a new issue tracker/wiki thing (back when Redmine was popular)). Flipping staff to new focus (eg: moved a help-desk staff to top NetAdmin, replacing Cisco Certified guy, which caused some havoc during an audit). What a mess, just had to put his fingerprint on everything!
Another time we got bought, merged into a new company, their CTO was our new CTO. In one of the initial meetings said "things won't change much" and, naturally, we didn't believe. She moved slow on all the things, methodical. Spent some time with each component team. It was months before we started making changes to better mesh with the new company. Very little chaos. Still admire that management style.
I think there's a middle ground. I used to be intensely critical of "doing things just to do things." The more perspective I get, the more I realize that, in a situation where things are not going right by whatever criteria you use to determine that (outside scope here), you need to make changes.
The right way to make those changes, or at least one way and I don't know a better one, is to perturb the system and see how it responds. This is necessarily risky and uncomfortable, and choosing the right things to perturb and the magnitude of those peturbations is a very, very tricky skill.
But ultimately if you're dealing with an opaque system, which most companies are, and you want to make it a more transparent system that can change, that risk and discomfort are necessary side effects.
This is of course very situational, and the methodical method is by far preferred, but if you'll permit a metaphor: you get dropped into an unfamiliar cockpit, and the controls are labeled in some foreign language. The plane is crashing, or at least you don't know if it is. What do you do? You wiggle things and hope that, in doing so, you don't crash, and you take very careful note of what happens.
> But ultimately if you're dealing with an opaque system, which most companies are,
While most companies have elements that are hard to see clearly [1], I would hope 95% of what the company is doing would be transparent to the CEO.
The CEO should easily be able to tell which divisions/projects are profitable, which are on track to hit their goals, how those goals combine into a coherent strategy, which areas are getting the most complaints and refunds, and so on.
[1] intangible concepts like 'innovation' and 'culture' for example
If you can figure out how to turn the "should" in that sentence into "can" then you'll die wealthy. Tracking goals and turning them into a coherent strategy is a major unsolved problem in software engineering.
We accept best-effort from CTOs, but that leads to an industry that is a bit like a comet with a few success stories and a huge burning tail of leadership where they have limited to no ability to understand whether they are on track to achieve their goals and those goals don't come together into a coherent strategy. There is a strong argument that many of the success stories are only good relative to companies that failed even worse than they did and we all had to pick one of these bug-ridden software packages.
It is a lot like the era of the manufacturing industry before the statisticians moved in around WWII. We haven't managed a similar moment in software yet.
You can never understand complex adaptive systems to anywhere near 95%, and leaders believing that they can—that the map is the territory—leads to some pretty bad dynamics.
Sadly at many companies that's really not true. The CEO has direct visibility into direct reports and those metrics, but those don't necessarily clearly indicate what changes to the system would do. Largely because they're descriptive, not predictive, in my limited experience. They also tend to be lagging or current indicators, so they tell you what policy was doing last quarter. If those metrics are trending badly, you can't just demand "move X number up" and expect any success.
Any workable management approach relies on not managing down further than your direct reports, and believing what they say. Otherwise you've eliminated that layer of middle management, and have to do their work.
It might happen that this is the correct approach, and how to slice things up is often an eternal argument both on an organizational level and technical level.
Unfortunately that gives a lot of power to the middlemen, whoch they might use against you, but that's how the cookie crumbles.
My internal metaphor for senior management is of a man sitting in a darkened room receiving slips of paper under the door with little messages on them.
That's why founder types have such a massive advantage. They've got a much better mental picture of what's beyond the door.
This might be appropriate in some cases, but it's important to consider that you have a finite amount of social capital as a new leader. Once people get sick of poorly thought-out changes it can be hard to keep changing things and get buy-in, and talented employees (who almost always have someone asking to hire them) can be the first to leave.
I'm a fan of Chesterton's Fence [1]. Put effort into understanding the organization and why it's architected the way it is before making changes.
absolutely. You have to get hearts and minds, and honestly that's the biggest job as any kind of leadership. I think if you say to people "We have to make changes, these are not arbitrary, the company needs to do X soon, and the best way to understand that is to make some short term uncomfortable changes. I want your feedback" etc, if you build trust through connecting your actions to your words, people can accept that.
The other part of that is ensuring that it doesn't fall disproportionately on certain sections of the company, and that you provide compensatory benefits like, say, comp overtime, extra vacation, bonuses, whatever is possible.
A great philosophy for anyone who is pretending to know what they're doing that will still result in the plane crashing because you need to know how to fly a plane to fly a plane, and you need to know how to run a business to run a business.
On the other hand, because you've run business A, doesn't mean you have a clue how business B is actually working. I've seen that one more than a few times too.
Sometimes the plane is going to crash and the best you can do is a soft landing.
In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."
Except in many cases it is your responsibility to ask. If something has indefined legal status, and no documentation, it is a major red flag. Very often corruption, drug or people trafficking or other shady stuff.
If you want gate in middle of the public road, show the paperwork! Or I will call authorities!
The responsibility to ask is literally the point of Chesterton's fence in my mind; when something looks out of place, and you think it doesn't make sense, you need to ask and learn about it. Sometimes the fence genuinely is unnecessary, and you can then proceed to dismantle it, but other times it might be useful for surprising reasons; it might be a mitigation for an issue that would require a much more time-consuming fix; and it might sometimes genuinely be unnecessary. The point of finding out this information is that the correct action is different for each of them; taking down the fence is fine if it's genuinely useless, and leaving it alone is necessary if it's genuinely useful for reasons you didn't anticipate. In the middle ground where there's a better solution that would take more time, the correct action depends on the answer to a follow-up: is replacing the fence the most important use of my time right now? I've experienced all three of these situations before (and both possible answers to the follow-up in the third case), so I've found this framework helpful for how to deal with the fences when I come across them.
How you ask the question matters just as much as whether you should ask it. Impressionable ears are everywhere and asking 'is there icecream in the house?' means that everyone is about to get a bowl or be upset.
Yes, Chesterton clearly hadn’t started working at a job where he was responsible for the security or accuracy of a process. “Then Marge calculates the late penalties by hand and enters them into the system? It’s fine, she … has a method?Really?”
The point Chesterton is making isn’t that you leave everything alone. It’s just that you find out why something is there before you take it out. Find out my Marge calculates the penalties by hand. You may find that the program gets it wrong, in which case taking her out of the process would be a disaster unless you fix the underlying problem first. Or you may find that it’s completely pointless and you can go straight to using the automation. It’s not that you ignore it and leave it forever, just that you find out what’s going on before you start taking the axe to things.
Chesterton was talking about politics (public policy). And 'responsible for security or accuracy' well, have you heard of politics? If you haven't, don't look it up, it will just depress you.
What a ridiculous misrepresentation of the principle. In fact isn't that a good illustration of the principle? The fence is just sitting there, maybe it's annoying or slows you down but it isn't actually an acute problem or an emergency. All the more reason to not just rip it out without taking the time to understand why it's there.
Something which, as soon as you discover it, you should immediately respond by trying to remove it, without asking questions about where it came from or what its purpose might be.
I have encountered many. For example if you find a password in plaintext in source control, you don't assume the person who put it there had a good reason, you assume they were deeply misguided.
This article is highly AI generated. The first paragraph is probably not AI generated, but the rest is definitely.
I also double checked on gptzero me and it 100% agrees with me.
I'm curious to know though whether or not the "author" used Gemini. I've been using Gemini a lot in the past year, and the writing sounds exactly like Gemini. But it's possible that all the models sound the same.
Edit: I'd like to add that I still liked the article and agree with it, and in general I find Gemini's writing style to be quite enjoyable.
How do you know? I think LLMs are more than advanced enough to come up with this text.
In fact, I think they've got so much more management in their training set than a senior engineer that I expect they're going to be a better source of material than the author.
The title was already a clue that it's AI-generated, and it only gets worse...
The first paragraph is probably not AI generated
"A bias toward action is a superpower only when applied correctly - here's how to frame it as moving decisively after building context, not rushing in before you have it."
...followed by many, many bloated words that can basically be summed up in two words of old Internet lore: LURK MOAR
I agree with the article too, but I didn't have to read that many words to know. "Don't just start doing things because you want to show off, and understand what value you're providing" is how I'd phrase it.
The images are awesome, in an “I cannot believe someone would upload this to their site” kind of way.
The blueprint with the “LOAD-BEARING WALL!!!” includes nonsensical labels like “Dining Broom” and “Witchen”, and I am supremely disappointed that there isn’t a bubbling cauldron or pointed hat to be found.
I don’t see why it is interesting to claim that a piece is AI generated, especially in light of the concession in your last paragraph that you liked the article.
AI is a tool. It outputs things only when asked to. Asking it requires skill. Saying “This is AI generated” is like pointing at furniture and saying that “power tools were used to build that” or at a program and saying “that’s not assembly, a modern garbage-collected language was used to build that” or at a meal and saying “this was cooked in a kitchen with a modern temperature-controlled oven” or at a paper and saying “this was obviously typeset in LaTeX, not roff or plain TeX.”
So what? Give me a shop full of power tools and I can’t build any furniture, give me Python and a bunch of libraries and I can’t write Mercurial, and give me any LLM and I couldn’t have written this piece.
Does the conceit come from the idea of “some LLM wrote this, so anyone could”? This is like walking through a modern art museum and seeing some obvious-looking piece and saying “I could have done that.” Well, you didn’t.
> AI is a tool. It outputs things only when asked to.
This is not entirely accurate if we consider agentic loops.
> Asking it requires skill.
Considering the realm of writing a blog post instead of programming, what is the skill? I suspect there is extremely little. But I could be wrong, tell me what skill you think went into this.
> and give me any LLM and I couldn’t have written this piece.
Prompt your LLM of choice to generate 100 articles about different aspects of joining a new role, then you won’t need to provide the insights into the specific situations the author described. All you need to do is pay for the tokens.
> Does the conceit come from the idea of “some LLM wrote this, so anyone could”?
Yes.
> Well, you didn’t.
Do you know that? What’s stopping someone from asking an LLM to generate an entire HN front page worth of articles, and reading that list instead of HN?
This really is a problem with the health of the site in my opinion. If there are a flood of AI generated articles in the top spot, the value proposition of HN as a site is diminished.
Hey, thanks for taking the time to respond to feedback.
I believe there is a societal problem here, not specific to your particular actions. The expectation that communications should be “cleaned up” and “professional” in the first place comes from a bygone era. In the 2010s and earlier removing all typos, fixing wording, formatting the text and adding images were all signals that someone put extra care into sending their message. But in the present that just indicates use of AI.
You mentioned in another comment that your hand-drawn images would be “far worse”. Leaving aside whether any images were needed at all, a hand-drawn scribble in the 2010s might be unprofessional but in the present day there’s an AI generated image on every visible surface. A hand-drawn image, even a bad one, would actually make you stand out.
Even if you want to present the cleaned up version, you could also provide the original audio.
Appreciate the feedback and I don't necessarily disagree with your points - the societal argument is an interesting one.
I do think it's interesting that some people are immediately turned off of something because of the whiff of AI even if they like the actual idea or content.
Will likely experiment with different ways of writing in the future!
broadly speaking AI has shown itself to be unreliable in a lot of domains so even if its strongest feature is in fact language, it still carries a readers predisposed experiences with the tech.
That is just one problem. You also have to contend with the onslaught of AI generated content that is being used in deliberately fake articles, online personas and the mountains and mountains of things people and entities are trying to push to make a buck. Scams, misinformation, state-sponsored propaganda, a lot of things that are arguably bad for society. So if you consider that, you must also accept that you are making a choice to use a linguistic style that is used by many websites that are vectors that do harm or deliberately mislead (which also does harm).
Even if the ideas are of your own merit, you can't expect readers to always do the literary surgery it will take to identify that.That's extra investigative work and assessment that was never a part of anyones reportoire before all this took off. But at this point i don't think you should be surprised that AI writing isn't met with open arms, AI writing has become a pain point for a lot of people in their personal lives and their work lives, a lot of organizations are wounding themselves as people throw their ideas around curated in AI and everyone's eyes are glazing over. It's become synonymous with "this guy does not understand the claude proposal he just sent me". And the choice is yours if you still want to use it knowing that, I just don't think you should be surprised if it doesn't get the reception you hoped for.
Plus, you should lean into whatever your monologue is to write. Even if you're afraid it's not pro enough, like. That's writing. It's a journey it has crossover with your ability to communicate it defines you as a person. Keep sharpening that tool and you have untold ways to convey ideas exactly the way you want people to experience them for the first time.
Why would I not just type in "how do I correctly balance towards action in a new role" into chatgpt and read that instead? I have no signal that the author did anything beyond that himself.
How would I discern that from the AI slop images and AI formatting? What you just said is not signal, it's things you privately know. There are a lot of blogs out there. You need to appear superficially worth reading before I know your biography and work processes.
"You need to..." implies "for me to read it", me possibly being a proxy for others, and nothing more. So responding to "You need to do X for me to read it" with " I don't need to do anything. You can choose to read or choose not to read." is just restating my comment tautologically. I think you are taking my criticism personally, but it's not personal or even related to the content because I don't know you and I didn't read it. I am just giving you the feedback that AI writing is a negative signal that is going to make a lot of people not read the thing, not because it's annoying to read, but just because there's no inherent indication that anyone thought through this text like there usually is when something is published.
Also, you engaged with my comment, not I with yours, and I attempted to converse with you, but you then exited superciliously (below) without engaging with or even acknowledging my point. You don't need to say goodbye online if you don't want to discuss what I'm saying.
Solid article. Its worth calling out one thing thats maybe not emphasized enough though: while your contributions may start small make sure to publicize them appropriately. No need to cross post to every channel, but do post about it somewhere or socialize it somehow. Take a lot of time to craft a thoughtful and easy to read message.
Reputations are hard to earn and easy to destroy. Trust building at any new institution takes a lot of time and effort and can seem annoying. But just doing solid work and communicating about it consistently will make sure that like minded people notice you, vouch for you and then give you more opportunities.
When I hear "Bias toward action", it reminds me of von Hammerstein's typology:
> I distinguish four types. There are clever, hardworking, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and hardworking; their place is the General Staff. The next ones are stupid and lazy; they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the mental clarity and strength of nerve necessary for difficult decisions. One must beware of anyone who is both stupid and hardworking; he must not be entrusted with any responsibility because he will always only cause damage. [0]
So reframed, TFA argues that one must be "hardworking and clever" instead of "hardworking and stupid".
Sort of the antithesis of "Move fast and break things." I find it quite reasonable, but also despair that this advice even needs to be given. It's just basic "horse sense."
My last few jobs I started with a listening tour. I talked to everyone who was relevant to the job and asked them:
- what is going well,
- what is not going well
-what do hope that I will fix
-what should I do
-what should I not do
I put those question in the agenda for the meeting invite so they could come prepared. Then we took the conversation from there.
I put it all into a google doc, then synthesized it into summary that hid the identities of the people who said it and used it as my guide for the first few months.
FWIW I've been saying it in a sarcastic way since I was in my teens because of the Simpsons where Bart says "It's a load bearing poster." I assume if anyone uses the phrase (that isn't like a civil engineer) it probably came from here lol
https://www.youtube.com/watch?v=QRVExJZKIT8
There's one caveat to this – I think it's good to have bias to other people's actions early on in a new role. Taking on little projects that are already understood, taking on cleanups, things other people aren't volunteering for, is all a great way to find where some of the bodies are buried, understand how the team works, and prove yourself as a team player.
Thoughtful and to the point, I like it. I’m curious how long this process takes others. I’m in a new role for the first time in a while and trying to find the right balance between ramping up quickly and taking enough time for deeper learning.
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.
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.
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.
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.
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.
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).
I've met my fair share of people throughout the years for whom this wasn't self-evident. Anecdatally, they also don't tend to stick around for too long. I suspect it's because teams don't tend to warm to people who already enter the door with a "you're doing it wrong".
But yes, the article can basically be distilled into just Chesterton's Fence.
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.
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.
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.
I had a role, we got a new CTO. This man could not stop wiggling things. Almost from day one. Not just small things but larger things too (let's migrate to a new issue tracker/wiki thing (back when Redmine was popular)). Flipping staff to new focus (eg: moved a help-desk staff to top NetAdmin, replacing Cisco Certified guy, which caused some havoc during an audit). What a mess, just had to put his fingerprint on everything!
Another time we got bought, merged into a new company, their CTO was our new CTO. In one of the initial meetings said "things won't change much" and, naturally, we didn't believe. She moved slow on all the things, methodical. Spent some time with each component team. It was months before we started making changes to better mesh with the new company. Very little chaos. Still admire that management style.
I think there's a middle ground. I used to be intensely critical of "doing things just to do things." The more perspective I get, the more I realize that, in a situation where things are not going right by whatever criteria you use to determine that (outside scope here), you need to make changes.
The right way to make those changes, or at least one way and I don't know a better one, is to perturb the system and see how it responds. This is necessarily risky and uncomfortable, and choosing the right things to perturb and the magnitude of those peturbations is a very, very tricky skill.
But ultimately if you're dealing with an opaque system, which most companies are, and you want to make it a more transparent system that can change, that risk and discomfort are necessary side effects.
This is of course very situational, and the methodical method is by far preferred, but if you'll permit a metaphor: you get dropped into an unfamiliar cockpit, and the controls are labeled in some foreign language. The plane is crashing, or at least you don't know if it is. What do you do? You wiggle things and hope that, in doing so, you don't crash, and you take very careful note of what happens.
> But ultimately if you're dealing with an opaque system, which most companies are,
While most companies have elements that are hard to see clearly [1], I would hope 95% of what the company is doing would be transparent to the CEO.
The CEO should easily be able to tell which divisions/projects are profitable, which are on track to hit their goals, how those goals combine into a coherent strategy, which areas are getting the most complaints and refunds, and so on.
[1] intangible concepts like 'innovation' and 'culture' for example
If you can figure out how to turn the "should" in that sentence into "can" then you'll die wealthy. Tracking goals and turning them into a coherent strategy is a major unsolved problem in software engineering.
We accept best-effort from CTOs, but that leads to an industry that is a bit like a comet with a few success stories and a huge burning tail of leadership where they have limited to no ability to understand whether they are on track to achieve their goals and those goals don't come together into a coherent strategy. There is a strong argument that many of the success stories are only good relative to companies that failed even worse than they did and we all had to pick one of these bug-ridden software packages.
It is a lot like the era of the manufacturing industry before the statisticians moved in around WWII. We haven't managed a similar moment in software yet.
You can never understand complex adaptive systems to anywhere near 95%, and leaders believing that they can—that the map is the territory—leads to some pretty bad dynamics.
Not just wrong, but confidently wrong! I've done that one myself a couple times too.
Sadly at many companies that's really not true. The CEO has direct visibility into direct reports and those metrics, but those don't necessarily clearly indicate what changes to the system would do. Largely because they're descriptive, not predictive, in my limited experience. They also tend to be lagging or current indicators, so they tell you what policy was doing last quarter. If those metrics are trending badly, you can't just demand "move X number up" and expect any success.
Any workable management approach relies on not managing down further than your direct reports, and believing what they say. Otherwise you've eliminated that layer of middle management, and have to do their work.
It might happen that this is the correct approach, and how to slice things up is often an eternal argument both on an organizational level and technical level.
Unfortunately that gives a lot of power to the middlemen, whoch they might use against you, but that's how the cookie crumbles.
That's why sometimes new management comes in and cleans house at the direct report level so they have people they know they can trust.
My internal metaphor for senior management is of a man sitting in a darkened room receiving slips of paper under the door with little messages on them.
That's why founder types have such a massive advantage. They've got a much better mental picture of what's beyond the door.
This might be appropriate in some cases, but it's important to consider that you have a finite amount of social capital as a new leader. Once people get sick of poorly thought-out changes it can be hard to keep changing things and get buy-in, and talented employees (who almost always have someone asking to hire them) can be the first to leave.
I'm a fan of Chesterton's Fence [1]. Put effort into understanding the organization and why it's architected the way it is before making changes.
[1] https://www.lesswrong.com/w/chesterton-s-fence
absolutely. You have to get hearts and minds, and honestly that's the biggest job as any kind of leadership. I think if you say to people "We have to make changes, these are not arbitrary, the company needs to do X soon, and the best way to understand that is to make some short term uncomfortable changes. I want your feedback" etc, if you build trust through connecting your actions to your words, people can accept that.
The other part of that is ensuring that it doesn't fall disproportionately on certain sections of the company, and that you provide compensatory benefits like, say, comp overtime, extra vacation, bonuses, whatever is possible.
A great philosophy for anyone who is pretending to know what they're doing that will still result in the plane crashing because you need to know how to fly a plane to fly a plane, and you need to know how to run a business to run a business.
On the other hand, because you've run business A, doesn't mean you have a clue how business B is actually working. I've seen that one more than a few times too.
Sometimes the plane is going to crash and the best you can do is a soft landing.
Ok but also one surefire way to crash a plane is to enter the cockpit and start perturbing things.
Cannot cite Chesterton's fence too often.
In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."
— https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
Related: https://news.ycombinator.com/item?id=38653711
> a fence or gate erected across a road.
Except in many cases it is your responsibility to ask. If something has indefined legal status, and no documentation, it is a major red flag. Very often corruption, drug or people trafficking or other shady stuff.
If you want gate in middle of the public road, show the paperwork! Or I will call authorities!
The responsibility to ask is literally the point of Chesterton's fence in my mind; when something looks out of place, and you think it doesn't make sense, you need to ask and learn about it. Sometimes the fence genuinely is unnecessary, and you can then proceed to dismantle it, but other times it might be useful for surprising reasons; it might be a mitigation for an issue that would require a much more time-consuming fix; and it might sometimes genuinely be unnecessary. The point of finding out this information is that the correct action is different for each of them; taking down the fence is fine if it's genuinely useless, and leaving it alone is necessary if it's genuinely useful for reasons you didn't anticipate. In the middle ground where there's a better solution that would take more time, the correct action depends on the answer to a follow-up: is replacing the fence the most important use of my time right now? I've experienced all three of these situations before (and both possible answers to the follow-up in the third case), so I've found this framework helpful for how to deal with the fences when I come across them.
How you ask the question matters just as much as whether you should ask it. Impressionable ears are everywhere and asking 'is there icecream in the house?' means that everyone is about to get a bowl or be upset.
Yes, Chesterton clearly hadn’t started working at a job where he was responsible for the security or accuracy of a process. “Then Marge calculates the late penalties by hand and enters them into the system? It’s fine, she … has a method?Really?”
The point Chesterton is making isn’t that you leave everything alone. It’s just that you find out why something is there before you take it out. Find out my Marge calculates the penalties by hand. You may find that the program gets it wrong, in which case taking her out of the process would be a disaster unless you fix the underlying problem first. Or you may find that it’s completely pointless and you can go straight to using the automation. It’s not that you ignore it and leave it forever, just that you find out what’s going on before you start taking the axe to things.
Chesterton was talking about politics (public policy). And 'responsible for security or accuracy' well, have you heard of politics? If you haven't, don't look it up, it will just depress you.
As a counterpoint, being useful is not always a sufficient reason to resist changing. Historical design can be also be flawed or just accidental.
I’ve always liked Chesterton’s Fire.
Maybe there’s a reason you’re on fire. Until you can say for sure, I will not put it out.
I will just be here roasting these marshmallows on your burning flesh. :)
What a ridiculous misrepresentation of the principle. In fact isn't that a good illustration of the principle? The fence is just sitting there, maybe it's annoying or slows you down but it isn't actually an acute problem or an emergency. All the more reason to not just rip it out without taking the time to understand why it's there.
My version was Chesterton's Facehugger.
Something which, as soon as you discover it, you should immediately respond by trying to remove it, without asking questions about where it came from or what its purpose might be.
Do you have a real practical example of this? I have never encountered a real one that didn't turn out to be a fence in hindsight.
I have encountered many. For example if you find a password in plaintext in source control, you don't assume the person who put it there had a good reason, you assume they were deeply misguided.
This article is highly AI generated. The first paragraph is probably not AI generated, but the rest is definitely.
I also double checked on gptzero me and it 100% agrees with me.
I'm curious to know though whether or not the "author" used Gemini. I've been using Gemini a lot in the past year, and the writing sounds exactly like Gemini. But it's possible that all the models sound the same.
Edit: I'd like to add that I still liked the article and agree with it, and in general I find Gemini's writing style to be quite enjoyable.
Definitely stinks of LLM phrasing, metering, and punctuation. But I'd say the ideas are the author's alone and they do cut through.
How do you know? I think LLMs are more than advanced enough to come up with this text.
In fact, I think they've got so much more management in their training set than a senior engineer that I expect they're going to be a better source of material than the author.
The title was already a clue that it's AI-generated, and it only gets worse...
The first paragraph is probably not AI generated
"A bias toward action is a superpower only when applied correctly - here's how to frame it as moving decisively after building context, not rushing in before you have it."
...followed by many, many bloated words that can basically be summed up in two words of old Internet lore: LURK MOAR
I agree with the article too, but I didn't have to read that many words to know. "Don't just start doing things because you want to show off, and understand what value you're providing" is how I'd phrase it.
The AI generated images are classic slop to the point of being actively distracting.
The images are awesome, in an “I cannot believe someone would upload this to their site” kind of way.
The blueprint with the “LOAD-BEARING WALL!!!” includes nonsensical labels like “Dining Broom” and “Witchen”, and I am supremely disappointed that there isn’t a bubbling cauldron or pointed hat to be found.
The Chesterton's Fence one also says in the caption that the fence has been removed, while in the image it's actually wider than in the first panel.
Yeah, nobody took one second to look this over before posting it directly from the slop machine =(
My hand drawn images would be far worse!
I don’t see why it is interesting to claim that a piece is AI generated, especially in light of the concession in your last paragraph that you liked the article.
AI is a tool. It outputs things only when asked to. Asking it requires skill. Saying “This is AI generated” is like pointing at furniture and saying that “power tools were used to build that” or at a program and saying “that’s not assembly, a modern garbage-collected language was used to build that” or at a meal and saying “this was cooked in a kitchen with a modern temperature-controlled oven” or at a paper and saying “this was obviously typeset in LaTeX, not roff or plain TeX.”
So what? Give me a shop full of power tools and I can’t build any furniture, give me Python and a bunch of libraries and I can’t write Mercurial, and give me any LLM and I couldn’t have written this piece.
Does the conceit come from the idea of “some LLM wrote this, so anyone could”? This is like walking through a modern art museum and seeing some obvious-looking piece and saying “I could have done that.” Well, you didn’t.
> AI is a tool. It outputs things only when asked to.
This is not entirely accurate if we consider agentic loops.
> Asking it requires skill.
Considering the realm of writing a blog post instead of programming, what is the skill? I suspect there is extremely little. But I could be wrong, tell me what skill you think went into this.
> and give me any LLM and I couldn’t have written this piece.
Prompt your LLM of choice to generate 100 articles about different aspects of joining a new role, then you won’t need to provide the insights into the specific situations the author described. All you need to do is pay for the tokens.
> Does the conceit come from the idea of “some LLM wrote this, so anyone could”?
Yes.
> Well, you didn’t.
Do you know that? What’s stopping someone from asking an LLM to generate an entire HN front page worth of articles, and reading that list instead of HN?
This really is a problem with the health of the site in my opinion. If there are a flood of AI generated articles in the top spot, the value proposition of HN as a site is diminished.
Author here: I dictated this article into my phone and got a model to transcribe and clean up / reword.
I'd argue that counts as using AI as a tool for conveying my original thoughts.
Hey, thanks for taking the time to respond to feedback.
I believe there is a societal problem here, not specific to your particular actions. The expectation that communications should be “cleaned up” and “professional” in the first place comes from a bygone era. In the 2010s and earlier removing all typos, fixing wording, formatting the text and adding images were all signals that someone put extra care into sending their message. But in the present that just indicates use of AI.
You mentioned in another comment that your hand-drawn images would be “far worse”. Leaving aside whether any images were needed at all, a hand-drawn scribble in the 2010s might be unprofessional but in the present day there’s an AI generated image on every visible surface. A hand-drawn image, even a bad one, would actually make you stand out.
Even if you want to present the cleaned up version, you could also provide the original audio.
Appreciate the feedback and I don't necessarily disagree with your points - the societal argument is an interesting one.
I do think it's interesting that some people are immediately turned off of something because of the whiff of AI even if they like the actual idea or content.
Will likely experiment with different ways of writing in the future!
broadly speaking AI has shown itself to be unreliable in a lot of domains so even if its strongest feature is in fact language, it still carries a readers predisposed experiences with the tech. That is just one problem. You also have to contend with the onslaught of AI generated content that is being used in deliberately fake articles, online personas and the mountains and mountains of things people and entities are trying to push to make a buck. Scams, misinformation, state-sponsored propaganda, a lot of things that are arguably bad for society. So if you consider that, you must also accept that you are making a choice to use a linguistic style that is used by many websites that are vectors that do harm or deliberately mislead (which also does harm).
Even if the ideas are of your own merit, you can't expect readers to always do the literary surgery it will take to identify that.That's extra investigative work and assessment that was never a part of anyones reportoire before all this took off. But at this point i don't think you should be surprised that AI writing isn't met with open arms, AI writing has become a pain point for a lot of people in their personal lives and their work lives, a lot of organizations are wounding themselves as people throw their ideas around curated in AI and everyone's eyes are glazing over. It's become synonymous with "this guy does not understand the claude proposal he just sent me". And the choice is yours if you still want to use it knowing that, I just don't think you should be surprised if it doesn't get the reception you hoped for.
Plus, you should lean into whatever your monologue is to write. Even if you're afraid it's not pro enough, like. That's writing. It's a journey it has crossover with your ability to communicate it defines you as a person. Keep sharpening that tool and you have untold ways to convey ideas exactly the way you want people to experience them for the first time.
Why would I not just type in "how do I correctly balance towards action in a new role" into chatgpt and read that instead? I have no signal that the author did anything beyond that himself.
Apart from years of experience and thinking about this problem, dictating my thoughts into my phone and transcribing and posting...
How would I discern that from the AI slop images and AI formatting? What you just said is not signal, it's things you privately know. There are a lot of blogs out there. You need to appear superficially worth reading before I know your biography and work processes.
Respectfully, I don't need to do anything. You can choose to read or choose not to read. Have a great day!
"You need to..." implies "for me to read it", me possibly being a proxy for others, and nothing more. So responding to "You need to do X for me to read it" with " I don't need to do anything. You can choose to read or choose not to read." is just restating my comment tautologically. I think you are taking my criticism personally, but it's not personal or even related to the content because I don't know you and I didn't read it. I am just giving you the feedback that AI writing is a negative signal that is going to make a lot of people not read the thing, not because it's annoying to read, but just because there's no inherent indication that anyone thought through this text like there usually is when something is published.
Also, you engaged with my comment, not I with yours, and I attempted to converse with you, but you then exited superciliously (below) without engaging with or even acknowledging my point. You don't need to say goodbye online if you don't want to discuss what I'm saying.
"I didn't read it" - good day, sir. Enjoy your weekend!
AIDR
Who cares!
People who value their time more highly than wanting to spend 5 minutes reading something that took someone 3 seconds of effort to produce, if that.
I visit HN because it's supposed to surface interesting, novel, engaging, challenging articles. LLM output is the extreme opposite of that.
I think this comment is AI generated.
Solid article. Its worth calling out one thing thats maybe not emphasized enough though: while your contributions may start small make sure to publicize them appropriately. No need to cross post to every channel, but do post about it somewhere or socialize it somehow. Take a lot of time to craft a thoughtful and easy to read message.
Reputations are hard to earn and easy to destroy. Trust building at any new institution takes a lot of time and effort and can seem annoying. But just doing solid work and communicating about it consistently will make sure that like minded people notice you, vouch for you and then give you more opportunities.
When I hear "Bias toward action", it reminds me of von Hammerstein's typology:
> I distinguish four types. There are clever, hardworking, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and hardworking; their place is the General Staff. The next ones are stupid and lazy; they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the mental clarity and strength of nerve necessary for difficult decisions. One must beware of anyone who is both stupid and hardworking; he must not be entrusted with any responsibility because he will always only cause damage. [0]
So reframed, TFA argues that one must be "hardworking and clever" instead of "hardworking and stupid".
[0]: https://en.wikipedia.org/wiki/Kurt_von_Hammerstein-Equord#Cl...
Sort of the antithesis of "Move fast and break things." I find it quite reasonable, but also despair that this advice even needs to be given. It's just basic "horse sense."
https://i.pinimg.com/736x/a5/b3/10/a5b31033a487595f913639c35...
My last few jobs I started with a listening tour. I talked to everyone who was relevant to the job and asked them:
- what is going well,
- what is not going well
-what do hope that I will fix
-what should I do
-what should I not do
I put those question in the agenda for the meeting invite so they could come prepared. Then we took the conversation from there.
I put it all into a google doc, then synthesized it into summary that hid the identities of the people who said it and used it as my guide for the first few months.
Great approach - I'd add a key one: "Who else should I talk to / who is (regardless of title) effectively responsible for X?"
OT: This is the first time in a while that I’ve seen the phrase “load-bearing” used in a natural way. :-)
Is it natural? It immediately made me suspect AI, if for no other reason than every human is avoiding it now so they’re not confused with AI.
Props to the author if they simply don’t care though.
FWIW I've been saying it in a sarcastic way since I was in my teens because of the Simpsons where Bart says "It's a load bearing poster." I assume if anyone uses the phrase (that isn't like a civil engineer) it probably came from here lol https://www.youtube.com/watch?v=QRVExJZKIT8
Pangram says 100% AI generated.
There's one caveat to this – I think it's good to have bias to other people's actions early on in a new role. Taking on little projects that are already understood, taking on cleanups, things other people aren't volunteering for, is all a great way to find where some of the bodies are buried, understand how the team works, and prove yourself as a team player.
Thoughtful and to the point, I like it. I’m curious how long this process takes others. I’m in a new role for the first time in a while and trying to find the right balance between ramping up quickly and taking enough time for deeper learning.
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.
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.
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.
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.
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.
[flagged]
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.
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.
Maybe your responsibility is to push back against the pressure put on you to deliver short-term.
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
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
I wish there was a repository of stories about new managers changing things, ruining everything and leaving in 2 years.
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.
So… figure out what’s going on before changing things?
I must admit I’ve always considered this to be self-evident but maybe I’m the odd one out.
I’d be a terrible blogger.
I've met my fair share of people throughout the years for whom this wasn't self-evident. Anecdatally, they also don't tend to stick around for too long. I suspect it's because teams don't tend to warm to people who already enter the door with a "you're doing it wrong".
But yes, the article can basically be distilled into just Chesterton's Fence.
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.
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.
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.
[dead]