5 ms·

To Build a Top Performing Team, Ask for 85% Effort

87 points by kiyanwang 3y ago

dave4420 3y ago
Where did this 85% figure come from? Is 85% the new 80%?
- sjwod 3y ago
  The summary at the top of the article clearly mentions that the precise number 85% is just a rule of thumb...
- jillesvangurp 3y ago
  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.
  - magicalhippo 3y ago
    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.
  - carlmr 3y ago
    >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.
    - jillesvangurp 3y ago
      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.
datadeft 3y ago
Isn't this the Pareto principle in different flavour?
- koliber 3y ago
  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.
  - nottorp 3y ago
    Its not only burning out but also having spare capacity for emergencies. Which is also in the interest of the employer.
    - carlmr 3y ago
      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.
nottorp 3y ago
Hmm I wonder if Slack named their chat app “Slack” to make it hard to find the original “The importance of slack” articles.
- wiredfool 3y ago
  Probably Smiling Bob.
- re-thc 3y ago
  Slack named themselves "Slack" so when you want to Slack off you use the Slack app = get back to work.
Traubenfuchs 3y ago
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.
- RobotToaster 3y ago
  >Overstating problems/blockers, overestimating stories and overselling your work should be in any capable slackers toolkit Otherwise know as the Scotty principle.
  - robertlagrant 3y ago
    That's why Kirk halved his doubled estimates.
orwin 3y ago
> 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.
koliber 3y ago
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.
- sam_lowry_ 3y ago
  No-no, pushing people too hard leads to dumber, less efficient solutions all the time. One needs to procrastinate just a bit to do smart things.
  - nine_k 3y ago
    Aka take some time to think.
wly_cdgr 3y ago
Wise and spot-on. Looks like an adult wrote this
- wly_cdgr 3y ago
  Y'all will come back in 20 years specifically to upvote this.
sph 3y ago
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.
- re-thc 3y ago
  What's the point? It's all vague. How do you really tell if it's 75% or 110%? How would you even know what someone's 100% is? Is it hours worked? Is it "acts passionate"? Is it talks too much? Is it the amount of code commits?
  - ethanbond 3y ago
    You ask them
  - smaudet 3y ago
    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?"
- OJFord 3y ago
  Anyone (or company, but I haven't seen that) talking about '110%' of such things raises a different red flag for me anyway!
  - sharemywin 3y ago
    a math red flag.
pdpi 3y ago
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.
- unsupp0rted 3y ago
  There is such a thing as 110% effort. It's the amount of effort that temporarily or permanently injures the person making it.
  - speed_spread 3y ago
    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.
- HelloNurse 3y ago
  But the payroll savings compared to hiring 10-20% more people are much more solid and measurable.
  - smaudet 3y ago
    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.
siliconc0w 3y ago
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.
- epicureanideal 3y ago
  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..”
  - BlargMcLarg 3y ago
    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.
    - TheOtherHobbes 3y ago
      Most corporate hierarchies exist to create status and power, not to enhance effectiveness and productivity. "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.
    - ChrisMarshallNY 3y ago
      > 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.
kingkongjaffa 3y ago
> Consider McKinsey’s research on burnout 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.
- raverbashing 3y ago
  I'm sure several Associate members had tight deadlines and were pushed to the brink to produce that report
isoprophlex 3y ago
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. https://chat.openai.com/share/ba358d38-816f-4561-b125-a6d272b7cfed https://chat.openai.com/share/ba358d38-816f-4561-b125-a6d272...
Mizoguchi 3y ago
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.
OJFord 3y ago
What about the 'well I'm going to go all out anyway, so when they consider that my 85% effort they'll think I must be hot shit' effect?
frankreyes 3y ago
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.
llamajams 3y ago
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.
- smif 3y ago
  > 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.
koromak 3y ago
Heres a crazy idea - How about 40 hours a week?
SkyPuncher 3y ago
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.
- FooBarBizBazz 3y ago
  This. This. This. 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.
karmakaze 3y ago
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?
- sharemywin 3y ago
  1st task on the agenda: 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
baerrie 3y ago
It’s pretty simple, operate at 85% so that when unexpected work crops up, adding 5-10% more effort doesn’t break you
leros 3y ago
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.
ldehaan 3y ago
[dead]

87 points by kiyanwang 3y ago

dave4420 3y ago

Where did this 85% figure come from? Is 85% the new 80%?

sjwod 3y ago
The summary at the top of the article clearly mentions that the precise number 85% is just a rule of thumb...
jillesvangurp 3y ago
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.
- magicalhippo 3y ago
  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.
- carlmr 3y ago
  >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.
  - jillesvangurp 3y ago
    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.

datadeft 3y ago

Isn't this the Pareto principle in different flavour?

koliber 3y ago
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.
- nottorp 3y ago
  Its not only burning out but also having spare capacity for emergencies. Which is also in the interest of the employer.
  - carlmr 3y ago
    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.

nottorp 3y ago

Hmm I wonder if Slack named their chat app “Slack” to make it hard to find the original “The importance of slack” articles.

wiredfool 3y ago
Probably Smiling Bob.
re-thc 3y ago
Slack named themselves "Slack" so when you want to Slack off you use the Slack app = get back to work.

Traubenfuchs 3y ago

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.

RobotToaster 3y ago
>Overstating problems/blockers, overestimating stories and overselling your work should be in any capable slackers toolkit Otherwise know as the Scotty principle.
- robertlagrant 3y ago
  That's why Kirk halved his doubled estimates.

orwin 3y ago

> 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.

koliber 3y ago

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.

sam_lowry_ 3y ago
No-no, pushing people too hard leads to dumber, less efficient solutions all the time. One needs to procrastinate just a bit to do smart things.
- nine_k 3y ago
  Aka take some time to think.

wly_cdgr 3y ago

Wise and spot-on. Looks like an adult wrote this

wly_cdgr 3y ago
Y'all will come back in 20 years specifically to upvote this.

sph 3y ago

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.

re-thc 3y ago
What's the point? It's all vague. How do you really tell if it's 75% or 110%? How would you even know what someone's 100% is? Is it hours worked? Is it "acts passionate"? Is it talks too much? Is it the amount of code commits?
- ethanbond 3y ago
  You ask them
- smaudet 3y ago
  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?"
OJFord 3y ago
Anyone (or company, but I haven't seen that) talking about '110%' of such things raises a different red flag for me anyway!
- sharemywin 3y ago
  a math red flag.

pdpi 3y ago

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.

unsupp0rted 3y ago
There is such a thing as 110% effort. It's the amount of effort that temporarily or permanently injures the person making it.
- speed_spread 3y ago
  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.
HelloNurse 3y ago
But the payroll savings compared to hiring 10-20% more people are much more solid and measurable.
- smaudet 3y ago
  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.

siliconc0w 3y ago

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.

epicureanideal 3y ago
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..”
- BlargMcLarg 3y ago
  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.
  - TheOtherHobbes 3y ago
    Most corporate hierarchies exist to create status and power, not to enhance effectiveness and productivity. "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.
  - ChrisMarshallNY 3y ago
    > 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.

kingkongjaffa 3y ago

> Consider McKinsey’s research on burnout 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.

raverbashing 3y ago
I'm sure several Associate members had tight deadlines and were pushed to the brink to produce that report

isoprophlex 3y ago

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. https://chat.openai.com/share/ba358d38-816f-4561-b125-a6d272b7cfed https://chat.openai.com/share/ba358d38-816f-4561-b125-a6d272...

Mizoguchi 3y ago

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.

OJFord 3y ago

What about the 'well I'm going to go all out anyway, so when they consider that my 85% effort they'll think I must be hot shit' effect?

frankreyes 3y ago

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.

llamajams 3y ago

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.

smif 3y ago
> 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.

koromak 3y ago

Heres a crazy idea - How about 40 hours a week?

SkyPuncher 3y ago

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.

FooBarBizBazz 3y ago
This. This. This. 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.

karmakaze 3y ago

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?

sharemywin 3y ago
1st task on the agenda: 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

baerrie 3y ago

It’s pretty simple, operate at 85% so that when unexpected work crops up, adding 5-10% more effort doesn’t break you

leros 3y ago

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.

ldehaan 3y ago

[dead]