5 productivity questions answered by engineering leaders

5 questions and answers on engineering productivity


The never-ending need to quickly ship code and update products can be daunting. The drum-beat of deadlines never ceases to pound. It’s critical to combat productivity issues and help your team understand roadblocks, both for their potential and the success of the business. After all, that’s the mark of a great manager. Most important is to find solutions that work in the long-term, not just your current sprint or project. 

If productivity were easy, no one would ever talk about it. There is no magic bullet, no one-size-fits-all solution that will transform a team. In fact, many of the suggestions presented here come with the same caveat: it depends on your team. What works for a startup might not work for an enterprise. What motivates a group of mature, veteran engineers isn’t going to have the same effect on those early in their career. With that in mind, here are the answers to five questions about improving productivity.

What should you measure?

Productivity can only result from the identification of a goal and the steps it takes to reach that goal. The goal comes first, the measurement second. So what is your goal? A common dissonance that hurts productivity is when engineering teams lose track of the company's goals and start to focus on goals that look important on paper, but ultimately don’t lead in the right strategic direction. Developers need to see themselves as part of the business, not just part of the engineering team. 

To that end, it’s better to focus measurement on features instead of points or even the number of pull requests where, frankly, the achievement can be arbitrary. Outputs that affect the business, help sales, satisfy customers, are the ones worth measuring.


How important is customer feedback?

Speaking of customers, turns out they’re one of the keys to productivity. Five, ten years ago, there was this buffer between the customer and engineering where developers pushed out releases and products and the customers just accepted them. For several reasons, perhaps the ubiquity of software products, better UX, or just better business practices, customer feedback is integral to building software products today.

Customers drive productivity in the features they request. Whether in a survey, a new ticket, or spending habits, they have their thumb on usability and care only about the experience. Customers direct your time to solve real problems and deliver new features. 


How do you improve cycle times?

Cycle times are a great measurement of productivity, especially when they’re feature-driven. But how do you make them faster? Some solutions reveal themselves in the midst of the cycle. Pay attention to bottlenecks, roadblocks and rework, especially at the developer level. Which members of your team are struggling the most and in which parts of the workflow? Does the engineer need more training? Collaboration with other developers who can check their work? Maybe their strengths aren’t being utilized in the right areas and could be more productive working on different tasks.

There are three levels to looking at cycle times and productivity. Tools, processes and culture. At the base level, a CI/CD tool roots your team in a common system. And processes establish expectations about timelines and workflow. Finally, culture fosters communication and responsibility. When you have all three, productivity and faster cycle times follow.

Should you stick to a specific framework?

With a number of development frameworks you could follow—scrum, agile, etc.—how do you know which to choose? And after you’ve decided, how rigidly do you follow it? Should you be dogmatic or pick and choose the bits you like from each and assemble a piecemeal framework?

Here’s where the makeup of your team really comes into play. With a younger, inexperienced team, strict adherence to a framework might be an advantage. You can track progress easier and create rote processes to ensure work gets done. With a more mature team, you could keep things looser. Above all, pragmatism should guide your frameworks. Be disciplined enough to follow a methodology and flexible enough to make changes to accomplish the job.

How do you balance communication with letting developers work uninterrupted?

Engineers tend to like deep work, headphones on, cranking away at code. Even if that stereotype is a little dated, each interruption still takes precious time, not just for the immediate pause but the time it takes to get refocused. How then, do you create a collaborative culture while still giving the team time for focused work? 

To start, give your team autonomy to set their own schedules. Let them block out time on their calendar to work uninterrupted. As a team, does it make sense to set meeting-free days? Or something clever, like a lightbulb on a desk or a Slack icon that means “do not disturb?” Creativity may help you strike a balance, but so will formality. Don’t hesitate to set up processes that account for deep work.

Get started

These 5 questions are a great place to start your productivity improvement, but it’s important to remember that every team is different. Likewise they will have their own unique needs when it comes to building trust, process improvement and listening to customer feedback. The important part is to get started by asking your team what they need to be successful, testing different approaches and fine-tuning as you progress.