How to Prioritize Engineering Work When Everything Is Important

Joao Esteves

Director of Platform Engineering at Workhuman



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.

"One of the biggest challenges that most managers face is prioritizing the work that matters on a day-to-day basis."

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.

"Where did all of the work come from?"

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.

Be notified about next articles from Joao Esteves

Joao Esteves

Director of Platform Engineering at Workhuman

CommunicationOrganizational StrategyDecision MakingEngineering Management

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


HomeCircles1-on-1 MentorshipBounties

© 2024 Plato. All rights reserved

LoginSign up