(2023-09-02 update: I want to recommend three great books I’ve read since posting this: Humanocracy: Creating Organizations As Amazing As the People Inside Them by Gary Hamel and Michele Zanini, Escaping the Build Trap: How Effective Product Management Creates Real Value by Melissa Perri, and Multipliers: How the Best Leaders Make Everyone Smarter by Liz Wiseman)
(2023-06-13 update: I loved this talk by “Joy, Inc.” author Rich Sheridan. His brief discussion of estimates, deadlines, and commitments brilliantly captures the essence of why fear-driven tech workplaces are so unpleasant and underproductive. And his stories of babies in his IT shop’s workplace are hilarious.)
“To go fast, go alone. To go far, go together.”
– Unknown (possibly African proverb)
Not finance. Not strategy. Not technology. It is teamwork that remains the ultimate competitive advantage, both because it is so powerful and so rare.
– Patrick Lencioni, The Five Dysfunctions of a Team
For years, I’ve been shocked and saddened so many tech companies have heavy-handed management and toxic work environments. Companies become great by fostering creative, collaborative, committed teams… not by collecting talented “individual contributors” and carefully counting how many JIRA points each racks up.
A year ago I recorded what I intended to be the first of three videos documenting the problem and suggesting how we can fix it. My first video presented the experiences of many programmers who became programmers because they LOVED coding only to be driven to misery and madness by their tech jobs. What an indictment of tech management: It’s often so horrible and traumatizing that it compels people who love programming to flee the industry – despite the high pay, comfortable offices, and prestige – because their workplaces are so toxic.
At least 146,971 companies use JIRA, mostly in IT and software development! Many of these also use the formal, bureaucratic, meeting-heavy SCRUM™ process, even conflating “SCRUM™” with “agile” …though the original “Agile Manifesto” advocated for the exact opposite of SCRUM™:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
Notice that SCRUM™ is even trademarked because they’re literally trying to sell you more process (training, certifications, etc.), not actually help you eliminate unnecessary process to unleash developer creativity!
Managers love formal process and JIRA points because, they believe, gamifying software development allows them to squeeze every ounce of output from their “resources” (a.k.a. human beings with emotions, finite energy levels, pride, and on-work lives and responsibilities who can become exhausted and demoralized being treated as nothing but “code monkeys”). Surprisingly, developers hate feeling every day as if they’re on The Apprentice, Survivor, or The Hunger Games.
Beyond the cruelty, gamifying knowledge work is a formula for mediocrity.
Nearly two decades ago, when the New England Patriots were on the cusp of winning their third Super Bowl, I wrote two volumes on Management Secrets of the New England Patriots. In them, I shared a story in which coach Bill Parcells spun around 50 yards from a training drill to scream at a player. When the journalist who had been interviewing Parcells asked how he possibly could have seen that because he had been facing the other direction, Parcells explained he had planned to yell at that player that day and just happened to pick that moment. Parcells was a fear-driven motivator. Not coincidentally, most of Parcells’ career success was turning lousy teams into good teams, not turning good teams into great teams. (Parcells won two Super Bowls as Giants head coach, both with Bill Belichick as coordinator of the Giants’ stifling defense. Parcells never repeated his success as head coach of the Patriots, Jets, or Cowboys.)
Management by fear can whip lousy teams into decent – perhaps even good – teams, but it seldom produces greatness. Greatness comes only from the heart, when colleagues believe in one another and help each other accomplish more together than any of them could have achieved individually. Bill Belichick always shared the unvarnished truth with his players and constantly challenged them to become their best selves and most effective teammates. Striving for collective greatness was the team’s unifying principle, leading to six Super Bowl victories.
I’ve still not gotten around to recording the other two videos I outlined a year ago. But several weeks ago, I watched this outstanding Randy Shoup presentation on “Improving Software Flow” and loved it. I had planned my second and third videos to cover many of those topics and cite much of the same research, so I shared it with a former colleague who now manages a small engineering team, telling him:
I really enjoyed that talk… even if he ‘stole’ all my ideas! ;-) Seriously, the knowledge of how to run tech teams well is out there, but most companies still manage to suck at it. Sad.
(If you’re in tech, please go watch that talk! This blog will still be here when you finish.)
I’ve decided to turn my written notes into blog posts to share my thinking here. Hopefully this will energize me to finally record my videos.
The core problem is that many managers and executives crave real-time visibility into and control over everything happening on teams reporting to them because they don’t trust their people. This motive also explains why many firms have ordered employees back into offices, even though job satisfaction exploded during the COVID-compelled work-from-home era while productivity also rose substantially.
David Powell, president of Prodoscore said their data showed that if an employee was highly productive in-office, they’ll be productive at home; if an employee slacked off at the office, they’ll do the same a home. “After evaluating over 105 million data points from 30,000 U.S.-based Prodoscore users, we discovered a five percent increase in productivity during the pandemic work from home period,” he said. “Although, as we know, any variant of the Covid-19 virus is unpredictable, employee productivity is not.”
Two studies in early 2022 validated the views of remote/hybrid work advocates. Research from Owl Labs found that remote and hybrid employees were 22% happier than workers in an onsite office environment and stayed in their jobs longer. Plus, remote workers had less stress, more focus and were more productive than when they toiled in the office. Working from home led to better work/life balance and was more beneficial for the physical and mental well-being of employees.
A study from Ergotron sampled 1,000 full-time workers. It found that as workers become more acclimated to hybrid and remote office environments since the onset of Covid-19, the hybrid workplace model has empowered employees to reclaim physical health, and they are seeing mental health benefits, too.
– Forbes
Many managers/execs distrust their employees. Rather than let the employees most informed about details of each product/service/feature/codebase use their expertise to make informed decisions and choose how to work together most effectively, many managers/execs prefer to dictate what gets built, how it gets built, and when things must be finished. They desire the predictability and certainty schedules, burndown charts, and similar numeric systems provide the illusion of, much as millions consult astrologists, homeopaths, and psychics for “answers” to what ails them.
Many managers insist on using every feature in JIRA because they want to record every detail about who does what when, so they can slice and dice that data, partly to “measure” individual worker productivity. “Individual productivity” is a meaningless concept in truly collaborative environments where everyone regularly helps everyone else. Ironically, precisely “measuring” and rewarding individual productivity is the perfect way to kill off natural, healthy collaboration, communication, and coordination. And destroying teamwork will finally enable you to meaningfully measure individual productivity because it will be the only thing left!
Attempting to measure “individual productivity” incentivizes workers to cut corners on anything unmeasured – like code quality, documentation, tests, helping one’s colleagues, etc…. all to the long-term detriment of the team and the firm:
“Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.” …Anthropologist Marilyn Strathern expressed Goodhart’s Law as “When a measure becomes a target, it ceases to be a good measure.”
Managers/execs want to tell others how to use their time, not trust them to make informed decisions and invest their time wisely, so they force programmers to track their “productivity” using JIRA while almost never subjecting themselves to a similar system, a double-standard resented by coders.
Centralized, top-down, command-and-control processes may work well in widget factories where every worker has a narrow, well-defined, discrete, independent, easily measured role on the widget assembly line. But micromanagement and simplistic measurements fail utterly when job roles are unclear, products improve through the iterative & incremental application of creativity (i.e., true “agile”), and collaboration and brainstorming are key productivity drivers. What matters is how much customers (and potential customers) value the collective output of the collective programming effort.
The value to customers of each new feature, UI change, performance enhancement, security improvement, etc. is hard to measure and nearly impossible to predict. It’s impossible to empirically calculate return-on-investment (ROI). So, how can managers “scientifically” manage by metrics? Since they can’t measure customer value, tech managers – like the proverbial economist who looks for his lost keys under a lamppost because that’s where the light is, even through he dropped them elsewhere – embrace SCRUM™.
Though managers/execs attribute magical significance to “JIRA points,” it’s totally unclear what JIRA points measure. Some teams say it’s time, others complexity, others just a “tee-shirt size” (S, M, L). Whatever JIRA points are, they ignore what really matters – how much customers value the code changes – and very inaccurately measure employee time inputs. They even do a lousy job of measuring that. But, desperate for control and the comfort and cover metrics provide, managers & executives revere a bad measure of the wrong thing. “Maximizing sprint velocity” is the holy grail in many tech shops, despite the ease with which JIRA points can be gamed and the incredible time wasted guesstimating, planning with, and monitoring JIRA points. As Shoup’s talk proves with empirical evidence from many teams working across many code bases, it’s extremely hard to estimate large projects – especially projects on codebases laden with significant technical debt, which is commonplace at the “feature factories” where managers wholeheartedly embrace full-on SCRUM™ – leading those guesstimates to be wild-ass guesses. You won’t really have a good sense of how hard the project is until you’re well into the implementation and have interacted with the code that must change.
In a world of perfect information, managers would select for implementation the highest ROI (return-on-investment) projects first. In reality, they can’t calculate return and have only lousy metrics on time investments. Nevertheless, they persist with a formal, metrics-driven planning process, even though formal meetings to point every JIRA are time-consuming and soul-crushingly boring. Why not just let teams or individual developers informally decide which features to prioritize based on their informed judgment about customer needs and likely development time?
Creative, collaborative teams thrive when everyone trusts everyone else and everyone is free to unleash their creative energy. Think about great jazz bands. Or great basketball teams. Or great soccer (i.e., real “football”) teams… (Hooray for City winning our fifth Premier League trophy in six seasons!).
Tech managers and executives should strive to build great jazz or rock bands. Tech managers write job descriptions seeking “rock stars,” but then those same managers try to control everything by locking down innovation/creativity and standardizing everything from work hours to process via rules and bureaucracy. This turns jazz/rock into classical.
When we took our kids to a classical music concert years ago, we were almost the only non-elderly in the giant auditorium. Classical is dying – it’s just 1% of music in the US – because jazz and rock are more fun to play and listen to. Programmers didn’t become programmers to work in a paint-by-numbers bureaucracy where they spend more time in planning poker meetings than in VS Code. Employee engagement is critical to company success, and excessive bureaucracy is demotivating. But when you force rock stars to play classical music, they’re going to find a new band! Musicians love making music, but when you tell each musician exactly how to play each note, you’re sucking the creativity, playfulness, and joy out of music-making.
Micromonitoring and micromanagement are “push” approaches to management predicated on the usually tacit assumption that workers are lazy and must be prodded like cattle to do their jobs. People dislike being constantly monitored and distrusted and forced to follow arbitrary rules & procedures (as evidenced by the wild popularity of the brilliantly haunting TV series “Severance”).
Minimizing bureaucracy and embracing real “agile” boosts engagement, creativity, productivity, and job satisfaction.
Engaged, productive developers despise routinized meetings (while appreciating focused, just-in-time meetings held to achieve clear, important objectives) and any bureaucratic process/paperwork that distracts from building stuff. Great tech companies strive to minimize interruptions and unproductive bureaucracy, instead fostering environments that enhance developers’ desire and ability to create value by removing blockers and getting out of their way. Surround great developers with other great developers, managers, designers, data engineers, etc. Foster effective communication and coordination. Set a clear high-level vision. Help them understand customers and their needs. Help unblock them when they’re stuck. Praise their successes. Servant leadership spurs creativity-driven knowledge work.
The happiest and most productive tech teams use true “agile” – usually closer to extreme programming or kanban than full-blown SCRUM – and leverage modern DevOps (see: Accelerate: Building and Scaling High Performing Technology Organizations) to rapidly iterate an improvement-and-feedback loop that drives their productivity flywheel. They:
- Focus on making customers happy
- Iterate in small, quick steps
- Get constant, fast feedback
- Deploy frequently
- Minimize meetings, paperwork, and bureaucracy
Great developers love incrementally evolving software that helps and delights customers. They don’t want to sit around a conference table TALKING about doing things, like meetings to prioritize the upcoming month’s 100 JIRAs or “planning poker” meetings estimating (i.e., guessing) how long implementing each of those 100 JIRAs will take. Customers don’t care about JIRA points. These are examples of what I term “incidental work” – “work” we do that provides no intrinsic value – as contrasted with “essential work” – real work that provides real value.
I coined the term “incidental work” because software engineering makes an analogous distinction between “essential complexity” – complexity that must be present in our code to match the business problem the code solves – and “incidental complexity” – excessive, unnecessary code complexity extraneous to solving the business problem. Great code minimizes incidental complexity, just as great firms minimize incidental work.
As part of my dissertation 25 years ago, I showed empirically that creative work happens in collaborative, growth-mindset work cultures with fewer rules and greater autonomy where workers feel more engaged, satisfied, and fulfilled and productivity is higher. A secondary effect was that workers in jobs with strict hours and rules and more top-down controls – e.g., factory workers and workers in large, bureaucratic firms – were less happy and less autonomous but received a pay premium, apparently to compensate for the strict conditions. My dissertation showed that rules & regulations literally cost companies money because firms with strict workplaces must pay what labor economists term a “wage premium” to attract and retain workers who must obey and are prevented from exercising creativity.
Managing creative work requires servant leadership and a “trust but verify” approach toward non-managerial employees. If you want your knowledge workers to love their jobs and bring their creativity and enthusiasm to their work every day, please stop micromonitoring & micromanaging them. Trust them do work intelligently and diligently and help them when you notice them struggling. Most will reward your trust.
Knowledge workers are at greater risk of burnout than excessive slacking. Everyone needs some slack time in their schedule to decompress and clear their heads. And, given how frequently innovation strikes while exercising, showering, etc., it’s essential that leaders realize that pushing their knowledge workers to work 50 or 60-hour weeks – or even trying to squeeze 40 hours of focused work into each week – is not just unfair but also counterproductive. You won’t get the benefit of your workers’ innovation and creativity because they won’t have any downtime in which innovation can strike. And code written by exhausted, stressed engineers will be full of expensive bugs. (And preventing bugs is far more cost-effective than fixing them later.)
Knowledge workers also need time to learn new skills. Technologies are constantly changing. New technologies arise as older technologies fade away. Workers need time to update their skills. Tech innovations can benefit your firm only if your workers have time to learn about and play around with them. Demanding that they spend every minute of their work week churning out code guarantees you’ll eventually: a) burn them out; b) drive them away to less torturous employers, and/or; c) stifle their growth by forcing them to grind through their days… working harder but never smarter.
I don’t now who first shared this astute observation, but someone once answered a manager’s fearful question – “What if I train my workers and they leave?” – with “What if I don’t train my workers and they stay?” If you treat your employees well, which definitely includes allowing tech workers time to upskill, they’re likely to reward your loyalty and concern for their welfare. Firms that treat workers solely as output machines deserve no loyalty.
There’s an implicit contract between employers and employees in fast-evolving fields like tech that workers will be able to acquire and grow skills through their work. Employers who deny employees opportunities to grow are violating this norm and will suffer the consequences through low morale, ill-equipped employees, and their best people quitting.
Sadly, tech management may not be much worse than management broadly because less than one-third of U.S. employees consider themselves actively engaged at work!
employee engagement in the U.S. saw its first annual decline in a decade – dropping from 36% engaged employees in 2020 to 34% in 2021.
This pattern continued into 2022, as 32% of full- and part-time employees working for organizations are now engaged, while 18% are actively disengaged. Active disengagement increased by two percentage points from 2021 and four points from 2020.
This isn’t a recent phenomenon. The same article shows data since 2000, and employee engagement has averaged just 30%! What a colossal waste!
Gordon Gecko famously said, “Greed is good.” Corporate America over the past four decades agrees. Whereas large corporations in the 1950s bragged about the taxes and wages they paid, CEOs have cared almost exclusively about shareholders since Ronald Reagan took office. From 1979 through 2021, inflation-adjusted worker productivity rose 64.4% while inflation-adjusted worker compensation rose only 17.3% (Economic Policy Institute, Oct 2022)! Where did the other 47.1% increase go? To stockholders!
Corporate profits have exploded relative to employee productivity, so workers naturally feel aggrieved. Even highly profitable large tech firms have been carrying out large-scale layoffs over the past year (while also forcing employees back into offices). Wall Street seems to endorse these “cost-cutting” measures, but these firms are sowing the seeds of employee disengagement and discontent because knowledge workers perform best in stable work environments with teammates and managers they trust and feel “psychological safety” working with. Treating knowledge workers as expendable “resources” undermines the trust and psychological safety that underlies creative, collaborative teamwork. Some of these executives and managers probably even think they can replace some of their workers with ChatGPT.
Knowledge work is creative work, which must be fostered, not forced. This requires trust, not surveillance. After my friend watched Randy Shoup’s talk, he asked how managers and execs can let go of control and trust workers to do the right thing. That’s the key question, and it’s where I believe so many managers and executives go off the rails. They crave certainty and control, but that’s impossible for work done best via innovation, collaboration, and experimentation. I replied:
You must hire trustworthy, responsible, motivated employees. If people aren’t consistently delivering, they don’t belong there and you need to replace them. Autonomy comes with responsibility.
Most people want to do good work. If they’re not, they’re either over their heads, distracted by life problems, or lazy. In the first case, your job is to get them the training or help they need or assign them more suitable work. In the second case, you encourage them to get help, but if things don’t eventually improve, they have to go. In case three, they need to go right away. You’re not a babysitter.
Check out “Theory X vs. Theory Y.” Many managers are stuck on Theory X. But we require creativity and motivation. Managing programmers requires Theory Y.
Here’s a brief summary of “Theory X” vs. “Theory Y”:
Frederick Winslow Taylor invented “scientific management”, i.e., managing employees via metrics. Many execs today think in Taylorist terms (i.e., developers require monitoring and carrots & sticks to perform optimally), but most knowledge workers are actually intrinsically motivated to do quality work and wish managers would trust them to do their jobs to the best of their abilities.
Many execs & managers remain stuck in Taylorist (“Theory X”) thinking that people are lazy and need to be pushed to do work via monitoring, rewards, and punishments. For good developers, the reality is the opposite. Good developers are desperate to produce value for customers. They take pride and joy in producing quality work. The #1 factor determining daily developer satisfaction is how productive the developer felt that day:
What makes a [developer’s] workday good… On good workdays, developers make progress and create value on projects they consider meaningful, and spend their time efficiently, with little randomization, administrative work and infrastructure issues.
Knowledge workers live in a Douglas McGregor / “Theory Y” (“The Human Side of Enterprise”) world, for which traditional Taylorist management is a bad fit:
“In the 1970s the MIT Sloan School was involved in a management program for newly promoted admirals at the Naval War College. …When we gave this [Theory X vs. Theory Y] questionnaire to class after class of the new admirals, we were surprised to learn that they were consistently higher in Theory Y assumptions than the industrial groups we had tested. As we got to know these admirals as individuals and heard their stories of what leadership in the Navy meant, it became obvious that command did not automatically mean control. These admirals were acutely aware of how important it was for them to trust their subordinates… They knew that control systems that implied mistrust would backfire.”
– Edgar Schein, forward to the annotated edition, in: Douglas McGregor, updated by Joel Cutcher-Gershenfeld, “The Human Side of Enterprise,” Annotated Edition, 2006
Warren Bennis summarized “Theory Y” creator Douglas McGregor as advocating:
* Active participation by all involved
* A transcending concern with individual dignity, worth, and growth
* Reexamination and resolution of the conflict between individual needs and organizational goals, through effective interpersonal relationships between superiors and subordinates
* A concept of influence that relies not on coercion, compromise, evasion or avoidance, pseudosupport, or barganing, but on openness, confrontation, and "working through" differences
* A belief that human growth is self-generated and furthered by an environment of trust, feedback, and authentic human relationships
-- Warren Bennis, forward to the 25th-anniversary printing, in: Douglas McGregor, updated by Joel Cutcher-Gershenfeld, "The Human Side of Enterprise," Annotated Edition, 2006
My friend asked whether such an approach can work in toxic environments. I replied:
It likely depends on the form of the toxicity. If there are reasons for people feeling shitty about doing their jobs, like tons of formal process, you can hopefully improve the environment and raise engagement. I doubt many firms are full of lazy developers. There’s likely at least one serious, underlying problem at any firm where everyone feels shitty about their job.
One such thing I’ve seen is companies with many unreasonable deadlines, lots of technical debt, and demands that employees work nights and weekends to get their JIRAs done on schedule. Coding at places that prioritize shoveling shit out the door [perhaps because they measure and worship a bullshit metric like JIRA points], rather than keeping tech debt to reasonable levels, can be truly painful. There are many such firms. And many of the execs/managers either don’t understand how painful working in an ecosystem loaded with tech debt is or they just don’t care.
People cut corners by hacking in quick fixes, skipping tests and documentation, etc., and tech debt spirals out of control. Next, the good devs leave. It then appears as if the problem is bad attitudes, but [those attitudes are] a symptom of the bad work environment.
Let’s please minimize bureaucracy, minimize fear, and minimize frictions that prevent teams from collaborating to make steady collective progress. Done well, software development teams love their colleagues and their jobs.
Richard Sheridan documents in Chief Joy Officer: How Great Leaders Elevate Human Energy and Eliminate Fear the wonderful example he helped build in Ann Arbor-based software firm Menlo Innovations, which has lasted 22 years and counting. (He has another successful book, Joy, Inc.: How We Built a Workplace People Love, that I haven’t yet read.) If you want to learn more about building healthy, happy, productive tech teams, his book explaining what he terms “joyful leadership” might be a good place to start. You could also listen to this podcast interview or this interview or one of his many other video talks & interviews.
(Thanks to Alex Knight for this photo on Unsplash.)