Ben BiranFollowBetter Programming--1ListenShareIn this series, we’ll explore how transferring prioritization responsibilities from product to Engineering leaders can unlock enhanced team velocity. We’ll first delve into the main benefits of employing this change. Subsequent posts will discuss how to assess the suitability of this approach for your team and offer practical steps to get started.When I joined Zapier as an engineering manager (EM) on the Interfaces team in October 2022, I was focused on organizing the work in our Jira board and setting up automation to streamline the software development lifecycle. The team was small (two full-time engineers and one contractor), and I was tasked with setting up a process that would keep us nimble and focused on shipping speed.At the time, Interfaces was in alpha, fresh out of ZapConnect, where the product was announced. We only had a dozen free users, and we were focused on building the minimum viable product (MVP).I asked Luke Thomas, the team’s lead product manager (PM), if he’d let me pilot a process I had used with previous teams I managed. The process was different from how other teams at Zapier moved. As an EM, I would own the prioritization work. Rather than Luke maintaining the Jira board, I would decide which tasks took precedence.While Luke would still provide the broader direction, I would sequence the tasks in a way that optimized the team’s efficiency. This approach would immediately shift certain decisions, such as the amount of tech debt to address each week and even the feature build sequence, from a product-centric responsibility to one fulfilled by engineering.Luckily, Luke was game for trying. It was a win-win. “I was stoked when Ben volunteered to own Jira and related processes,” he recalls. “Managing Jira was already a source of organizational heartburn for me. I wanted to spend most of my time talking to customers and determining the most important projects.”Spoiler alert: This process has worked extremely well for the Interfaces team, and we’re continuing to iterate on it. As Luke puts it, “Our output went way up, and frustration went down. I strongly recommend exploring this with your team if you are a PM.”Earlier in my career as a software engineer, I was inspired by a blog post I read, “The Product-Minded Software Engineer” by Gergely Orosz. In the post, the author posits that product-minded engineers have a greater impact. Their unique perspective is highly advantageous thanks to their deep understanding of the product’s purpose and robust engineering expertise.By always considering the why and offering product ideas that account for both engineering tradeoffs and maximum product impact, product-minded engineers significantly influence the team, business, and product success. If this is true, I thought, then there’s a compelling opportunity to reimagine the traditional relationship between engineering and product to create more efficient collaboration and processes.My transition to engineering leadership allowed me to test this hypothesis. My first role as an engineering leader was overseeing the software team at a robotics startup in New York. We were working on an MVP for a hardware product — a six-degrees-of-freedom robotic arm controlled via a web application, and it made sense to organize into Software and Hardware teams, each with product and engineering business functions.The founder took on the Hardware team, and I was responsible for the Software product and engineering side. This non-traditional, hybrid engineering/product role required me to level up my product skills and experiment with applying the product mindset within engineering. I had to structure the team and its processes to maximize efficiency and velocity.What we ended up with wasn’t a conventional engineering team by any standard, but it worked — in just one year, we built a robot and onboarded our first customer.What became clear to me at the time was that the relationship between product and engineering is not a one-size-fits-all. Traditional software development models place the onus of prioritization on the shoulders of product managers. They decide what gets built, in what order, and when, leaving engineering to handle the how. But this model isn’t sacrosanct, and the blurring of lines I’ve described offers a glimpse into an alternative approach.In my current role on the Interfaces team, I’ve come to appreciate the unique value of expanding the scope of engineering roles even more. Including responsibilities traditionally held by product managers might seem unconventional, but it’s undeniably beneficial.Operating with a product mindset within engineering has boosted our team’s velocity, accelerated our learning pace, and strengthened our team culture. In just seven months, we quadrupled the team size. We brought new members on board and had them shipping code within their first two weeks. Starting with a few dozen users when we launched our open beta, we’ve now grown our user base by 3500%.As an engineering manager, your role isn’t just about overseeing projects and people. It’s about fostering a mindset, a culture, and a workflow that amplifies your team’s strengths and bridges its gaps.Here’s why you should consider adopting this philosophy:Product managers are the bridge connecting users’ needs, market trends, and business objectives. They scout the horizon, identify problems, and chart the strategic course. However, when PMs dive deep into the tactical arena — into the nitty-gritty of Jira boards, task assignments, and tactical prioritizations — they often face disruptive context switching. It’s akin to repeatedly pulling a general from the war room into the frontlines.The cost? Reduced efficiency, a blurred vision, and increased cognitive load. As Luke adds, “Reducing the time PMs need to allocate to JIRA allows them to invest more of their time in conversations with customers. This is often more impactful and a greater use of their time.”By allowing EMs to assume the mantle of tactical decision-making, roles are better aligned with natural strengths. EMs, already deeply entrenched in the day-to-day operations and workflows, are best positioned to manage the prioritization of tasks. They ensure that the engineering team remains agile, adaptable, and aligned with strategic objectives without the lag time and overhead of excessive back and forths.Take Luke’s approach, for example. By presenting the Interfaces team weekly with two to three user-centric problems (without prescriptive solutions), he ignites the problem-solving prowess of the engineering team, letting us devise the most efficient tactical solutions. He focuses on pinpointing problems, synthesizing feedback, and illuminating the most pressing challenges. The bets he places are strategic — “If we solve this problem, we will get more users to upgrade.” He’s not worried about grooming a Jira board or being the “process police” — he’s focused on user problems.On the engineering side, an EM’s role complements this by ensuring that the team can tactically pivot, adapt, and execute strategic decisions in the most time-efficient manner. By owning the tactical decision-making, EMs can ensure the product bets have the best odds of succeeding by minimizing technical risk and considering the opportunity costs — building something else.If you know me, you’ve probably been on the receiving end of my enthusiastic raves about Barry’s Bootcamp (I’m so sorry). I swear by it, and if we’ve talked at length, I’ve likely tried (or threatened) to recruit you for a class, promising it would change your life as it did mine. Barry’s is a high-intensity interval training (HIIT) workout for those unacquainted, blends cardio on treadmills with weight-based strength circuits. What’s truly transformative about Barry’s isn’t just the raw intensity but the clever cadence of “active recovery” periods, strategically placed low-intensity exercises designed to reduce fatigue while promoting muscle recovery.Drawing parallels between Barry’s HIIT regimen and the cadence of an engineering team might sound like a stretch, but bear with me…In the software development realm, “active recovery” isn’t about disconnecting from tasks. Rather, it’s juxtaposing intense bouts of new feature development with activities that offer a different challenge, like addressing technical debt, refactoring code, or implementing testing. This switch wards off burnout while enriching engineers’ skill sets, broadening their knowledge of different areas of the codebase.If you’re an engineer, you probably know the feeling of emerging from the grueling process of rolling out a complex feature. Times are so dark that even working on a set of bug fixes afterward offers a welcomed change in rhythm — much like transitioning from an all-out sprint at Barry’s to a steadier jog.You are still exercising, but you’re also recovering. This intentional task-switching serves multiple ends. During the ‘active recovery’ phase with bug fixes, engineers often stumble upon unfamiliar sections of the codebase. This exposure equips them with new insights and helps dissipate team bottlenecks, ensuring that bandwidth remains fluid and optimized.By owning task prioritization, engineering managers play the part of Barry’s trainers, curating the rhythm and transitions. They have their fingers on the pulse of individual capabilities, strengths, and current task loads. They discern when a shift in tempo is in order and curate the tasks to effect that change.Product managers don’t need to delve into these granular team dynamics — they can remain focused on higher-level strategy (see #1). EMs, much like Barry’s instructors, ensure a harmonious interplay between intensity and steadiness. Ultimately, EMs can strike the perfect balance where the team operates at its zenith without burning out.And if you’re wondering whether this whole article was written just so I can compare myself to a fitness instructor, then the answer is yes.A team’s velocity is intrinsically linked to its capability to harness bandwidth promptly. Here, the age-old maxim “Jack of all trades, master of none” comes to mind. How can a team ensure diverse proficiency without compromising on depth? The solution isn’t to make every engineer a polymath but rather to weave a fabric where collective competence is broad and knowledge gaps are actively addressed.Product managers aren’t expected to know individual engineers’ strengths and weaknesses. On the other hand, engineering managers are in the perfect position to harness this knowledge. When EMs prioritize, they can continually look for opportunities to onboard engineers into different parts of the code (with Good First Tickets™ involving bug fixes, refactoring, or testing) so the team is better stacked.As a result, when engineers are well-equipped to dive into a part of the system less familiar to them, the team’s agility is greatly amplified. Fewer bottlenecks mean bandwidth can be created dynamically when priorities change.As an EM, you can solicit regular feedback from team members to assess the risk and impact of blindspots and bottlenecks. This can be done through weekly 1:1s or by running a technical proficiency self-assessment survey. (We’ll explore key questions to ask during 1:1s in a future post.) And the bonus? By proactively addressing risks to your team's velocity, you not only ensure swifter execution but also foster a culture of continuous learning and alignment (more on that below).A crucial advantage EMs have is their vantage point, which lies at the crossroads of strategy and execution. While they possess a deep understanding of the tactical engineering challenges, they also have the foresight to consider the broader strategic goals. This dual perspective makes EMs uniquely positioned to cultivate a culture of value alignment within the engineering team. Through day-to-day interactions with engineers, EMs can seamlessly weave in the broader objectives, ensuring that the team is aligned in the what and deeply rooted in the why.By regularly discussing the broader product strategy with engineers, EMs can socialize building principles that connect day-to-day technical decisions, such as scope, to overarching company objectives. By doing so, engineering managers can also gather engineers’ feedback on the impact of technical debt, balancing it against feature development. This sharpens the team’s alignment while shortening the feedback loop between engineering and product, placing it precisely at the intersection of tactical, technical decision-making and product strategy.For many teams, priorities are often seen as gospel — rigid, unyielding, and top-down directives. Our team eschews this dogmatic approach. Here’s how we view and act on priorities:Our approach to prioritization isn’t just about sequencing tasks — it’s about building a responsive, aligned, and proactive team that excels in dynamic environments.Ultimately, these benefits extend beyond ensuring engineering decisions are tethered to overarching goals. EMs also have a unique opportunity to empower individual engineers to develop a heightened sense of purpose, clarity, and motivation. This elevates the quality and impact of the engineers’ work and fosters a sense of collective ownership and collaboration within the team.If you’ve read this far, thank you. I’ll now attempt to sum it all up.There’s a huge opportunity to redefine the traditional relationship between product and engineering. To unlock velocity, engineering managers should operate with a product mindset and take ownership of prioritization. This approach allows product managers to remain focused on strategic vision while EMs ensure efficient technical execution and dynamically optimize bandwidth.EMs, with their frontline experience, are best positioned to harmonize new feature development and system stability work, averting burnout. Viewing priorities as fluid, not fixed, and encouraging constructive challenge cultivates value alignment. I’ve seen firsthand how this translates to substantial growth and success, all while nurturing a thriving team culture.I’d love to hear your thoughts on whether this might work for your team (and I will do a deep dive on this topic in my next article), so let’s discuss!----1Better ProgrammingInterfaces Engineering @ ZapierBenoit RuizinBetter Programming--128Dmitry KruglovinBetter Programming--48Francisco TrindadeinBetter Programming--4Sergei SavvovinBetter Programming--18Valerio Zanini--Mike Hall--9TymeLabs WriterinTymeLabs--Mike LiinAgility Booster--T. Robert RoethinUX Collective--12Kseniya Strelnikova--HelpStatusWritersBlogCareersPrivacyTermsAboutText to speechTeams