Back to resources

How to Prioritize Engineering Work When Everything Is Important

Prioritization
Agile / Scrum

15 July, 2021

Joao Esteves

Joao Esteves

Director of Platform Engineering at Workhuman

Joao Esteves, Director of Platform Engineering at Workhuman, shares his experience on prioritizing tasks that effectively affected his team's success and engagement and his role as a leader.

Problem

One of the biggest challenges that most managers face is prioritizing the work that matters on a day-to-day basis. Most of them are used to prioritizing work either within a sprint or using agile methodologies. Stepping up to be a director or a senior manager means that you might be getting an influx of strategic initiatives, especially if you are in an area that gets many requests from outside or within the organization. Sometimes, it is hard to manage all those requests unless there is a process or framework to handle that.

From my experience, I had a data team reporting to me, which was pretty new and small. They had merely started by implementing a datalake to ingest information from all the systems of the organization. Once all the teams of the company realized the value of it, suddenly we had about 17 people asking us more questions about the system. It did cause a lot of confusion in the team to cope with the demand that they had, and at the same time, they didn’t feel empowered to say no.

The biggest challenge was that the team did not know which requests were more critical or highly prioritized. Furthermore, who should guide them by saying that something was more important than the other? This led the team to feel that they did not grasp the prioritization framework and what they were doing.

Actions taken

My first approach to the problem was asking the team a simple question: where did all of the work come from? Their reply to the question was that the work came from everywhere — all the departments.

Sometimes having to escalate those questions or queries to the senior management was not a great situation to be in. I worked on resolving the problem. Since I knew where all the problems of the work were coming from, I worked towards that. I communicated with every team or people necessary to come to an outcome. And, communicating effectively was the glue that helped us stick everything together.

Best of all, the team knew what needed to be done. The obstacle in the middle was that they lacked a method to measure, which was more important than the other. In companies that are exponentially growing every day, it could be seen that the importance of every task changes every week.

We created a request funnel, where the heap of requests would come in, and the system would ask them questions in a detailed form. Answering those questions helped the team get a clear idea of what to expect from the problems and finally prioritize them for that reason. It was actually funny because what sounds like common sense did hit us hard from multiple directions. However, when we are in small companies and trying to scale, we had to use some framework, and in our case, this worked great.

We used a weighted matrix for prioritization to react to changes quickly. We had some dimensions where we saw something coming in, and we would immediately look at the pros and cons of implementing some changes. We started by attributing value to all the diminutive dimensions, and in the end, they would get a score that helped them prioritize efficiently. If we did this for every large request that came in, they could compare those requests and prioritize accordingly.

That, in turn, helped them to go back to the stakeholders and explain the roadmap. It was a concrete way of justifying the order of things they were going to do and why they would do it in a certain way. Finally, it became our process to explain ourselves better. Since we created a priority funnel, they now knew better as to what was more significant and beneficial for the business.

Many companies do QBRs and have them ingrained in their processes, which is undoubtedly a great idea to stay in tune with everything. Nonetheless, it is important to revise priorities proactively. Although it depends on the size of the company, how fast it is growing, and how extensive the array of stakeholders need to be informed, these are some aspects to not fail out on.

Lessons learned

  • Product managers need appropriate tooling to manage requests, in the same way that teams use jira for managing their software delivery lifecycle. Slack or other private messaging channels should be avoided in this case, while emails can be a more appropriate trigger for a conversation. However, having a tool to capture such requests formally is actionable.
  • If problems come in from multiple sides, have the right metadata for the submitters to record them. Simple details like the urgency, who had requested it, and who it would impact from it can help in the prioritization matrix.
  • Try to understand the problem that the business needs to solve, rather than having people describe to you a solution. Most people might think that it can be solved by giving the engineering team a solution, but they might not see the complete insights of how it can be done in reality. It just goes by the saying, "if I had asked people what they wanted, they would have said faster horses" - by Henry Ford.
  • Assign at least one product owner persona to manage each product backlog because the concept of ownership in an area and someone taking care of project intakes and strategic business needs is very hard. Instead of having one product strategist doing it for multiple areas, it makes more sense to have different people with adequate cognitive load to be accountable for.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Product
Dev Processes
Conflict Solving
Internal Communication
Collaboration
Convincing
Strategy
Prioritization
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

The Optimization and Organization of Large Scale Demand

4 May

Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.

Managing Expectations
Delegate
Team Processes
Prioritization
Kamal Qadri

Kamal Qadri

Head of Software Quality Assurance at FICO

The Necessary Structures of Time Management

14 April

Suryakant Mutnal, Engineering Manager at PayPal, discusses the importance of time management and the necessary structures in order to create internal consistency.

Goal Setting
Managing Expectations
Remote
Deadlines
Productivity
Roadmap
Prioritization
Performance
Suryakant Mutnal

Suryakant Mutnal

Engineering manager at PayPal

Shortening the Feedback Loop to Improve Collaboration

4 April

Rui Ferreira, Change Agent at Independent, describes how he structured a feedback loop between cross-functional teams.

Internal Communication
Productivity
Feedback
Prioritization
Health / Stress / Burn-Out
Rui Ferreira

Rui Ferreira

Change Management Expert at Typeform

Destressing the Software Delivery Cycle

4 April

Rui Ferreira, Change Agent at Independent, shares his experience destressing a team by delivering high-quality software on a consistent basis.

Customers
Users
Team Reaction
Prioritization
Health / Stress / Burn-Out
Rui Ferreira

Rui Ferreira

Change Management Expert at Typeform

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.