Let It Fail(maxcountryman.com)
maxcountryman.com
Let It Fail
https://www.maxcountryman.com/articles/let-it-fail
86 comments
I agree with your overall sentiment, though this definitely isn't limited to large businesses. Plenty of small businesses are plagued with hero culture as well.
What's really needed are leaders who recognize hero culture for what it is and are willing to move away from it. That's hard to do, in large part because managers benefit from it in the short-term and many will move on before the long-term costs become apparent. Given your previous example: Every manager wants to be the "winner" who gets the job done with 10 people, but what's unfortunate is that many of them will move up to the next level and claim that they would have success even with just 4 "good" people (re: heroes). So their replacement will get 4 people and the cycle will continue.
What's really needed are leaders who recognize hero culture for what it is and are willing to move away from it. That's hard to do, in large part because managers benefit from it in the short-term and many will move on before the long-term costs become apparent. Given your previous example: Every manager wants to be the "winner" who gets the job done with 10 people, but what's unfortunate is that many of them will move up to the next level and claim that they would have success even with just 4 "good" people (re: heroes). So their replacement will get 4 people and the cycle will continue.
Something similar happened in my previous organisation with less than 5 people on the engineering side where I was asked to do a major refactor of the codebase that touched 70% of the files while also adding new features(with changing requirements) at the same time. Though I was working day and night, it took me thrice the time to do it than we initially expected. I was put on PIP after delivering the work(prod deployed) so I left. Then they got 3 engineers from top 1 percentile of industry to work on the same codebase. All this time I was shouting that I need someone to help me in the team but got no one :) . Question mark was put on my performance rather than the management of the team/resources.
The right choice between the "get something done and working" and "your systems should be going down" paths might depend on the situation. Sometimes the right call for the company is to actually have "relative success" despite the downsides if it's better than the downsides of the early failure.
Implicitly, this article implies some communication failures in an organization, where visible failures are used as as attention-getting substitute for what should be healthy communication and prioritization channels.
Implicitly, this article implies some communication failures in an organization, where visible failures are used as as attention-getting substitute for what should be healthy communication and prioritization channels.
One of the first lessons I used to teach new guys in tech support was to work one ticket at a time. Take your time, document….. and just let the phone ring and let SLAs get missed if that is what happens.
Go getter guys would rush because calls we’re waiting, it was hard to break them of the habit of trying to rush and documenting later. but inevitably rushing meant poor work was done.
In the end though you have to do your job right fist. That’s always on you.
Missed calls, ultimately that’s someone else’s staffing choice.
Sure someone will say “Hey what happened you missed a call?!?” but if there were 4 people and 6 calls… there you go. In many orgs if the call(s) wasn’t missed it probably would never get addressed…
Go getter guys would rush because calls we’re waiting, it was hard to break them of the habit of trying to rush and documenting later. but inevitably rushing meant poor work was done.
In the end though you have to do your job right fist. That’s always on you.
Missed calls, ultimately that’s someone else’s staffing choice.
Sure someone will say “Hey what happened you missed a call?!?” but if there were 4 people and 6 calls… there you go. In many orgs if the call(s) wasn’t missed it probably would never get addressed…
As a manager, I actually find people doing "big picture" thinking quite annoying to deal with. What I want you to do is concentrate on the tasks in front of you and do those well. You shouldn't be caring about the total amount of tasks to do, or if we are going to finish the project on time. That is my problem, not yours.
At some point I realised that it's better to have all the issues in the tracker assigned to project managers and never have more than half a dozen on someone at a time because some people just can't seem to handle it.
People with a lot of work assigned to them will report how stressed they are and how they are working too hard. When I ask them if they are working more than 40 hours a week they tell me "no". (We don't allow people to work unapproved overtime)
And then if you unassign all the work off them and just parcel out the issues they work the same amount of time and produce about the same amount of work and yet are not "overworked" to hear them tell it.
At some point I realised that it's better to have all the issues in the tracker assigned to project managers and never have more than half a dozen on someone at a time because some people just can't seem to handle it.
People with a lot of work assigned to them will report how stressed they are and how they are working too hard. When I ask them if they are working more than 40 hours a week they tell me "no". (We don't allow people to work unapproved overtime)
And then if you unassign all the work off them and just parcel out the issues they work the same amount of time and produce about the same amount of work and yet are not "overworked" to hear them tell it.
> As a manager, I actually find people doing "big picture" thinking quite annoying to deal with. What I want you to do is concentrate on the tasks in front of you and do those well. You shouldn't be caring about the total amount of tasks to do, or if we are going to finish the project on time. That is my problem, not yours.
Your attitude is probably sound and productive in itself, but it's going to drive away a lot of top performers and leave you with a predictable but modestly achieving team at best. You may benefit from finding a way to accommodate some of those "big picture" thinkers who show more initiative and who might bring attention to some of your own blind spots and misjudgments.
Your attitude is probably sound and productive in itself, but it's going to drive away a lot of top performers and leave you with a predictable but modestly achieving team at best. You may benefit from finding a way to accommodate some of those "big picture" thinkers who show more initiative and who might bring attention to some of your own blind spots and misjudgments.
A lot of high performers do like to think about the big picture, and they have good ideas. A lot of them become managers, and good managers usually ask for their input. But also, a lot of people on a team like to think about the overall status of a project or a company rather than the task at hand. Many problems are more interesting than the one in front of you. Worse, sometimes contributors like to obsess over org problems as a way of validation. As in, I am only a week behind but the project is over two months late! That can be annoying.
That's... fine? They can't all be Jeff Deans, or John Carmacks. Nor would you want them to be. Promote those that are up the engineering ladder and let the L4's do L4 work. You need L4 work to happen or else the annoying bugs don't get fixed and the small but important pieces of functionality don't get built.
> leave you with a predictable but modestly achieving team at best.
What I'd give for this to be the norm. For any organization past a certain size, having a team that performs predictably is worth it's weight in gold.
What I'd give for this to be the norm. For any organization past a certain size, having a team that performs predictably is worth it's weight in gold.
I don't think the suggestion is that they _never_ do big-picture thinking, only that they concentrate on the current task. The wider view can be addressed in retrospectives.
Early in my career I quickly moved off projects whenever I found myself working for people like you.
As a junior, especially when working for large organisations I frankly didn’t give a shit whether I did what was described as “my job”, I was interested in learning as much as possible, working across multiple teams and areas and maximising the value of my output (as opposed to the alignment between my output and a job description or someone barely more senior than me’s idea of what I should be doing).
Some managers hated this. Others trusted me, treated me as an equal, and let me propose ideas and take on tasks that nobody even knew/thought were possible and deliver massively outsized value. Those are the ones that made my career.
My advice to anyone young and ambitious is that if you find yourself just “concentrating on your tasks” most of the time, get out of there.
As a junior, especially when working for large organisations I frankly didn’t give a shit whether I did what was described as “my job”, I was interested in learning as much as possible, working across multiple teams and areas and maximising the value of my output (as opposed to the alignment between my output and a job description or someone barely more senior than me’s idea of what I should be doing).
Some managers hated this. Others trusted me, treated me as an equal, and let me propose ideas and take on tasks that nobody even knew/thought were possible and deliver massively outsized value. Those are the ones that made my career.
My advice to anyone young and ambitious is that if you find yourself just “concentrating on your tasks” most of the time, get out of there.
Truth is you need both. Some cases call for insulating someone so they can think deeply about one problem. Some require bringing everyone into the fray so you can cross-pollinate ideas. Mis-judge and you get cogs-in-the-machine or status-update-hell syndrome.
True.
Also, of course, the way you treat someone, the kind of tasks you give them, and the style of management and working with them should be tailored to each individual to get the best out of them.
I’m constantly amazed at how many people want to be managed and told what to do, and value “clarity” over freedom.
Also, of course, the way you treat someone, the kind of tasks you give them, and the style of management and working with them should be tailored to each individual to get the best out of them.
I’m constantly amazed at how many people want to be managed and told what to do, and value “clarity” over freedom.
I genuinely think the world (and most larger organizations) need both kinds of people.
[deleted]
Often times, people would walk up to the devs and ask if we could work on this thing. Often times, especially if they were fat cats in the company, we'd happily switch gears to appease. Our manager homie eventually told us like "Look, I'm your manager and I delegate the tasks that have been requested of us. Have whoever comes up to you to talk to me, even if it's [SVP of Engineering guy]." And so we did and it streamlined everything a bunch.
Sounds like you have good manager! Management is there to manage. Sometimes, surprisingly, they actually do!
With respect, this is backwards. This is recipe for burned out and isolated employees that have no buy in or ownership of organizational goals.
>What I want you to do is concentrate on the tasks in front of you and do those well. You shouldn't be caring about the total amount of tasks to do, or if we are going to finish the project on time. That is my problem, not yours.
Most likely you're not a perfect oracle and therefore will not be able to do what you describe here. So you're already set up for failure by attempting to shield the team from "politics" or however you would describe them.
>People with a lot of work assigned to them will report how stressed they are and how they are working too hard.
No they won't. At the point someone is telling you this, they are burned out. In which case you already failed and now you're behind the curve with a burned out and alienated team member.
I suggest you take a step back and evaluate how you view yourself in relation to your other teammates. If you believe you are smarter or better than them then you need to re-evaluate whether you should be in management.
Your job as a manager is to care for your employees without being parochial, giving them as much information as appropriate (which is USUALLY all of the information) while ensuring that they have the tools and environment that fit their individual working style, and mediating between team members to align incentives across the organization.
>What I want you to do is concentrate on the tasks in front of you and do those well. You shouldn't be caring about the total amount of tasks to do, or if we are going to finish the project on time. That is my problem, not yours.
Most likely you're not a perfect oracle and therefore will not be able to do what you describe here. So you're already set up for failure by attempting to shield the team from "politics" or however you would describe them.
>People with a lot of work assigned to them will report how stressed they are and how they are working too hard.
No they won't. At the point someone is telling you this, they are burned out. In which case you already failed and now you're behind the curve with a burned out and alienated team member.
I suggest you take a step back and evaluate how you view yourself in relation to your other teammates. If you believe you are smarter or better than them then you need to re-evaluate whether you should be in management.
Your job as a manager is to care for your employees without being parochial, giving them as much information as appropriate (which is USUALLY all of the information) while ensuring that they have the tools and environment that fit their individual working style, and mediating between team members to align incentives across the organization.
From what you wrote you seem to tend to treat devs as human CPUs and not as intelligent people that might be much more capable than anyone in the management and who are naturally complex problem solvers (no offense, MBA is easier than undergrad and incomparable to computer science or any hard science). You are reducing them to FIFO/priority queue processors without giving them a view of the big picture, likely increasing their stress and sense of futility, pigeonholing them to being single-task focused at all times.
> As a manager, I actually find people doing "big picture" thinking quite annoying to deal with
That's a bold statement. You've made your job easier, at the cost of creating a culture of "not my job". You assume you can handle all the big picture yourself. That way lies micromanagement.
Maybe your team requires that right now. Only you know. But you should also ask yourself why you sound like your team is annoying you. In the quote above, in "to hear them tell it", "some people just can't handle it".
That's a bold statement. You've made your job easier, at the cost of creating a culture of "not my job". You assume you can handle all the big picture yourself. That way lies micromanagement.
Maybe your team requires that right now. Only you know. But you should also ask yourself why you sound like your team is annoying you. In the quote above, in "to hear them tell it", "some people just can't handle it".
I wouldn't try and argue with someone who retorts to stress by asking you whether you work more than 40 hours a week, which is like telling a foie gras goose that actually it spends less time a day eating than most other poultry.
A while ago, I would have agreed. I've long since learned that the reason our industry has the management problems it has because we don't prepare people for leadership. At all. We just throw them in the grinder and hope it works out.
This means there are a lot of people who see stress and work that way because they don't know any better. A lot of people who think it's "manager vs. team". I can't cure that by myself, but as long as I can offer nudges to rethink that, I will.
Like almost every systemic problem, it only gets fixed if a large number of us keeps trying to fix it. (That said, I certainly get being tired of trying to :)
This means there are a lot of people who see stress and work that way because they don't know any better. A lot of people who think it's "manager vs. team". I can't cure that by myself, but as long as I can offer nudges to rethink that, I will.
Like almost every systemic problem, it only gets fixed if a large number of us keeps trying to fix it. (That said, I certainly get being tired of trying to :)
Especially when they’ve made it clear that admitting to more than 40 hours per week is an official problem!
There are several failure modes I see from lack of big picture thinking:
- A system is left running for years even though we no longer need it as a business. Millions of dollars wasted because no one had a ticket for "think about whether we still need system X" so no one thought about it. (This one happens a LOT, oh my lord.)
- Two teams solving the same problem in different ways. They each hit their goals and people get promoted and so forth. But the business ends up silently paying double, and we all have to deal we extra cognitive overhead from the redundancy, which slows us down.
- Excessively manual processes. People clock in and fix support issues all day instead of re-engineering the thing to be more automated and self-service. But again, everyone's doing their tasks as specified, promotions all around.
- A system is left running for years even though we no longer need it as a business. Millions of dollars wasted because no one had a ticket for "think about whether we still need system X" so no one thought about it. (This one happens a LOT, oh my lord.)
- Two teams solving the same problem in different ways. They each hit their goals and people get promoted and so forth. But the business ends up silently paying double, and we all have to deal we extra cognitive overhead from the redundancy, which slows us down.
- Excessively manual processes. People clock in and fix support issues all day instead of re-engineering the thing to be more automated and self-service. But again, everyone's doing their tasks as specified, promotions all around.
As a support person I see this happen often when a new feature is implemented to an existing product, typically something a customer requests.
The feature works, it passes all test we throw at it, and then when out in the field the product breaks down in unexpected ways because the developers/product managers/big thinkers use the product doesn't match how the customer uses the product. Functionally sound by itself but fails as a system.
The issues are generally obvious from a systematic view, but when each person is face first at a different part of the elephant they'll all say their piece is working.
The feature works, it passes all test we throw at it, and then when out in the field the product breaks down in unexpected ways because the developers/product managers/big thinkers use the product doesn't match how the customer uses the product. Functionally sound by itself but fails as a system.
The issues are generally obvious from a systematic view, but when each person is face first at a different part of the elephant they'll all say their piece is working.
> That is my problem, not yours.
It has become theirs.
Because if it's a problem in the first place, and they start to notice it, and care enough to voice up about it, it means it's become frequent enough that you seem not to have done/said something about it.
Their reaction is not about you. It's about the environment in which they understand they operate.
Their options are: care about it, not care about it, leave for a better environment.
It has become theirs.
Because if it's a problem in the first place, and they start to notice it, and care enough to voice up about it, it means it's become frequent enough that you seem not to have done/said something about it.
Their reaction is not about you. It's about the environment in which they understand they operate.
Their options are: care about it, not care about it, leave for a better environment.
I've seen this attitude so many times and it has never ended well.
Odds are that the people who do the work have an order of magnitude better understanding of the bigger picture than someone whose role is to portion out work in small bites.
Odds are that the people who do the work have an order of magnitude better understanding of the bigger picture than someone whose role is to portion out work in small bites.
Odds are that the manager engages in turf building and fiefdom defense.
I've heard of turf building but what is fiefdom defense? Google search isn't really turning up business fallacies.
> That is my problem, not yours.
If this is your real idea, I wouldn't want to work with someone who works with this logic. Working with someone who takes most of the responsibilities may not be very good for development.
If this is your real idea, I wouldn't want to work with someone who works with this logic. Working with someone who takes most of the responsibilities may not be very good for development.
Hu? "total amount of tasks to do, or if we are going to finish the project on time" is exactly the boundary that should be upheld between contributors and their managers.
One of the most important tasks of a manager is to lead, not just to delegate. by 'leading', one of the core is about forming consensus. my question is, how could you annoying by folks doing 'big picture' thinking at the stage of forming consensus?
As a big picture thinker, sometimes big picture thinking is an excuse to jerk people around. There's not just one big picture, there are tons of possibilities at any given moment. Unless it's a repeat process w defined goals, the view will depend as much on your mood and random thoughts as it does on the actual stuff.
Ugh, those human-shaped productivity units can be so annoying and inconvenient, right?
And slow. Don't forget slow!
Soo basically your people are cogs in the factory, and you’re the bossman.
Seems like a place top notch performance
Seems like a place top notch performance
> As a manager, I actually find people doing "big picture" thinking quite annoying to deal with
People aren't cogs in a machine. Your attitude is dehumanizing. I'm in a position where I also want people to concentrate on their tasks, but way more often than not I have something pointed out by a direct report that I missed -- and because I stow my ego at the door, I accept and appreciate that help, and make sure they're commended for it by the larger organization. They wouldn't be able to do that if they didn't see the big picture.
A peer of mine has a great quote from a movie whose name I can't recall, that goes something like this:
"Sometimes, you treat people like mushrooms. You keep 'em in the dark and feed 'em shit."
Seems apropos.
Edit: spelling
People aren't cogs in a machine. Your attitude is dehumanizing. I'm in a position where I also want people to concentrate on their tasks, but way more often than not I have something pointed out by a direct report that I missed -- and because I stow my ego at the door, I accept and appreciate that help, and make sure they're commended for it by the larger organization. They wouldn't be able to do that if they didn't see the big picture.
A peer of mine has a great quote from a movie whose name I can't recall, that goes something like this:
"Sometimes, you treat people like mushrooms. You keep 'em in the dark and feed 'em shit."
Seems apropos.
Edit: spelling
I am often surprised how the big picture manifests itself in nitty gritty details.
I want all teams to know the big picture and you must trust their expertise and experience.
This is tough to learn to let go but that's why you hired experts in the first place.
I want all teams to know the big picture and you must trust their expertise and experience.
This is tough to learn to let go but that's why you hired experts in the first place.
you know what is more stressful than having too much work? not understanding the work you do have
This. You are only human. The business has a choice; drop work from the queue or increase the worker count (or scale back expectations for work that cannot be parallelized; obligatory Mythical Man Month reference).
If you enable a system to operate successfully to great detriment of its components, it’s still operating and no action will be taken. Failure is a resourcing or scheduling problem, not an individual failing. Failure is a symptom of system defects(s) requiring system improvement.
Great post. Stay healthy.
If you enable a system to operate successfully to great detriment of its components, it’s still operating and no action will be taken. Failure is a resourcing or scheduling problem, not an individual failing. Failure is a symptom of system defects(s) requiring system improvement.
Great post. Stay healthy.
yup, philosophy for life:
Failure is acceptable and if you learn from it even encouraged
There is no point stressing about things you have no control over
You can only do what you can only do, if you can't do it then find someone that can.
Failure is acceptable and if you learn from it even encouraged
There is no point stressing about things you have no control over
You can only do what you can only do, if you can't do it then find someone that can.
"This too shall pass" we would tell each other. You're not getting paid to stress and age like [some animal that ages quickly].
My favorite battle cry of "Fail fast" was from this Microsoft head of something engineering behind Windows Vista.
And how.
My favorite battle cry of "Fail fast" was from this Microsoft head of something engineering behind Windows Vista.
And how.
Mayflies can survive in their immature form for years but only live for 1-2 days as adults: https://en.wikipedia.org/wiki/Mayfly
Replacing one system (typically referred to as legacy - almost in a pejorative way) with another new system can be a big improvement.
Or it can be a complete waste of time and money.
It all depends on the actual quality of the old system, and the actual quality of the new system.
The most common way this manifests is with technology changes. We must rewrite in a modern language like c#. We must switch our JavaScript framework to React. From my experience 90% of these transitions fail precisely because the legacy system is working fine, and _doesn't_ fail. The new system is always 2 years behind, so is never adopted.
Good architecture trumps new language. And there are a lot of legacy systems with good architecture.
There are also plenty of systems with bad architecture. Ones with too much tech debt. Ones that will fail. And these need to be rebuilt, hopefully with better architecture.
So how does a non-technical person tell the difference (hint: they can't). So they rely on their tech team to tell them. But tech teams want to play with new toys all the time so they're not easily trusted. Changing has huge consequences (usability, training, deployment etc) all of which the tech guys don't care about.
The sweet spot is a well architected legacy system, managed by people who both understand tech, and understand the needs of the business,and importantly, understand the architecture so can limit the tech debt created.
Such systems exist, but it's rare. And ironically all too often management doesn't even know they have it, so some upstart convinces them to "rewrite in React".
Or it can be a complete waste of time and money.
It all depends on the actual quality of the old system, and the actual quality of the new system.
The most common way this manifests is with technology changes. We must rewrite in a modern language like c#. We must switch our JavaScript framework to React. From my experience 90% of these transitions fail precisely because the legacy system is working fine, and _doesn't_ fail. The new system is always 2 years behind, so is never adopted.
Good architecture trumps new language. And there are a lot of legacy systems with good architecture.
There are also plenty of systems with bad architecture. Ones with too much tech debt. Ones that will fail. And these need to be rebuilt, hopefully with better architecture.
So how does a non-technical person tell the difference (hint: they can't). So they rely on their tech team to tell them. But tech teams want to play with new toys all the time so they're not easily trusted. Changing has huge consequences (usability, training, deployment etc) all of which the tech guys don't care about.
The sweet spot is a well architected legacy system, managed by people who both understand tech, and understand the needs of the business,and importantly, understand the architecture so can limit the tech debt created.
Such systems exist, but it's rare. And ironically all too often management doesn't even know they have it, so some upstart convinces them to "rewrite in React".
One of the big issues with legacy systems is the hidden edge cases that everyone that uses said legacy system doesn't talk about. I call this the 'silent specification'. If you look at the real specification of the legacy system and try to make a modern system with it, the modern system won't work for the users needs. The users attempt to implement the silent specification on the new system and workflows break down, or huge amount of manual mental work need done. So to use the new system it involves a huge amount of retraining to the point you realize you designed the wrong new system for what the user/workflow/job requires.
Agree, but there is also one more point, always allow people that created legacy system to work on new one.
In one of projects I worked there was legacy system that had enough issues causes by architecture, that 95% of workforce was assigned into fixing new and new bugs/regressions.
So business decided to rewrite that system, but mistake they made was to create complete new team for that task. The new team didn't know why previous solution failed, as this was on first sight very simple system, and not knowing all of the hidden complexity made similar mistakes that caused previous system to fail.
And in that way we ended up brand new legacy system that also failed in similar ways.
Fortunately I convinced them to create third version with the same team as this second failed system and it all looked well until.. some well known consulting company was hired and they decided to rewrite everything on react, and 90% of people just resigned from work.
In one of projects I worked there was legacy system that had enough issues causes by architecture, that 95% of workforce was assigned into fixing new and new bugs/regressions.
So business decided to rewrite that system, but mistake they made was to create complete new team for that task. The new team didn't know why previous solution failed, as this was on first sight very simple system, and not knowing all of the hidden complexity made similar mistakes that caused previous system to fail.
And in that way we ended up brand new legacy system that also failed in similar ways.
Fortunately I convinced them to create third version with the same team as this second failed system and it all looked well until.. some well known consulting company was hired and they decided to rewrite everything on react, and 90% of people just resigned from work.
> So business decided to rewrite that system, but mistake they made was to create complete new team for that task. The new team didn't know why previous solution failed, as this was on first sight very simple system, and not knowing all of the hidden complexity made similar mistakes that caused previous system to fail.
The most nightmarish company I ever worked for did this, but took it even further: The two teams (old and new) were set up as competing with each other to see who could create the better solution. The team that lost (for some unclear definition of losing) would often see several people laid off and the remaining members assigned to lower seniority positions on the winning team.
It created chaos every time the CEO set up competitions like this. Few things create infighting and information hoarding quite like setting two teams against each other with the threat of losing their jobs if they let the other team succeed.
The most nightmarish company I ever worked for did this, but took it even further: The two teams (old and new) were set up as competing with each other to see who could create the better solution. The team that lost (for some unclear definition of losing) would often see several people laid off and the remaining members assigned to lower seniority positions on the winning team.
It created chaos every time the CEO set up competitions like this. Few things create infighting and information hoarding quite like setting two teams against each other with the threat of losing their jobs if they let the other team succeed.
"But they are needed on the old system to fix bugs! The new team wouldn't know how to solve these" -- reasons the fictional manager.
>Consider that if our hero disappears on a months-long backpacking adventure in Europe and without her to save the day our velocity slows to a crawl, we've stumbled upon a systemic reliance that reveals deeper fragility.
>As such generally we want to discourage a culture of heroism and seek to build systems and processes that don't require it.
The economy runs on heroism. If you don't believe me, see how central planning went in the last century
I have seen heroes quit because of decreased comp leading to huge revenue loss. I have also seen extremely expensive but predictable (often in that they don't deliver) "systems and processes"
This post speaks to cushy managerialism
>As such generally we want to discourage a culture of heroism and seek to build systems and processes that don't require it.
The economy runs on heroism. If you don't believe me, see how central planning went in the last century
I have seen heroes quit because of decreased comp leading to huge revenue loss. I have also seen extremely expensive but predictable (often in that they don't deliver) "systems and processes"
This post speaks to cushy managerialism
> The economy runs on heroism. If you don't believe me, see how central planning went in the last century
Ok...when the US and Europe were mired in depression in the 1930s, the Soviet Union was going through breakneck growth, to where US and European workers were going to the Soviet Union in droves to make money. Then virtually all of continental Europe invaded the Soviet Union and were beaten back to the Elbe River. Then it launched satellites, men into space, and other innovations.
Of course several decades into this growth, when Khrushchev decided to cut capital spending, that is when the trouble started - the same with Ulbricht.
In the people's republic of China, decades of central planning and five year plans have led to it becoming the second largest, and by some measures the largest economy in the world. The policies swing back and forth, planning was very centralized for decades, then Deng Xiaoping did some decentralization, but as pretty much every western media source acknowledges, Xi has been centralizing more.
Also there is an odd mythology in places like the US. A mythology where transistors did not take off due to the central planning of the US government and armed forces, who allowed centralized monopolies like Bell which invented the transistor, and then funded firms like Fairchild with large orders, before transistors were commercially viable for consumers and businesses. In this mythology the current stock market is mot going up or down due to heroic innovations, but due to the announcements of the federal reserve chairman.
Ok...when the US and Europe were mired in depression in the 1930s, the Soviet Union was going through breakneck growth, to where US and European workers were going to the Soviet Union in droves to make money. Then virtually all of continental Europe invaded the Soviet Union and were beaten back to the Elbe River. Then it launched satellites, men into space, and other innovations.
Of course several decades into this growth, when Khrushchev decided to cut capital spending, that is when the trouble started - the same with Ulbricht.
In the people's republic of China, decades of central planning and five year plans have led to it becoming the second largest, and by some measures the largest economy in the world. The policies swing back and forth, planning was very centralized for decades, then Deng Xiaoping did some decentralization, but as pretty much every western media source acknowledges, Xi has been centralizing more.
Also there is an odd mythology in places like the US. A mythology where transistors did not take off due to the central planning of the US government and armed forces, who allowed centralized monopolies like Bell which invented the transistor, and then funded firms like Fairchild with large orders, before transistors were commercially viable for consumers and businesses. In this mythology the current stock market is mot going up or down due to heroic innovations, but due to the announcements of the federal reserve chairman.
> the Soviet Union was going through breakneck growth
quite literally infact
quite literally infact
What was happening in the American south at the time, where senators were holding up lynching bill?
The Soviet Union was mired in famine covered up by the incompetent government in the 30s. This was the Holodomor which killed millions and Ukrainian people still remember it well, how Stalin tried to prevent journalists from seeing the true horror of his leadership
What do you think the Dust Bowl in the US was?
Were there people resorting to cannibalism in the US? Millions died in Ukraine due to communist mismanagement. Lenin did the same thing before Stalin did.
What's the alternative to process and knowledge sharing then? If you allow heroism to run rampant in your company you basically guarantee it will die just because a single employee quits, because all areas of the company are rife with single points of failure.
Pay the heroes what they’re worth. Imagine if the Bulls let Michael Jordan join another team because they wanted to discourage heroism.
No amount of pay can stop people from getting hit by a bus or leaving for other reasons though. Michael Jordan is an interesting example because he eventually did stop playing for the Bulls (because he retired) and then it took the Bulls six years before they made the playoffs again.
More in general: everyone thinks they're the "hero" in the situation and that they're underappreciated, but for the company the team is (and should be) more important than the individual. Imagine if you got laid off because the "hero" in (say) the sales team died and now the company is no longer profitable, because he/she was the only one bringing in any orders. Would you consider that a well-run company?
More in general: everyone thinks they're the "hero" in the situation and that they're underappreciated, but for the company the team is (and should be) more important than the individual. Imagine if you got laid off because the "hero" in (say) the sales team died and now the company is no longer profitable, because he/she was the only one bringing in any orders. Would you consider that a well-run company?
If you discourage heroism - worse, if you announce that you discourage heroism, the average employee's motivation is going to fall drastically. Everyone will do the bare minimum. Exotic forms of corruption like thrift may even emerge
This is exactly what happens in the wider economy when you discourage heroism in society
Humans naturally want to see the grass greener. If you know all you'll ever be is just a number - worse, if you know you will actually be disapproved of because you tried harder or can do better than average, then everyone (but especially gifted individuals) will perform worse and worse until the company breaks
What this post synthesizes is the managerial's class desire to become the "heroes" at the expense of lump-sumed menial labor performed by faceless employees. It's a parasitical philosophy on work
Imagine you own a company (usually involves years' worth of sweat and tears to achieve some sort of success/profitability). Imagine you hear a manager say "let it fail". I hope the feeling that follows makes it clear that the manager is a sponger
This is exactly what happens in the wider economy when you discourage heroism in society
Humans naturally want to see the grass greener. If you know all you'll ever be is just a number - worse, if you know you will actually be disapproved of because you tried harder or can do better than average, then everyone (but especially gifted individuals) will perform worse and worse until the company breaks
What this post synthesizes is the managerial's class desire to become the "heroes" at the expense of lump-sumed menial labor performed by faceless employees. It's a parasitical philosophy on work
Imagine you own a company (usually involves years' worth of sweat and tears to achieve some sort of success/profitability). Imagine you hear a manager say "let it fail". I hope the feeling that follows makes it clear that the manager is a sponger
If I own a company where (unbeknownst to me) some function has been hopelessly understaffed to the point they can no longer successfully complete all their tasks, a good thing that could happen is that eventually they do fail at their task and the subsequent investigation into why that happened reveals that they are understaffed and overworked. We can then either allocate more resources or reduce their workload so their tasks become more sustainable. The best way to fix it would be to have good enough communication at all levels that there are no such situations in the first place, but humans are imperfect and mistakes happen.
The last thing I would want is for some "heroic" employee to paper over the gaps until they eventually burn out or leave, after which the company will have a huge problem. All the domain knowledge has been concentrating in that one employee and now that they are gone we have lost that knowledge and will need to rebuild it, probably at great cost if it can be done at all. Like you say, if I built my own company with many years of sweat and tears then I am don't want to let easily preventable issues to have such impact.
As to the first few paragraphs of your post: there are many ways to make employees feel appreciated without also making them into a single point of failure for the entire company.
The last thing I would want is for some "heroic" employee to paper over the gaps until they eventually burn out or leave, after which the company will have a huge problem. All the domain knowledge has been concentrating in that one employee and now that they are gone we have lost that knowledge and will need to rebuild it, probably at great cost if it can be done at all. Like you say, if I built my own company with many years of sweat and tears then I am don't want to let easily preventable issues to have such impact.
As to the first few paragraphs of your post: there are many ways to make employees feel appreciated without also making them into a single point of failure for the entire company.
Actually, you are right. In an ideal world, managers wouldn't need to resort to letting things fail to highlight an area being understaffed
Likewise, in an ideal world, heroes would be compensated according to their performance
But we don't live in an ideal world, so your point is valid
Likewise, in an ideal world, heroes would be compensated according to their performance
But we don't live in an ideal world, so your point is valid
> Michael Jordan is an interesting example because he eventually did stop playing for the Bulls (because he retired) and then it took the Bulls six years before they made the playoffs again.
I don’t see how this is a counterpoint. 100/100 NBA fans, players, and executives would take paying MJ and winning six in a row if the trade off was not making the playoffs for six years after. Are you saying it would have been better for the Bulls to not pay MJ, not win any championships, but consistently make the playoffs for 12 years instead?
I don’t see how this is a counterpoint. 100/100 NBA fans, players, and executives would take paying MJ and winning six in a row if the trade off was not making the playoffs for six years after. Are you saying it would have been better for the Bulls to not pay MJ, not win any championships, but consistently make the playoffs for 12 years instead?
I disagree. I have worked through exactly this proposition and I just left. Why would anyone that respects themselves work through a project that is set up to fail? If upper management cannot make up their internal politics, I don't want to be someone's pawn to be sacrificed for the greater good. After all, the right decision could be made from the beginning.
To me, this article was less about letting something fail and more about letting people learn for themselves. And I agree: It’s very hard to explain a solution to people when they haven’t fully understood the pain points you’re trying to solve and/or avoid.
Its just a lack of respect on the part of management for engineering. The engineers clearly stated that the new system was necessary. The managers just refused to respect their expertise or the integrity of the technology.
The missed lesson here is that that company seemed to be a mismanaged nightmare.
Lots of orgs are, and they can be a fine place to cut your teeth and learn some things and build a positive reputation with colleagues, but ideally you learn to recognize when a shitshow is a shitshow so you don’t normalize it.
Hopefully Max learned that failing systems are sometimes better than flailing teams, but that failing systems shouldn’t be the norm in the first place. Other people (founders? execs? managers?) had done very poor work there and what he did was find a productive way to deal with it.
Lots of orgs are, and they can be a fine place to cut your teeth and learn some things and build a positive reputation with colleagues, but ideally you learn to recognize when a shitshow is a shitshow so you don’t normalize it.
Hopefully Max learned that failing systems are sometimes better than flailing teams, but that failing systems shouldn’t be the norm in the first place. Other people (founders? execs? managers?) had done very poor work there and what he did was find a productive way to deal with it.
For most of the article I assumed that the “it” that they were letting fail was the project itself, in order to force organisational change, not the incumbent software system.
+1, the writing could certainly be improved there.
What editor are you using that uses angled quotes on HN plain text comments??
I think I posted that comment from iOS Safari, they iOS keypad does that.
🄸🄼🄿🄾🅂🅂🄸🄱🄻🄴
Highly recommend reading The Phoenix Project. Much longer winded than the post, but drives home similar, and a number of other, valuable lessons along the way in a memorable story-setting.
The biggest point of failure actually has nothing to do with the software itself - it’s whether enough money is coming in the door or not. The most backwards and tech debt riddled system will survive if there is enough customer demand and relationships. Meanwhile a perfectly working software project will die or go dormant if the maintainers aren’t getting paid.
Major refactoring of a platform is almost never the right answer, wholesale replacing battle tested code with theoretically better code satisfies only engineering teams and kills businesses.
Sure just let your competitors do that hard work instead.
A critical production piece of code can be replaced safely if a comprehensive test suite can ensure feature parity. It’s a lot of work but if people rely on it may as well test anyways. The tests will survive the upgrade.
A critical production piece of code can be replaced safely if a comprehensive test suite can ensure feature parity. It’s a lot of work but if people rely on it may as well test anyways. The tests will survive the upgrade.
I sure hope this isn't something in healthcare or transportation or aerospace or ... any industry that matters at all ...
This is classic HN pedantry. You really think these people would allow people to die to prove the point in the article? That they couldn't exercise sensible discretion on when failure might be the best course of action?
You mean like airplanes where they expect them to fail and so every vehicle has a nearly indestructible telemetry box with a homing beacon?
Failure is not the problem. Failing the same way and doing nothing about it is the problem.
Failure is not the problem. Failing the same way and doing nothing about it is the problem.
Failing in predictable ways is always a problem. Even if it's a novel way of failing. Those boxes are there as last resort, not as an engineering strategy.
Having a last resort is an engineering strategy (and not a very popular one outside of safety critical industries).
I've seen plenty of projects that choose not to design or think about handling "unknown unknown" failure vectors because YAGNI
I've seen plenty of projects that choose not to design or think about handling "unknown unknown" failure vectors because YAGNI
What does that have to do with anything?
I don't want swiss cheese code written by an under-resourced operation in my airplane. If anything, the more critical the application, the more this message applies.
I don't want swiss cheese code written by an under-resourced operation in my airplane. If anything, the more critical the application, the more this message applies.
I suspect if people were going to or actually died the author would have mentioned it.
Did you even read the article?
It was a managed failure, nothing major.
I agree with this totally.
I've seen this happen to many managers at FAANG. You're promised 10 people for a project next year, you get 4. So you cut, manage, optimize, engineer, and hustle to get something done and working. Management above you sees this as relative success, and validates that they were right not to give you more people. Disillusionment sets in, the team quits or transfers, you get bad reviews.
The next year, you're fired or transferred, and the new guy comes in, he gets 10 people, saves the day and gets high praise. He gets good reviews and maybe a promotion. You look back with resentment. The problem wouldn't have been there if they had given you the resources you said you need. If you had 10 people, you also could have saved the day.
This is the sickness of large organizations and non-technical management. I have rarely seen organizations not run by owners spend the $1 on prevention today, they almost always elect for the $10 for a fix later.
If you need 10 people to do a job, and you get 4, the job should fail. Your systems should be going down. Don't sabotage, but upper management needs to see, not hear about, failure. Update deliverable timelines form 6 months to 18 months or just cancel new projects all together, change your SLA's from 99.9% to 90%. Change your ticket response times from 30 minutes to 12 hours or best effort business hours.
You'll either get the resources, get attention for reprioritization, or learn that your job isn't a real priority.