tl;dr

• Urgent requests from executives can disrupt software engineering teams and lead to rushed implementation.
• Scarcity mindset and cognitive load impact attention and decision-making in such situations.
• Cultural differences and hierarchical leadership styles in lower-cost outsourcing destinations can further complicate decision-making processes.
• Strategies for mitigating these challenges include having strong product managers to shield the team, maintaining a well-prioritized backlog, and physically separating external requests from the team’s ongoing work.
• Having solid product manager principles, conducting market research, prioritizing features, and working closely with the development team are essential for effective product management.
• Using tools like Asana, Jira, or Google Docs to maintain a well-organized backlog helps balance immediate tasks, future goals, and customer transparency.
• Avoid letting the backlog become too large and regularly review it to ensure efficiency and focus.
• Physically separating external requests from the team’s work creates a buffer and allows for better prioritization and evaluation of their importance.
• Applying techniques like the Eisenhower Matrix, First Things First, and Habit 3 of The 7 Habits of Highly Effective People can aid in prioritization and decision-making.

In Episode 145 of No Stupid Questions “Do You Have a Scarcity Mindset or an Abundance Mindset?” Steven and Angela touch on this important part:

DUBNER: One thing that really catches my ear as you’re describing the Mullainathan et al. research is about attention and how more of it is required — or more cognitive load, you might call it, is required — when you’re under scarcity because you’re trying to solve a huge set of problems. I mean, when economists talk about scarcity, that’s the problem with scarcity. Things get more expensive. When it’s a product, when it’s a good or service, and it’s more scarce, it costs you more. But also in the mindset mode, it can take your attention.

Steven talks about scarcity impacting your attention when you’re under cognitive load

This applies well to software engineering, where knowledge workers are under cognitive load trying to design new features and solutions for their customers. When a new request comes in that seems urgent, this becomes a time scarcity problem, people drop things to pickup a super-important-from-a-VP-request (Chief-Level, C-Level requests or C-Requests). Different teams have different coping mechanisms for this: one team that I worked with had an engineer oncall rotation only to handle C-Requests so they could show a great time to resolve.

The amygdala also activates the fight-or-flight response. This response can help people in immediate physical danger react quickly for their safety and security. For example, the fight-or-flight response helped early humans respond to threats to avoid injury or death. Today, that fight-or-flight response is more likely to be triggered by emotions such as stress, fear, anxiety, aggression, and anger.

Amygdala Hijack: When Emotion Takes Over

People make bad decisions when stressed

Picture this, your team manages a customer monitoring solution. You’re in the middle of a large data migration from one storage solution to another, for example Hadoop to Google BigQuery. Front-end engineers are scarce, and are focusing on the next generation of UI.

A request comes in, it’s from a Vice President, they ask for you to change the functionality of the legacy monitoring solution so that when you click on a specific area, you can perform an action. Without a strong request shield in place, this request is made directly to a software engineer on the team, and because this VP wants to ensure it is fixed, they also message another lead on the team without telling these two people.

Now you have a request from an executive, sent to two individuals, that appears to be urgent. What happens?
A. Both engineers talk to one another, and decide to put this in the backlog
B. The two engineers drop what they are working on to appease an executive
From what I’ve seen: Option B.

They rush to implement this feature, one of them finishes it first, and the other notices a similar code change when attempting to merge. Now they talk and realize they both had the same request, the first person to commit wins, the code is merged, and they go back to their regularly scheduled Jira Story. They have victory for that day, but no quality control, no design, no communication, and no future-thought was put into this. This feature is never rolled into the new system, and creates bugs for edge cases on the legacy system that will plague the team for months.

Cultures handle authority differently

With a focus from most companies to reduce costs, we have seen layoffs and outsourcing to places like Mexico and India (ref). What comes with this are some cultural changes that don’t combine well with authoritarian requests from Vice Presidents. Look at the graphic below – from research from Erin Meyer et al. we see that the countries that tend to be lower cost also avoid confrontation as part of their cultural norms.

This means that, left unchecked, executive requests will likely make the bulk of the feature requests that are prioritized, leaving more important features behind and potentially introducing more bugs. Once more, take a look at the next image below – this shows that these same countries are used to hierarchical leading, where the boss calls the shots. This goes counter to the quote “Those closest to the problem are closest to the solution, but typically furthest from the resources and power to do anything about it.” (DeAnna Hoskins).

You typically want high-value knowledge workers solving problems who are the most familiar with them – not high-level executives.

This is why you might see an emphasis on buying tools instead of building them. When knowledge workers who avoid confrontation are setup to be integrators of purchased tools, all executive feature requests then go through the vendor and not software engineering team.

Strategies for avoiding amygdala hijacking at work

When you have calmed down or feel less stressed, you can activate your frontal cortex. Begin by thinking about what activated the response, and how you felt. Then, consider responses you can and should have. These will be more thoughtful and rational responses. If you still feel emotional in the moment, give yourself more time.

Amygdala Hijack: When Emotion Takes Over

Product Managers (or just the mindset) can serve as a great frontal cortex by providing protection from amygdala hijacks.

Have solid product manager principles

You may not have the luxury of a full-time Product Manager for your project, either because they are split over multiple product lines or your team lacks general investment in this role. What’s critical is that someone upholds these principles to focus the team on only the features and products that will bring value to your customer.

1. Define the product vision: This involves identifying the problem that the product will solve and the target audience for the product.
2. Conduct market research: Gather and synthesize information about the target audience, their needs, and the competition.
3. Develop a product roadmap: Outline the key features and milestones for the product.
4. Prioritize features: Prioritize the features based on their importance and impact on the product.
5. Develop a product backlog: Work with engineering teams to maintain list of all the features that need to be developed for the product.
6. Work with the development team: The product manager should work closely with the development team to ensure that the product is developed according to the vision, OKRs, roadmap timelines, and feature backlog.
7. Test and launch the product: Hands-on, thorough testing to ensure that it meets the requirements. Once the product is ready, it should be launched to the target audience.
8. Analyze metrics: Ensure features are delivering based on projections, prioritize improvements based on these metrics.

Have a well maintained backlog using tools like Asana and Jira (or even GDocs)

Having a good balance between what needs to be done now, next, and the future is important. You’ll have to merge and adjust these lists as you think about new features. Giving your customers transparency on what your backlog looks like gives them confidence that you care. Being proactive with your backlog and release notes are great interrupts to avoid constant status meetings.

Being well organized also exudes outward confidence to senior leaders that you’ll work on the most impactful things. When “urgent” executive requests come in, you can speak logically against your current set of work to illustrate where this new request fits in (now, next, feature). You may need to do some analysis before accepting an external request – and that is okay. Executives might think they have the best idea since LLMs, but only the data should confirm or deny this.

Don’t let your backlog get too large. The maximum number of backlog tasks should be 50 – use Google Docs or Confluence pages that describe additional work the team needs to work on, but it not yet in your backlog. Being prideful for a large backlog is the wrong culture to have – a large backlog shows wasteful hygiene. Review backlogs bi-weekly.

Physically separate the teams work from external requests

Don’t pollute the work the team needs to do with external requests. If partner teams and senior leaders want to contribute, give them a separate place to do so – either convert emails/DMs to updates to existing Google Docs, or maintain a distinctly separate customer feature backlog that allows for transparency and even voting for the most important new features. Review these monthly. This is your physical buffer that shields the team from unnecessary escalations that seem urgent but may not be important (also read more about The Eisenhower Matrix, First Things First, and Habit 3 of The 7 Habits of Highly Effective People).