Let It Fail
maxcountryman.com
maxcountryman.com
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.
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.
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.
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…
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.
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.
My favorite battle cry of "Fail fast" was from this Microsoft head of something engineering behind Windows Vista.
And how.
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.
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.
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.
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".
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 :)
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.
- 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.
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.
Seems like a place top notch performance
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.
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.
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.
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.
>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.
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 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.
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".
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.
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.
>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
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?
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
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.
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
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?
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.
quite literally infact
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.
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 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.
Failure is not the problem. Failing the same way and doing nothing about it is the problem.
I've seen plenty of projects that choose not to design or think about handling "unknown unknown" failure vectors because YAGNI