Interrupts vs. polling models for product teams
The target audience of this post are product leaders trying to understand & evaluate the effectiveness of their product team's underlying operating model.
Interrupts
In computer architectures, there is a concept of “interrupt-driven” systems. Interrupt-driven systems rely on inputs from connected components and signals from external programs to ensure they are operating effectively and working on the highest priority task. Interrupt-driven systems are designed to be adept at context switching - they store the state of the currently running program and switch over elegantly to a new task based on an incoming signal (interrupt). Examples of interrupt-driven systems are incredibly common around us:
Our personal computers respond to a constant stream of signals from keyboards, mice, microphones, etc.
Traffic lights adapt their cadence based on inputs from weight sensors in the road.
Home security systems are designed to alert when sensors are tripped by intruders.
Interrupt-driven systems are popular due to their responsiveness & agility. In contexts where needs are dynamic and hard to predict ahead of time, interrupt-driven systems can help to ensure the most optimal utilization of resources. They can bring ‘order to chaos’ by switching contexts between tasks, while working to ensure that high value tasks are prioritized.
Interrupt-driven systems are designed for flexibility, and are reactively agile.
Polling
An alternative to interrupt-driven systems are polling-based systems. In polling-based systems, the system is designed to periodically check or ‘poll’ external components or programs to see if they have any relevant input or signal for it to process. Compared to interrupt-driven systems, they are less adept or efficient at context-switching. However they tend to operate much more effectively in contexts where external signals are either somewhat stable, infrequent or less critical for functioning.
Common examples of polling-based systems in our everyday life include:
Thermostats that regularly compare the current temperature of the room to the preset desired temperature, and adjust heating or cooling accordingly.
Dishwashers that cycle through wash/rinse/dry modes based on internal settings & timers.
Polling-based systems are often far simpler to implement, more consistent in their operations and more reliable than interrupt-based systems. Their primary purpose is to ensure a well-defined core job or program is executed well - while being responsive enough to external inputs along the way.
Polling-based systems are designed for purpose, and are proactively curious.
Interrupts vs. polling in product teams
A product team is a complex system, comprised of multiple parts (functions, roles) and signals (inputs, feedback) that must run among them to be effective. The analogy of interrupt-driven vs. polling-based systems is a useful one to understand the dynamics across a product team.
From my experience, generally speaking the best product teams operate in ways that are similar to polling-based systems - as a collective unit, and in collaboration across functions. In these teams, you will observe some common patterns:
They share a clear purpose and durable long-term aspiration (core job/program) for their product.
They proactively seek a variety of external inputs to inform, validate, pivot their approach to achieving their aspiration (through research, experimentation, customer + community engagement). These inputs are thoughtfully synthesized and prioritized.
They understand the interconnectedness of their individual roles in the system and self-manage their contributions. They are rarely ‘blocked’ on other team-members, as cross-collaboration is proactively sought out.
In contrast, weaker product teams that operate more akin to interrupt-driven systems manifest very different patterns:
Their purpose is vaguely defined, and their long-term direction tends to pivot often.
They react to external inputs as the primary mechanisms to drive clarity and alignment on their plans. The inputs are reacted to haphazardly, prone to recency bias or the “loudest voice in the room”. They context-switch amongst priorities repeatedly.
The team tends to be confused about how the various functions can best contribute. They often require significant coordination tax (micromanagement, RACIs, etc. ) to work well together since their cross-collaboration is mostly reactive, based on functional handoffs.
Interrupt-driven operating models - which may work wonderfully well in other functional areas of the organization (ex: Operations or Support) - tend to map poorly to product teams. Because at its heart, great product building requires purpose & conviction - in other words, a core program or job that is continuously running. And external inputs are valuable to serve or support the core program - but not the other way around.
One of my recent favorite clips on this topic is from this interview of Joe Gebbia, Airbnb’s co-founder - on the topic of conviction & resilience in the midst of volatile external input (customers, press, investors). I recommend watching the section from 4:00-12:30.
If your product team feels like the latter, operating in an interrupt-driven way, then the good news is that any system - no matter how complex - can be re-architected. It is certainly not easy to do so, and it is certainly not a quick process. But often, evolving from an interrupt-driven model to a polling-based system for a product team boils down to:
Building expertise: a common root cause for teams to fall into an interrupt-driven model is due to gap in confidence/conviction when the team lacks deep expertise in the customer problem space & domain.
Clarifying purpose: articulating your product’s charter, vision and strategy for a meaningful time horizon.
Defining a proactive operating model: mapping out the various external inputs needed for effective functioning, prioritizing them and developing predictable mechanisms for getting these inputs.
In a vacuum, this playbook may feel intuitive or straightforward. But in reality, making this evolution is messy since product teams operate in the broader context of wider organizations. It requires a degree of strong and high-integrity leadership to give the space for these kinds of teams to evolve - and to look beyond more superficial patches to the system that can be tempting (ex: swap team-members, strengthen team processes, clarify roles/responsibilities, etc).
A footnote on interrupt-driven PMs
My original intent for this post was to talk about the challenges of interrupt-driven behaviors for the PM role. In writing, I realized that it’s likely more relevant to reflect on this dynamic at a product team level, not just a single function or individual.
That said, as with many of my posts, I do believe the PM has a very central role in leading the team to become more purposeful and proactively curious. Given how many product orgs are typically setup - if PMs are interrupt-driven, it is often difficult if not impossible for other cross-functional team-members to mitigate that effect on the team’s operating model.
Additionally, interrupt-driven PMs risk personal burnout and overload. Product building is such that the variety and quantity of external inputs is exceptionally wide. From external signals (customers, competitors, partners, investors) to other internal signals (leadership, stakeholders, operational functions) - it can be incredibly hard to keep focused without a personal polling-based operating model. The best PMs are intentional in how they lead with a consistent purpose, while being proactively curious to the external inputs that matter the most. And their priorities, relationships, calendars, and outputs reflect that.