There's a little bit of insight from lean manufacturing related to this. Manufacturer plant managers tend to shoot for production loads around 85-90%. Anything higher just means stuff starts piling up, which causes delays and is actually bad for business. Anything over 100% means work isn't getting done.
Sounds familiar? That explains every software project that went over time and budget ever. You can apply the same logic to product management. If you are planning for more work to be done than can be done, you are wasting time and money. Ask for less; you'll get more better and sooner. Applying Brooke's law to this means that adding people to the team won't address this even.
I regularly see companies make both mistakes and then they fail to deliver, everybody is stressed out, and the team under performs. It doesn't work. Prioritize work correctly and make sure everybody focuses on only the top priorities. It doesn't matter if you are using scrum, kanban, or waterfall. Just make sure your team is working on the smallest number of things at any time possible without any of them having to idle or wait.
I'm a big fan of Don Reinertsen's work on lean 2.0 where he talks about this and more and uses some sound economical reasoning to back all this up.
Reminds me of the study I read about how placing a barrier in the form of a pole in front of an emergency exit drastically improved how many managed to get out during an emergency (simulated in the study).
By introducing a barrier people are forced to reduce congestion, which avoids people trying to exit the door at the same time clogging it up.
>Prioritize work correctly and make sure everybody focuses on only the top priorities. It doesn't matter if you are using scrum, kanban, or waterfall.
IME it does matter. Kanban is really about focusing on priority and throughput with no frills. Kanban is effective, can be explained in ten minutes, and just works.
Most of Kanban really ties in well with Demings ideas, which I think is why it works.
Scrum leads to a lot of meetings, ceremony and more "managers" - scrum masters as well as POs, and any other middle management your company had before picking scrum.
And when Scrum inevitably fails, the cultists yell that it was implemented wrong, that we never did real Scrum, that if Scrum was done correctly we would succeed. Kind of like "communism was never tried".
But it was tried, many times, by many teams, and sometimes despite the system some project somewhere might have thrived.
It's a system that only works in an idealized world, with idealized people, that I surmise at this point never existed.
I'm not disagreeing too much here but people get to hung up, dogmatic, and emotional on processes to have meaningful discussions about this at this point. You can do both Scrum and Kanban and apply the same principals. The underlying principles are actually more important than the process.
Kanban is not an excuse to skip planning and having a TODO list full of high priority items is a classic mistake with it. When everything is important, nothing really is. With Scrum the classic mistake is over committing your team based on a notion that managers wants to overload the team because they think that produces results.
I treat both processes exactly the same when I put my product manager hat on (I'm also CTO, and a developer): regular planning activity to cherry pick the backlog and populate the TODO column. Pruning unimportant work from the TODO list. Making sure work is prioritized correctly. Scrum light, Kanban, Vaguely Agile, whatever labels you want to put on it works for me. I can scale up or down the scrum ceremonial stuff as needed/demanded.
I don’t think so. Pareto principle is based on the idea that 20% of the effort will get you 80% of the gains. This article states that at any point in time you should give 85% of the effort in order to maximize output in the long term. Otherwise, you risk burning out if you give 100%, and then your output drops to zero.
Not just spare capacity for emergencies. Think about how many times an engineer came up with a good idea how to make some part of the process smoother, faster, less error-prone.
It's usually in some phase of the project where there's not too much to do or deliver. But these small gains are necessary for everything to work well then the pressure is on a month or two later.
You don't get this if you're always at capacity and have no time to think.
Overstating problems/blockers, overestimating stories and overselling your work should be in any capable slackers toolkit to enforce work life balance and proper pacing on the "client" (read: employee) side.
One should also teach those skills to colleagues to deconstruct high performance (stress) environments.
I once had a manager who would literally "sneak up" on people: He would make cartoonish sneaking gestures while sneaking up behind someones chair! He criticized anything not purely work related he could see on screens. When I had worked enough and wanted to rest, my solution was to literally scroll through source code while going somewhere else in my head.
> The second type is “failure-avoiding” perfectionists: people who are consistently anxious that their work is not sufficient or adequate, who fear losing the esteem of others if they fail to attain perfection
Didn't know about it. I guess I'm somehow a perfectionist when I work with people I respect or on projects I find valuable. It's tiring though.
If you are building bf a company for the long term, this is the right mindset. If you push people hard all the time, you are optimizing for short term gains but risking long term losses. People will burn out and quit. Finding new people, training them, and getting them to perform costs a lot of money.
I have declined a few interviews from companies who claimed "this is a great place to work, because all our engineers give their 110% in everything they do."
Big red flag. I am not prepared to give 110% to anyone's who's not me or my loved ones, sorry. And the amount I expect to receive in exchange, monetary or otherwise, increases quadratically as we reach 100%.
If your engineers give more than 75% effort on average, they're lying to you, you're hopelessly naive, or you're a slave driver.
110% is code for "we are broke/greedy a-holes so we can't hire anyone, please instead magically produce more for us - management what's that, isn't it called nagging employees?"
Avoiding burnout and optimising for long-term performance is one side of this coin.
Even if you pretend that your team can sustain 100% effort in the long term, and are willing to disregard the effects of working that way on their lives, there is no such thing as 110% effort, so a steady state of 100% effort means you don't have the spare capacity to push hard on specific short-term goals when there is a need for it. Or, put differently, you have a much more limited ability to react quickly to sudden shifts in the market.
There is also a lower threshold over which no permanent injury occurs (yet) but which makes workers borrow upon finite reserves of endurance which eventually (soon) need to be replenished with interest. So if you even it out over time workers are actually less productive. This is known in the gaming industry as the crunch mode, and it's what I would consider "over 100%". Permanent damage occurs if you accumulate too much interest. Both thresholds vary per individual - known as stress resistance. IMO, any mention of it as a quality in interview is a big no-no.
To be fair there are diminishing returns to additional hires, typically hiring one additional developer produces maximum 20% additional throughput, often lower after onboarding/hiring too green. You might have to double or triple team size to get 20-30% increase.
So I see the temptation to "get more done with less" although the reality is you actually drop throughput in the long term.
Being sarcastic is my fault, but understanding the opposite of what the article intends is your fault. I was talking about hiring to increase slack, not to increase throughput.
None of these insights make it to the professional managerial class unless they reenforce current behaviour. See also the article on why layoffs are self destructive.
How did it happen that the vast majority of “professional managers” don’t read anything about how to be good managers, and basically have no qualifications other than “well, somebody promoted me to management before, probably for political reasons, and I have this authoritative sounding voice..”
People, as a collective, fail to learn from research or history and like to use their authority and charisma as a stand-in for logic and proof.
It isn't just the managers doing this. Anyone who isn't in a position of authority but has knowledge of the state-of-the-art, research on it, etc. can tell when someone in that position is pushing their ideals over actually having done research or doing logic beyond a bunch of unquantifiable 'what if' arguments. It takes 5 minutes of online research to dismantle their arguments. But it still happens regardless, even in CS and SD where myths are pushed as absolute truths.
My favorite myth is the one that I hear surprisingly often, from educated and intelligent people. I hear it, because I ask them why they bias for only young people; even in senior management, architectural, and mentoring roles.
They explain that young folks can do the impossible, because they haven't been told that it's impossible. It's a really compelling myth, reinforced by founders of successful unicorns, sharing it as their "secret sauce," as opposed to obsessive work, intelligence, and an enormous dollop of good luck and timing.
I call it the "Don't Look Down" Fallacy.
When Wile E. Coyote runs off the edge of a cliff, he stays up, until he looks down.
If you don't allow anyone into the team that yells "Look down!", then you can fly.
Eh, I think you’re reading into it too much. The reality is that organizations accrue a set of both tested and untested beliefs. A lot of untested beliefs (i.e. someone told me X will turn out badly so I will just avoid doing X) are useful heuristics to avoid relearning expensive lessons, but some untested beliefs are just wrong. Circumstances have changed or they were never right in the first place and need to be tested again. New people (and especially young people, but not necessarily) are good at doing that — sometimes deliberately and sometimes by accident.
Absolutely. I didn't mention people that tell you to stay away from the edge.
In many cases, timidity (often a reaction to past trauma) can be debilitating.
I remember when I was interviewing at startups, and Every. Single. One. -Every one, described themselves as "unicorns."
The harsh reality is that, for every unicorn, prancing around the tech industry, there's a charnel pit, filled with the corpses of 10,000 goats and jackasses, with horns glued to their foreheads.
Not all timidity is bad, and, sometimes, ignoring warnings can be quite fatal.
Probably the same reasons that the vast majority of software engineers don’t read anything about how to be good engineers, the majority of welders don’t read anything about welding, the majority of baristas don’t read anything about coffee making, and the majority of people working in fields with continuing education requirements hit the legal minimum on the nose.
Plenty of people will learn only that which they perceive to be required and no more. People managers don’t seem to be an outlier here.
My take on this is that nobody sees themself as being responsible for developing or cultivating a "manager" as such. Company culture is usually something like "we build widgets, not managers. Let's focus on making everyone the best widget builder possible." Take my field as an example. The executive public defender absolutely does manage managers: her direct reports are supervising attorneys or bureau chiefs or whatever. But she sees her job as managing public defenders.
For that reason, training for public defender managers is usually legal training and subject-matter-specific leadership training. For example, we get a lot of training time on how to support lawyers through burnout. It is almost unheard of that we would get training on abstract or generalist management practices. Executives see it as off-mission and managers think it's a waste of time.
This problem is exacerbated by being a correct strategy at a certain (small) organizational scale, but the paradigm falls out of alignment as the organization grows. It's hard to build an intentional culture of management in an already-existing organization.
One thing that's been eye opening for me as I've gone up the levels is how much different the work styles are between IC and Leadership. The divide gets even bigger at larger companies.
* ICs need time to think deeply. They're tasked with getting all of the details correct. Details take a lot of time, mental load, and effort. They're exhausting in the moment. It's hard to do "just one more task" after you've already worked deeply all day.
* Leaders are tasked with shaping direction of teams. They spend a lot of time reviewing and guiding "the details", but generally can't get into the weeds. They carry on-going mental burden of _everything_ that's important to the company, but can generally delegate the details to other people. Since they don't spend all day dealing with the details, it doesn't feel painful for them to "tackle a few more things".
It's kind of like the tortoise and hare.. ICs sprint, sprint, sprint. Leaders walk. They probably cover the same ground mentally, but most people are much better equipped to walk 10k miles per day than sprint 10k, 100m at a time.
It's incredibly hard to overcome that daily lived experience. Most leaders are going to be at least 5+ years separated from the daily IC grind. They've had other goals, other mental loads, other stresses for 5+ years and simply cannot remember what it's like to be an IC anymore.
You can even handwavingly "prove" using queuing theory that giving a 100% at work will always be unsatisfying; you'll never be able to meet demand during busy moments if people expect you to be at 100% effort always, on average.
Pareto principle again, we see it in yoga, running, finances and now team management. Lack of purpose, not able to fully disconnect from work and low wages are the real leading causes of low productivity/burnout IMO.
That's just the Pareto distribution, one more time. In queuing theory that's where the knee is at. And for NP problems, efficient approximations are at about the same number.
I'm not sure there are any solutions other than customized and active management. Have lead two teams over the last 3 years. I'm not a manager, a mere scrum lead, that entails more of a frontline people/technical leadership position in my org as opposed to process evangelist. Both teams Ive had the exact same approach with at least in the beginning; people over process, autonomy over oversight, explicit expectation of no more that 80% commitment, flex time etc etc a healthy approach as far as I was concerned. The first was brilliant sucess to the point that the team was naturally agile, scrum was a joke of a projects, and I actually started cancelling dayil stand-ups because they were a pointless meeting. Over half the team turned into overachievers, we actually had to start forcing people to take time off to guard against burnout.And not PTO mind you, unaccounted flex time as a courtesy for good performance.
The second went completely off the rails. Near total underperformace, maybe on average 20% utility, people trying to game the system and cheat the team, esp with flex time and PTO. Why I have no clue because we never changed our policies, "I don't want to work today" has been a valid excuse our org. The larger org is so cooperative, that you could check out in the middle of release if you wanted to, no questions asked and people would cover for you, because there has always been an underlying trust that you do you best when you can and you would do the same for your mates when the time came. This was so widely abused that I have to take 2 sets attendance, one publicly and one on the side (the latter is where I count how many times grandma died), I'm having to chase people for deliverables, stand-ups are daily and an interrogation session when I have to publicly shame people for trying to cheat their teammates. One guy actually posted his second job on his linkedin(he was axed). And now I have to wave the big hammer of looming layoffs around. Overall a pretty miserable situation. Finally after many draconian measures there is a glimmer of acceptable performance.
> I'm not sure there are any solutions other than customized and active management.
I think this is the real issue here. People are not replaceable parts and it's very hard to come up with generalizeable solutions.
Maybe one thing we could do as an industry is switch mindsets from predictive models (i.e. "if we just implement XYZ methodology, the team will do better") to reactive models (i.e. "something is going wrong, we should try to understand it and change something"). This is probably just a roundabout way of describing the customized and active management that you mentioned, but I also think that sometimes these problems can be structural.
For example, sometimes a team member leaving can have detrimental effects because they weren't just a programmer, they were also the social glue holding the team together. Conversely, sometimes adding (or replacing) someone can bring about a situation where it feels like there are too many cooks in the kitchen, even if the overall team size hasn't changed much (or at all).
Maybe one area to look at with respect to people gaming the system is around people's personal values and how they track with the org's. These can be hard to gauge and people will intentionally misrepresent them because they want that job and the money that comes with it, so they are prepared to say what you want to hear. Also in larger organizations, sometimes the values statements are very dilute and not really saying anything. For example, saying "success" is a value is pretty useless because everyone wants to succeed. That's not a value, that's just effectively a no-op generic filler statement.
Anecdotally, I've found I do my best work when I have periods that average to roughly 85% pressure (ballparking that). It's okay to have 110% days, but they need to be offset by some lower-stress days. I think this is well-known, but that "slack" time gives me space to think about what I'm doing. I have time to think smart and execute better. I can afford to take small-ish risks to deliver faster/better/quicker knowing I have space to recover if I fail.
When I work at 110% pressure all of the time, I need to choose safe solutions. Safe solutions take longer, but they always ship.
* Mentally, I don't have the capacity to think about what I'm doing. If I'm just churning out cogs in a machine, that's fine. If I need to come up with a creative solution, I'm going to find the mentally easiest one (not necessarily the best one)
* For Bandwidth/Time, I don't have time to take any risks. I can't explore possible better solutions because the risk of being wrong pushes me back even further. Without Slack, I have absolutely no time to catch up.
When you imagine that people are machines, feed them OKRs, put a lot at stake, and stack-rank them, you are systematically stamping out the heavy tail that gives rise to spectacular things. Only with mediocrity can an individual "consistently deliver on commitments".
The solution is portfolio thinking. Stop demanding that each employee be a Treasury Bond, and have a portfolio of growth stocks instead. Speaking of portfolios, we know what active management does, do we not?
Additionally, there is a rhythm to things. The field lies fallow, and then there is planting, and then it bears fruit. It's not just constant visible output.
I had a manager once ask us to give 100% during a production incident, including over the weekend since we'd worked into Friday. On Saturday I started to realize the extend of the damage and told everyone to pace themselves--I took Sunday off. The problem was extensive data inconsistencies with duplicates requiring application of heuristics yet to be developed in an area our team didn't have expertise. It took months to complete. The last thing you want is for tired burnt-out folks making sweeping production data changes in a hurry. The manager's idea of helping was repeatedly asking in the dev chat channel, how's it going? When will it be done?
If you read management books, they suggest loading your employee even less, I think it's 70%. The idea is to give your team the room to take on tasks that pop up outside of regular scheduling.
63 comments
[ 2.9 ms ] story [ 147 ms ] threadIs 85% the new 80%?
Sounds familiar? That explains every software project that went over time and budget ever. You can apply the same logic to product management. If you are planning for more work to be done than can be done, you are wasting time and money. Ask for less; you'll get more better and sooner. Applying Brooke's law to this means that adding people to the team won't address this even.
I regularly see companies make both mistakes and then they fail to deliver, everybody is stressed out, and the team under performs. It doesn't work. Prioritize work correctly and make sure everybody focuses on only the top priorities. It doesn't matter if you are using scrum, kanban, or waterfall. Just make sure your team is working on the smallest number of things at any time possible without any of them having to idle or wait.
I'm a big fan of Don Reinertsen's work on lean 2.0 where he talks about this and more and uses some sound economical reasoning to back all this up.
By introducing a barrier people are forced to reduce congestion, which avoids people trying to exit the door at the same time clogging it up.
IME it does matter. Kanban is really about focusing on priority and throughput with no frills. Kanban is effective, can be explained in ten minutes, and just works.
Most of Kanban really ties in well with Demings ideas, which I think is why it works.
Scrum leads to a lot of meetings, ceremony and more "managers" - scrum masters as well as POs, and any other middle management your company had before picking scrum.
And when Scrum inevitably fails, the cultists yell that it was implemented wrong, that we never did real Scrum, that if Scrum was done correctly we would succeed. Kind of like "communism was never tried".
But it was tried, many times, by many teams, and sometimes despite the system some project somewhere might have thrived.
It's a system that only works in an idealized world, with idealized people, that I surmise at this point never existed.
Kanban is not an excuse to skip planning and having a TODO list full of high priority items is a classic mistake with it. When everything is important, nothing really is. With Scrum the classic mistake is over committing your team based on a notion that managers wants to overload the team because they think that produces results.
I treat both processes exactly the same when I put my product manager hat on (I'm also CTO, and a developer): regular planning activity to cherry pick the backlog and populate the TODO column. Pruning unimportant work from the TODO list. Making sure work is prioritized correctly. Scrum light, Kanban, Vaguely Agile, whatever labels you want to put on it works for me. I can scale up or down the scrum ceremonial stuff as needed/demanded.
It's usually in some phase of the project where there's not too much to do or deliver. But these small gains are necessary for everything to work well then the pressure is on a month or two later.
You don't get this if you're always at capacity and have no time to think.
One should also teach those skills to colleagues to deconstruct high performance (stress) environments.
I once had a manager who would literally "sneak up" on people: He would make cartoonish sneaking gestures while sneaking up behind someones chair! He criticized anything not purely work related he could see on screens. When I had worked enough and wanted to rest, my solution was to literally scroll through source code while going somewhere else in my head.
Otherwise know as the Scotty principle.
Didn't know about it. I guess I'm somehow a perfectionist when I work with people I respect or on projects I find valuable. It's tiring though.
One needs to procrastinate just a bit to do smart things.
Big red flag. I am not prepared to give 110% to anyone's who's not me or my loved ones, sorry. And the amount I expect to receive in exchange, monetary or otherwise, increases quadratically as we reach 100%.
If your engineers give more than 75% effort on average, they're lying to you, you're hopelessly naive, or you're a slave driver.
Is it hours worked? Is it "acts passionate"? Is it talks too much? Is it the amount of code commits?
Even if you pretend that your team can sustain 100% effort in the long term, and are willing to disregard the effects of working that way on their lives, there is no such thing as 110% effort, so a steady state of 100% effort means you don't have the spare capacity to push hard on specific short-term goals when there is a need for it. Or, put differently, you have a much more limited ability to react quickly to sudden shifts in the market.
So I see the temptation to "get more done with less" although the reality is you actually drop throughput in the long term.
It isn't just the managers doing this. Anyone who isn't in a position of authority but has knowledge of the state-of-the-art, research on it, etc. can tell when someone in that position is pushing their ideals over actually having done research or doing logic beyond a bunch of unquantifiable 'what if' arguments. It takes 5 minutes of online research to dismantle their arguments. But it still happens regardless, even in CS and SD where myths are pushed as absolute truths.
"My team always give 110%" is better than "I treat my people like adults with lives of their own", even if it gets much poorer results.
My favorite myth is the one that I hear surprisingly often, from educated and intelligent people. I hear it, because I ask them why they bias for only young people; even in senior management, architectural, and mentoring roles.
They explain that young folks can do the impossible, because they haven't been told that it's impossible. It's a really compelling myth, reinforced by founders of successful unicorns, sharing it as their "secret sauce," as opposed to obsessive work, intelligence, and an enormous dollop of good luck and timing.
I call it the "Don't Look Down" Fallacy.
When Wile E. Coyote runs off the edge of a cliff, he stays up, until he looks down.
If you don't allow anyone into the team that yells "Look down!", then you can fly.
Absolutely. I didn't mention people that tell you to stay away from the edge.
In many cases, timidity (often a reaction to past trauma) can be debilitating.
I remember when I was interviewing at startups, and Every. Single. One. -Every one, described themselves as "unicorns."
The harsh reality is that, for every unicorn, prancing around the tech industry, there's a charnel pit, filled with the corpses of 10,000 goats and jackasses, with horns glued to their foreheads.
Not all timidity is bad, and, sometimes, ignoring warnings can be quite fatal.
Plenty of people will learn only that which they perceive to be required and no more. People managers don’t seem to be an outlier here.
I’d probably still agree with your statement though. They also definitely don’t teach us how to manage.
For that reason, training for public defender managers is usually legal training and subject-matter-specific leadership training. For example, we get a lot of training time on how to support lawyers through burnout. It is almost unheard of that we would get training on abstract or generalist management practices. Executives see it as off-mission and managers think it's a waste of time.
This problem is exacerbated by being a correct strategy at a certain (small) organizational scale, but the paradigm falls out of alignment as the organization grows. It's hard to build an intentional culture of management in an already-existing organization.
It was a good enough insight that Phoenix Project basically mentioned that book for its version of it.
https://en.wikipedia.org/wiki/W._Edwards_Deming
* ICs need time to think deeply. They're tasked with getting all of the details correct. Details take a lot of time, mental load, and effort. They're exhausting in the moment. It's hard to do "just one more task" after you've already worked deeply all day.
* Leaders are tasked with shaping direction of teams. They spend a lot of time reviewing and guiding "the details", but generally can't get into the weeds. They carry on-going mental burden of _everything_ that's important to the company, but can generally delegate the details to other people. Since they don't spend all day dealing with the details, it doesn't feel painful for them to "tackle a few more things".
It's kind of like the tortoise and hare.. ICs sprint, sprint, sprint. Leaders walk. They probably cover the same ground mentally, but most people are much better equipped to walk 10k miles per day than sprint 10k, 100m at a time.
It's incredibly hard to overcome that daily lived experience. Most leaders are going to be at least 5+ years separated from the daily IC grind. They've had other goals, other mental loads, other stresses for 5+ years and simply cannot remember what it's like to be an IC anymore.
Management consulting is one of the worst work life balance and total hours industries.
I’m not sure advice on burnout from them isn’t ironic.
https://chat.openai.com/share/ba358d38-816f-4561-b125-a6d272...
The second went completely off the rails. Near total underperformace, maybe on average 20% utility, people trying to game the system and cheat the team, esp with flex time and PTO. Why I have no clue because we never changed our policies, "I don't want to work today" has been a valid excuse our org. The larger org is so cooperative, that you could check out in the middle of release if you wanted to, no questions asked and people would cover for you, because there has always been an underlying trust that you do you best when you can and you would do the same for your mates when the time came. This was so widely abused that I have to take 2 sets attendance, one publicly and one on the side (the latter is where I count how many times grandma died), I'm having to chase people for deliverables, stand-ups are daily and an interrogation session when I have to publicly shame people for trying to cheat their teammates. One guy actually posted his second job on his linkedin(he was axed). And now I have to wave the big hammer of looming layoffs around. Overall a pretty miserable situation. Finally after many draconian measures there is a glimmer of acceptable performance.
I think this is the real issue here. People are not replaceable parts and it's very hard to come up with generalizeable solutions.
Maybe one thing we could do as an industry is switch mindsets from predictive models (i.e. "if we just implement XYZ methodology, the team will do better") to reactive models (i.e. "something is going wrong, we should try to understand it and change something"). This is probably just a roundabout way of describing the customized and active management that you mentioned, but I also think that sometimes these problems can be structural.
For example, sometimes a team member leaving can have detrimental effects because they weren't just a programmer, they were also the social glue holding the team together. Conversely, sometimes adding (or replacing) someone can bring about a situation where it feels like there are too many cooks in the kitchen, even if the overall team size hasn't changed much (or at all).
Maybe one area to look at with respect to people gaming the system is around people's personal values and how they track with the org's. These can be hard to gauge and people will intentionally misrepresent them because they want that job and the money that comes with it, so they are prepared to say what you want to hear. Also in larger organizations, sometimes the values statements are very dilute and not really saying anything. For example, saying "success" is a value is pretty useless because everyone wants to succeed. That's not a value, that's just effectively a no-op generic filler statement.
When I work at 110% pressure all of the time, I need to choose safe solutions. Safe solutions take longer, but they always ship.
* Mentally, I don't have the capacity to think about what I'm doing. If I'm just churning out cogs in a machine, that's fine. If I need to come up with a creative solution, I'm going to find the mentally easiest one (not necessarily the best one)
* For Bandwidth/Time, I don't have time to take any risks. I can't explore possible better solutions because the risk of being wrong pushes me back even further. Without Slack, I have absolutely no time to catch up.
When you imagine that people are machines, feed them OKRs, put a lot at stake, and stack-rank them, you are systematically stamping out the heavy tail that gives rise to spectacular things. Only with mediocrity can an individual "consistently deliver on commitments".
The solution is portfolio thinking. Stop demanding that each employee be a Treasury Bond, and have a portfolio of growth stocks instead. Speaking of portfolios, we know what active management does, do we not?
Additionally, there is a rhythm to things. The field lies fallow, and then there is planting, and then it bears fruit. It's not just constant visible output.
build bot that responds with:
how's it going?
bot:good
When will it be done?
bot: hard to tell but, we're making progress