To Build a Top Performing Team, Ask for 85% Effort
hbr.org
hbr.org
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.
One needs to procrastinate just a bit to do smart things.
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.
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.
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.
* 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.
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
https://chat.openai.com/share/ba358d38-816f-4561-b125-a6d272...
Is 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.
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.
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.