Engineering Productivity Is Critical
Software engineering leaders need to hire, organize, manage and lead talented and productive engineering teams. A productive team is capable of ideating, innovating and ultimately delivering what the business needs at the time it needs it.
Software Engineers are well-paid professionals and often represent the life and blood of the organization, but also one of the largest cost centers in the budget. For that reason, there is unavoidable scrutiny on the productivity of every engineering team and the allocation of its resources.
Unless the scrutiny is extreme and becomes a distraction, nobody should take it as a sign of distrust. It is a manifestation of a healthy corporate self-awareness that every business needs. It might feel uncomfortable, but it is a necessary evil.
Besides, scrutiny is not limited to Engineering. All functions and departments have perhaps uncomfortable but always necessary measures of productivity and success. In the most basic terms, results must always be compared with goals. When goals are accepted, they become expectations. If the results of a team meet or exceed expectations, it is a success. Otherwise, it is a failure.
For sales, success is measured comparing revenue and quotas. In marketing, success is commonly measured comparing leads generated with goals. Engineering is a bit different; ideally, success would be measured comparing the quantity and quality of software shipped with goals. The problem with measuring amount and quality of software produced is that one number cannot easily represent it. That’s where things get tricky.
Since there isn’t a perfect measure, Engineering scrutiny is commonly done in different ways, some better than others. Here are a few examples:
Scrutiny Informed By Business Success
A very high-level form of scrutiny is based on the market success of the output of the engineering team; This measure is arguably the ultimate test, but it takes a while to evaluate, it is difficult to quantify and does not focus on engineering alone.
In theory, the idea is simple: If the team generates software that consistently satisfies the needs of the business, and does so at a sustainable cost, then you could argue that the engineering team is successful.
The flaw with this lens alone is that there are many variables at play. For example, it is conceivable that a fantastic engineering team working with a terrible business team could fail this form of scrutiny, even if the issue is not in engineering.
Similarly, you could have a mediocre engineering team and brilliant sales and marketing teams. Together they might be able to generate money, even if the engineering side of the organization is struggling.
Scrutiny Informed by Commitment vs. Deliverables
In well organized and mature engineering teams, developers are asked to set goals and fulfill their commitments. The results are carefully tracked and studied over several weeks or several months. Success trends get measured with clear metrics and, over time, they paint an explicit picture of reality.
In Scrum teams, the work is split into stories and carefully estimated with “story points,” which is a relative measure of effort. Developers periodically commit to getting a set of stories done in a defined period called a Sprint, and then they work to realize that commitment.
As a result, over time the data regarding commitments and delivered value starts showing trends. Those trends inform the business if the development team is well functioning and if it is generating a predictable and sustainable output.
A predictable output should be a primary aim of every engineering team. It allows the organization to plan and evaluate the Return on investment. Used as a rudimentary gauge of an investment's profitability. More of projects, products, and features. Without a predictable output generated by the engineering team, an organization flies blindly in a world of uncertainty.
It is a good sign when a development team consistently achieves most of its sprint commitments and when its velocity remains stable or increases. It is not a perfect measure of productivity, but it is as good as it gets when reinforced by other means and observations.
Scrutiny Informed by Perception
Another type of engineering team scrutiny of productivity is rooted in perception. Perception and assumption are unhealthy and can enter the equation in an organic, sneaky and less scientific way.
If you’ve been in the software industry for a while, you know how this manifests in practice. Somebody walks the engineering space at 6 pm and notices that the office is empty. Alarm bells go off because the observation clashes with several ingrained expectations:
- Software Engineers start their day late and like to work at night.
- Software Engineers are solitary creatures who, in their natural habitat, regularly work 60-70 hours a week.
- The more hours an engineer works, the more stuff gets done.
The natural reaction when those expectations are not met is to think that engineers are not pushing as hard as they could. This perception becomes particularly acute when the engineering team is falling behind on critical deadlines.
I am going to focus on this last form of scrutiny because is insidious, uncomfortable, and nobody wants to talk about it. When nobody wants to talk about something, I want to talk about it even more. That’s how I am wired; call me a troublemaker, if you like.
As you know by now I like stories; let’s start with a fictional but realistic make-belief situation.
You are visiting the offices of a small software company that your client intends to acquire. You are in charge of taking an initial look to evaluate the engineering organization. It is a surprise visit. They are not expecting you.
You are greeted by the CTO who informs you that the engineering team is under considerable pressure to get a significant project done. They have a few months to finish, but things might go longer than expected. The project seems to be late, and management is getting nervous.
The following is what you see:
Case 1: The Development Pit
The building is old, made of bricks and has a musky smell. It is 9 pm when you walk the offices. You see a door with signs that say, “Geniuses at work,” “No talking past this point” and “Caffeine 2 Code transformation room”.
You open the door and enter a small, dark and messy space with open tables. Behind each of the desks, there is a guy in a hoodie, hunch over a laptop connected to two large monitors.
Most of them are typing furiously with very focused but tired expressions. One of them seem angry, and keeps on swearing and hitting the keyboard. Many of them look worried and stressed. Two are debating something that seems very important; it has something to do with refactoring and branching strategies.
You notice pillows and blankets thrown on the floor, fast-food wrappers and soda cans everywhere. It looks like these guys do not go out often, and some of them seem to be regularly sleeping in the office. In fact, one of them is sleeping in a corner right now. Looking at his computer, you notice that a compilation job is running, and realize that the developer is taking a nap while waiting for the compilation to complete.
Perceptions of the Development Pit
You can choose to interpret this scenario in different ways, depending on your background, how long you’ve been in the industry, your past experiences, what you do for a living, your age, your upbringing, and your way of working.
The Hard-Working Heroes Perception
You could decide to think that these Engineers seem to work hard, busting their rear-ends for long hours. They seem to be dedicated entirely to their craft and the mission of the company.
You can figuratively and sometimes literally see the sweat and blood they are pouring into their keyboards. They sleep under their desk, and never see the light of the sun. They do not waste time taking care of themselves. All they do is work, work, and work some more. You could decide that it is an excellent thing for the company and that it should be encouraged.
The Immature Frat House Perception
A different interpretation is that the Development Pit is like an immature frat house; nobody ever wrote quality code in similar working conditions. The engineers in this company are probably freaking out under enormous pressure. Alternatively, they could be very young, inexperienced and most likely wasting time. In either case, they are probably not very productive.
People working this way are shoot-from-the-hip hackers who don’t follow any process and produce mediocre results during sleepless nights fueled by caffeine. When they burn out, get bored, or get fired, they move to something else and start all over again.
The fact that the team is still coding at 9 pm, probably means that the engineers slept until noon. The fact that they seem so busy doesn’t tell you that they are working hard all day. Perhaps they spend the majority of the day playing games, surfing the web, or writing a novel.
Case 2: The Balanced Development Space
Let’s look at a different version of this story:
It is 5 pm. You enter a brightly lit office space full of gray cubicles. It is not the cleanest space you’ve seen, but it looks professional.
Some people are starting to leave the office. You can see them wave their hands as they head out. You hear them say, “Talk to you later” or “see you tomorrow.”
There are some empty cubicles while others are occupied by developers working on their computer. A few engineers are brainstorming at the whiteboard, drawing flowcharts and discussing data structures and algorithms.
At close inspection, you notice that people are coding or discussing what sounds like the architecture of software systems. You also observe that some of the cubicles dwellers are wearing headphones and are talking to other people through a video conferencing system. There is a quiet and professional energy in the room.
You stick around a little while, and more people go home. At around 6 pm the room starts looking deserted.
Perception of the Balanced Development Space
Again, you can choose to interpret this scenario in different ways.
Lack of Passion & Sense of Urgency Perception
You can choose to believe that the engineers do not seem to have any sense of urgency. They seem relaxed and lack energy; probably they come in late and go home early. They also probably don’t think about work until the next day.
People don’t seem passionate about their work, or at least not willing to make personal sacrifices. They are not the type of people who would sleep under their desk; when they have to choose between “life” and “work,” they choose “life” every time. They could and should work harder, especially when a project is late.
Mature Professionals Perception
A different interpretation is that those Engineers are mature professionals doing their jobs. They have families, and they know how to balance work with everything else. They leave at 6 pm, but they might be in the office at 7 am. When they go home, they have dinner with their family and then work from home if there is stuff to finish or if it is crunch-time. Their disciplined and orderly approach doesn’t represent non-commitment; it represents maturity and experience.
Ok, Now What?
Which perception is right? Which one is a fallacy? What can you do to tell if there are perforce issues in engineering?
In my experience, reality, passion, intent, and productivity cannot be measured based on casual observations about working habits, schedules, and appearances. For a software developer during an intense code-writing phase, the office is where their computer is. Laptops, video conferencing and a ubiquitous internet connection made developer’s mobility a reality that was impossible years ago.
Older engineers with families tend to be more poised and measured. They know when to take breaks, and know that burning-out won’t help. Younger developers tend to go all in and have no problems sleeping under their desk if they have to. Both can be very productive or very unproductive, or anywhere in between.
General Observations About Real and Perceived Productivity
The topic is complicated, and I recommend that you avoid the fallacy of making assumptions without evaluating at least a couple of data points.
During my career, I paid attention to patterns that I am going to share with you. My observations are not scientific but are based on personal experience accumulated in 30 years in the industry.
Working Long Hours Doesn’t Translate to Productivity
I’ve seen many developers sleep under their desk, but I have never seen a highly productive one do it. I am sure they exist, but I am also sure that they are rare.
Being in the office 18 hours a day is not a sign of productivity or passion. It is a sign of distress, lack of confidence, poor planning, and poor estimation. True productivity looks balanced, not frantic. Hours in the office are easy to accumulate and show off, regardless of how the time gets spent. Results are what counts.
Productivity Feels Like Focused Excitement
When you are in the presence of a development team that is on a critical mission, you can feel the energy in the room. It is not loud, and it doesn’t look like desperation or chaos. Those elements might exist but depend more on personalities than productivity.
True productivity feels like focused excitement.
Engineering Burnout Is Bad For Business
I have never seen a developer work 16 hours a day for months and stay productive or produce quality work. Burnout engineers are not high-performers, they create a ton of technical debt, and they won’t stay around very long.
If you notice that a development team is working an unhealthy schedule for long periods of time, you should be concerned. Not just concerned for the people, but also concerned for the quality of what they are building.
The cost of heroic behaviors is hidden. The aftermath is visible only much later in the form of reduced software quality and high employee churn.
There is a Point of Diminishing Returns
Everybody is different, but in general, the productivity of a focused developer drops after four hours without breaks, and after eight to twelve hours with breaks. Past that point, most developers reach a state of diminishing returns.
A developer who is mentally exhausted starts making serious mistakes. Feats of all-nighters might get the job done in time for an aggressive deadline, but often the quality of the results is meager.
A-Players Focus On Results, Not Perception
I have observed a strong correlation between productivity and attitude toward work schedule, but not in the way you might be thinking.
Confident A-players are not concerned about other people’s judgment of their productivity based on schedule or number of hours in the office. They are focused on getting their work done. What others think is not a top-of-mind concern. They make a statement with demonstrable and tangible results and high-quality software. They do not believe that a pillow and a blanket under their desk translates to positive outcomes.
Words Are Cheap
When someone doesn’t miss an opportunity to tell you how hard they work, take a good look at the results. More often than not you’ll find that they are not more productive than other more humble people. I don’t remember observing any exception.
Words are cheap and easy to throw around. Results are what matters. Productive people do not feel the need to tell you every day how productive they are and how hard they work. They just do.
Fashion Choices Are Irrelevant
I have never observed a correlation between appearance, fashion choices, and productivity. Great developers sometimes wear a dirty hoody; other times wear nice, clean, and ironed brand-name clothes. Most of the time they want to be comfortable, but that doesn’t always mean dirty; that’s just an old stereotype.
Productivity Is Predictable
Estimating how long is going to take to get some development work done can be difficult, even for experienced developers. Some engineers tend to underestimate; others tend to overestimate, most of them are all over the place.
That said, productive developers on average tend to be better at estimations than unproductive ones. The reason is that they are consistent producers of solutions, they plan and can rely on their plans and consistency. A team of several productive developers observed as a whole is especially good at estimations.
For this reason, teams that tend to fulfill their goals are also the most productive ones. Not only because they meet their goals, and so the goals and the results match, but also because they produce a more sustainable and prolific output.
Schedule Observations Fallacies
If you believe that someone who leaves the office at 7 pm works more hours than someone who leaves the office at 4 pm, you are making assumptions.
- Working 7 am to 4 pm, or working 10 am to 7 pm is the same number of hours. You need to know when somebody gets in the office before using out-of-the-office habits as a measure of time at work.
- Many developers work from home off-hours. Some do it “loudly,” meaning that you’ll hear about it, while others do it “quietly.”
- Just because somebody is around and looking busy, it doesn’t mean that they are productive. It is easy to waste time while sitting at the desk appearing busy.
Other Bad Measures Of Productivity
Whatever you do, resist the temptation to assess the productivity of a developer or a team using the following measures in isolation:
- The number of check-ins per day/week/month.
- Lines of code written per day/week/month.
You might think that’s crazy, but I’ve seen it done by well-intentioned and misguided people.