The Hardest Part of Being a Software Manager

Eric Elliott
Feb 20, 2020 · 9 min read
Image: Smoke Art Cubes to Smoke — MattysFlicks — (CC BY 2.0)

The hardest part of being a software manager is understanding that software takes the time it takes, and rushing it will slow it down and make it buggy. Patience is everything.

I know what you’re thinking. You have to finish your product in time for Black Friday, right? Or find product/market fit before the startup runway runs out? I feel your pain, but don’t make it worse on yourself. What you need to understand about software is that slow is smooth and smooth is fast.

Patience will help you move faster. Not just a little faster, but much faster. I once worked for a company that sold products through a custom shopping cart. Developers on the team lacked training and support, and a lot of the code they produced was buggy. About 40% of all commits were bug fix commits, many files had over 50 commits, meaning that it wasn’t right the first time. The code had to churn again and again before it was production ready. On average, a file needed more than a dozen changes before we could safely ship it to customers. We spent nearly half of our time on rework, and we had almost as many full time quality assurance specialists as we had engineers.

By slowing down, investing in training, and following a better quality process, we could have shipped working code considerably faster and spent more of our headcount building more value with software engineers instead of fighting fires with QA.

In manufacturing, assembly lines jam when work product piles up at any point in the assembly line. Work doesn’t continue until those jams get cleared. If the system jams, the last thing you want to do is try to push from the start of the assembly line. That makes the situation worse.

In manufacturing, that’s common sense, but when engineering managers detect a slowdown, the default strategy is to push developers to move faster instead of first fixing the jam.

Engineering managers usually lack visibility into the software development process and have misunderstandings about why things are slower than they expect. Instead of listening and observing and developing an understanding of the process, culture, and situation, they push harder and make things worse.

When you rush developers:

  • Mentorship & reviews halt
  • Bugs pile up
  • Tests get skipped
  • Communication suffers
  • Developers burn out
  • Productivity suffers

Tip: Do you measure your defect commit rate? Count the number of total commits and the number of commits that close bug tickets. If a file has 51 commits and 14 of those are bug fix commits, your file has a (14/51) * 100 = ~27% defect commit rate. Average the defect rate across all files, and you have a relative bug density metric you can use to track improvement over time to evaluate your quality efforts.

To do this accurately, you’ll need to mark all bug related issues with a “bug” tag so you can distinguish them, and then link commits to the tickets they’re related to. GitHub makes that process easy. A typical source file should have a low number of commits (i.e., single digits), and a near zero defect count. Most codebases have hotspots where commit numbers and defect rates are much higher per file. If those files have recent commit activity, you should consider improving unit test coverage and refactoring those files.

The Worst Thing to Do

According to “On the Unhappiness of Software Developers” (Daniel Graziotin, Fabian Fagerholm, Xiaofeng Wang, Pekka Abrahamsson): The top causes of developer unhappiness were:

  • Being stuck in problem solving
  • Time pressure
  • Bad code quality and coding practice

A 2016 survey by Stack Overflow found that “unrealistic expectations” was the #1 challenge faced by developers at work.

Pushing harder is going to make all of those worse.

The worst thing you can do when productivity drops is to bring developers into meetings for motivation-draining “performance review” to discuss their struggles. Those meetings are the fastest way to destroy a programmer’s mood and motivation, and often lead directly to resignation.

Praise in public, offer improvement suggestions in private. Never chastise individual developers in group meetings.

Don’t reprimand employees you want to keep. Because of their motivation destroying effects, reprimands should only be used if mentorship and support have already failed.

Frequent 1:1 meetings are a great alternative to get insights into the morale and thinking of your development team without making it feel like a scary disciplinary meeting. Meet with each of your direct reports monthly, and use those sessions to learn from their insights. Don’t think of it like a performance review or discipline, but the chance to connect with people, listen, offer support, mentor, and share.

Listening is key. Done right, those meetings are your opportunity to demonstrate that you are there for them if they have questions, ideas, or frustrations blocking their progress. Developers need to progress in three ways:

  1. On the project they’re assigned to.
  2. In their skills as a developer.
  3. In their career.

By understanding and supporting the goals of the members of your team, you can keep them highly motivated and highly engaged. Highly motivated, highly engaged developers are far more productive.

When developers are stuck, they don’t need reprimands. They need support. Do your developers feel supported? Do they have a safe cultural environment to ask questions and learn from each other? Do you practice code review so that developers have an opportunity to support each other with opportunities for code quality improvements? Are developers working within the constraints of hard deadlines and being pushed to meet those deadlines, even if that means cutting corners?

Instead, tell developers that they should ship as quickly as possible, but not at the cost of cutting corners, skipping unit tests, or building excessive technical debt (i.e., the next production jam clogging your team’s overall productivity). If they can’t meet a hard deadline, they should raise the issue with the product team and discuss priorities and possible scope cuts.

Empathy for the developers on your team is the best way to show them that you care about them as people, and not just about the money the company earns from their work.

The Cost of Moving Too Fast

The Boeing 737 Max

MCAS caused the aircraft to pitch nose down against the will of the pilots. The problem is that those commands should never have been issued, and caused the aircraft to crash.

March 10, 2019, Ethiopian Airlines Flight 302, also a 737 MAX 8, went down under similar circumstances, killing all 157 people aboard. Flight 302 also reported erroneous nose down commands.

Boeing’s 737 MAX 8 was grounded for months, and production was halted. As of this writing (Februray, 2020), there is no timeline to lift the grounding, and orders of the MAX 8 have flatlined. Boeing planned for sales of the MAX 8 to account for 33% of the company’s revenues for 5 years.

In addition to the indescribable tragedy of losing hundreds of human lives, errors related to the 737 MAX have cost Boeing tens of billions of dollars.

The Boeing Starliner Capsule

One of the bugs caused the mission clock to be off by 11 hours, which tricked the software into behaving as if it were in an “orbital insertion burn” phase, consuming too much fuel. That error made it impossible to dock with the IIS as planned. The capsule’s mission was aborted, and it landed safely, but before reentry, engineers discovered another bug that affected the thruster firings needed to jettison the Starliner’s service module safely. Either bug could cause the loss of the Starliner Capsule and the lives of its crew.

Toyota’s 10k Global Variables

Philip Koopman, a Carnegie Mellon University professor in computer engineering and safety-critical embedded systems specialist, testified that he found over 10,000 global variables in Toyota’s software.

Bugs Hurt Everybody

Expenses pile up from increased demand for customer service, increased rework from bug fixes (which can increase software development costs 30% — 100%), and fewer social recommendations.

Bugs hurt your conversion rates and new user acquisition. If your users aren’t recommending you, your product growth will lose steam. You need to maintain minimum recommendation rates and minimum conversion rates (collectively known as viral factor, or k-factor), or your product will slip into exponential decline the moment the marketing spend stops.

Buggy products aren’t viral. Products that aren’t viral can only be sustained by continually burning marketing dollars to keep the product selling. Eventually, your product will reach market saturation, and sales will taper off, even while maintaining marketing spend. The result is a slow death spiral.

Viral products market themselves, and that saves you mountains of money.

Key Takeaways

  • Patience is everything.
  • Slow is smooth and smooth is fast.
  • Engineering teams frequently spend more than half their time on rework.
  • Investing in training and quality processes can help you ship faster.
  • When an assembly line jams, you don’t push more product through, you clear the jam.
  • Track and improve your defect rate.
  • Identify rework hotspots in your codebase and fix them.
  • Happy developers are more productive.
  • The worst thing to do is push harder.
  • Don’t reprimand employees you want to keep.
  • Time pressure, unrealistic expectations, and poor code quality are top causes of developer unhappiness.
  • Pushing harder makes developers slower and more likely to write bugs.
  • Favor regular, supportive 1:1 meetings over “performance review” meetings.
  • Listening is key.
  • Support developers in their assigned work, skill progression, and career progression.
  • Empathy is the best way to show developers you care about them as people, and that makes them happier and more productive.
  • Bugs are extremely expensive. Low quality software can cost more than double to develop than high quality software.
  • Bugs expose companies to liability and severe product delays.
  • Bugs have a severe impact on product growth and marketing costs.
  • Viral products market themselves, and that saves you mountains of money.

Next Steps

Members of get all 5 hours of TDD training included along with access to training on JavaScript, React, Redux, and software design best practices. Buy it for your whole team. It only takes a few hour’s worth of cost savings per employee to pay for itself.

Want to pay with a single invoice? Let us know how many passes you want to buy, pay the resulting invoice, and we’ll send you a link your employees can use to activate their accounts.

Eric Elliott is the author of the books, “Composing Software” and “Programming JavaScript Applications”. As co-founder of and, he teaches developers essential software development skills. He builds and advises development teams for crypto projects, and has contributed to software experiences for Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC, and top recording artists including Usher, Frank Ocean, Metallica, and many more.

He enjoys a remote lifestyle with the most beautiful woman in the world.

JavaScript Scene

JavaScript, software leadership, software development, and…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store