Blog details

destroy your engineering team productivity

Ways that destroy your engineering team productivity

July 05, 2019

A lot of articles address the role of technical leaders and engineering managers. One common theme we often come across is how to increase a team’s productivity. But before you focus your energy trying to increase their productivity, you might first want to consider what’s destroying it, to have a sound base on which you can build. Unfortunately, even though Peopleware was published almost 30 years ago, we see lots of teams suffering from huge productivity loss in some (negatively) remarkable ways!

No one expects an engineer to get work done without access to a computer, but there are many companies that expect engineers to get work done without access to their mind. This is equally unrealistic.

So let’s deep dive into our list of things that prevent your engineers from getting “into the zone” and being productive. I will try to prioritize this list from most to least impactful.

If you’re wondering if all this is worth the investment, just consider the engineer’s salaries. Even 10% more productivity is a LOT!

1) Interruptions & Meetings

Interruptions are the top productivity killer for engineers, in my mind. Engineers can’t easily go back to where they were right before an interruption. They need to get into the mindset for development and then slowly trace back to where they left off. This can easily take more than 30 minutes. And the more interruptions, the more frustration, the less quality work, the more bugs — and it goes on.

“The more times you trip me up while I’m trying to get started — the longer between each time I’m going to try. If you fill my morning with interruptions — don’t be surprised when the day is unproductive.” -a developer on Reddit

What about meetings? The only difference between a meeting and an interruption is that a meeting is a planned interruption, which makes it even worse. Engineers can’t progress on a task if they know that they will have an interruption while working on it. So if they have a meeting in one or two hours, they will not be able to progress on anything, as most engineering tasks take more time.

As Paul Graham wrote, “A single meeting can blow a whole afternoon by breaking it into two pieces, each too small to do anything hard in.”

How can this be avoided? Our suggestion is to use a data-driven method like Waydev and have a meeting only one time or twice a week, Monday or Monday and Friday, in order to let your engineers work and you, as an engineering manager look daily in your data-driven solution, in order to check your engineers’ output.

2) Micro-Management

Of the different types of managers, micro-managers might be the worst in terms of the engineers’ productivity. Sure, micro-managers tend to have more meetings and unplanned interruptions. But it’s not only that. They show a lack of trust, and by doing so, you feel they constantly undermine your skills and your ability to get things done. Any motivation a developer had between interruptions will be just gone at that point. The impact goes beyond productivity. Micro-managers might be the first reason for engineers to leave, or at the very least, to change teams.

3) Vagueness

There are many ways to illustrate vagueness. Bug reports like “It’s broken, fix it!” don’t have enough information for engineers to work off of. By the way, having a bug report template can help in that case.

Or unclear specification on a feature, in which case engineers will start implementing what feels right to them before they have to start again from scratch once the manager better details the expected behaviour.

Unclear prioritization also belongs in this category. The time that a developer spends wondering if they are working on the right task can so easily be avoided. And if ever they get a comment from the manager asking why they worked on this particular task (while priorities were not defined)…well, you get it — a lot of frustration…

4) Seagull Management

Have you ever heard of it? It happens when engineering managers are totally uninvolved in the work, but… they just swoop down once in a while to shit all over everything. “This is wrong, and this, and this looks bad,” etc., before flying away again. I have to admit I loved the image, but unfortunately, this happens more often than we would like it to. This behaviour is deeply frustrating to engineers; they won’t be able to get back in the zone in the next few hours, and sometimes not even for days.

5) Credit Greediness

Have you ever had an engineering manager or other engineers who took all the credit for the work you have done in the past weeks? Engineers value competence above all. Taking the credit for someone else is taking the other’s competence for yourself and removing it from him or her. This is pretty high up on my list, as I feel it creates so much tension that it just destroys the whole engineers’ productivity for quite a while.

6) Environment — Noises, Motion, Workspace Design…

This might seem strange to non-engineers, but the environment in which engineers work has an important impact on their activities. For instance, having some white noise — loud AC, hearing cars and trucks roll by — helps them focus better. That’s why so many of us put headsets on! I actually just discovered RainyMood — really great!

Similarly, if the workspace is designed to have as much motion as possible, that won’t help them focus! Or having the desktop computer screens oriented in such a way that they are highly visible to the managers…well, that creates some extra stress and even more opportunities to be interrupted.

7) Scope Creepiness

Scope creep (also called focus creep, requirement creep, feature creep, and sometimes kitchen sink syndrome) in project management refers to uncontrolled changes in a project’s scope. This can occur when the scope of a project is not properly defined, documented, or controlled.

Scope creep turns relatively simple requests into horribly complex and time-consuming monsters! And most of the time it happens during development! For instance, for a simple feature:

  • Version 1 (before implementation): the feature is “Show a map of the location”
  • Version 2 (when version 1 almost finished): the feature is changed to “Show a 3D map of the location”
  • Version 3 (when version 2 almost finished): the feature is again changed to “Show a 3D map of the location that the user can fly through”

8) Product Definition Process

So this one might seem strange at first glance but is actually pretty easy to understand. If a product team defines its team’s priorities without ever validating (through customer feedback or any other means) the interest of the corresponding features, and the engineers see that most features are eventually just not used, they will feel that what they do is useless and will lose their motivation. We all want to feel impactful, and that may be even more important to engineers!

9) Lack of Consideration of Technical Debt

If you look at this Stripe survey, more than 30% of the week work is on technical debt. Technical debt is a deliberate decision to implement a not-the-best solution or write not-the-best code to release software faster. Taking on some technical debt is inevitable and can increase speed in software development in the short run. However, in the long run, it contributes to system complexity, which slows the engineers down. Non-engineers often underestimate the loss of productivity and are tempted to always move forward, and that becomes an issue. But if refactoring is never part of the priorities, it will not only impact productivity but also product quality.

10) Tool Multiplicity & Hardware

Engineers use many tools to program, push and merge their code every day. The more automation, the better. It goes without saying that if you use “ancient” tools, this will impact your productivity. Similarly, having a big screen vs only a laptop can have an impact. Given the cost of hardware and the developer’s salary, having just a 5% engineering productivity gain is definitely worth an investment on that point! Just give the tools and hardware that your engineering team prefers (individually for hardware, but as a group for the tools).

11) “How” Documentation

When learning how to code, we were told to comment early and often. The idea is that it’s better to have too many comments than to have too few. Unfortunately, many engineers incorrectly interpret this to mean that they must comment every single line of code, which is why we often see code like this (from Jeff Atwood’s post on “Coding Without Comments”):

r = n / 2; // Set r to n divided by 2
// Loop while r — (n/r) is greater than t while ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)}

Do you have any idea what this code does? Me neither. The problem is that while there are plenty of comments describing what the code is doing, there are none describing why it’s doing it. If there were a bug in the program and you stumbled across this code, you wouldn’t know where to begin.

12) Impossibly Tight Deadlines

This last one is linked to the tendency of engineering managers to ask engineers for estimates, then push them to lower those estimates as much as possible, and then magically consider them as deadlines! Managers will even consider that, as the developers themselves “decided” on the estimate, they committed to the deadlines, and therefore the deadlines should be considered valid enough to be shared to upper management.

Not surprisingly, engineers feel that those deadlines are unreasonable and arbitrarily tight; this creates tension and an inability to focus.

How are all those things unique to engineers? If you look at all things, they are actually pretty common to most other project-based jobs. It’s just that the impact of each of these is even more important for engineers, as they need deep focus to progress on their tasks.

If you recognize some points mentioned above within your company, it might be interesting to address them with your engineers. Talk to them; find out if these are an issue and how it can be resolved. Whatever they say, the most important thing is to trust their feedback and insights. And while today’s technology is very different from 30 years ago, the lesson is still the same. You can’t ignore the human factor when you consider team productivity.

Iterate on your processes, environment and work habits with your team, and let them guide you on how to have the highest productivity and impact.

Inspired from here: https://anaxi.com/blog/2018/10/15/top-12-things-that-destroy-developer-productivity/

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.