Back to resources

How to Prioritize Engineering Work When Everything Is Important

Prioritization
Agile / Scrum

15 July, 2021

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

Prioritizing as Your Start-Up Scales
21 July

Trey Tacon, Senior Director of Engineering at TeamSnap, knows that making the right moves early on can mean the difference between failure and building something that changes the world.

Scaling Team
Prioritization
Mission / Vision / Charter
Trey Tacon

Trey Tacon

Senior Director of Engineering at TeamSnap

What to Do When Joining a Non-Structured Team
19 July

Bogdan Chebac, Engineering Manager at Gorgias, talks about a stressful situation of handling clients and ample work pressure side by side.

Agile / Scrum
Health / Stress / Burn-Out
Team Processes
Bogdan Chebac

Bogdan Chebac

Engineering Manager at Gorgias

Moving From Cowboy to Agile Delivery
15 July

Catalin Stoiovici, Head of Engineering Delivery at Capco, shares how he helped his team transition to a more mature operational practice and replace their ad hoc, cowboy style of delivery with Agile.

Scaling Team
Career Path
Agile / Scrum
Team Processes
Catalin Stoiovici

Catalin Stoiovici

Head of Engineering Delivery at Capco

How to Prioritize Engineering Work When Everything Is Important
15 July

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.

Prioritization
Agile / Scrum
Joao Esteves

Joao Esteves

Director of Platform Engineering at Workhuman

Rational Agile
15 July

Anya Yudkovsky, Vice President of Engineering at GoCanvas, knows that not all implementations of the Agile methodology are perfect.

Agile / Scrum
Anya Yudkovsky

Anya Yudkovsky

VP of Engineering at GoCanvas

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.