I made this comment a few blog posts ago:

they are constantly trying to pivot everyone (also valid and true, for a variety of complex reasons).

…and I wanted to follow up on it.

A super common complaint that I hear from staff developers and engineers is how their manager is constantly changing their priorities and they have to context switch so much.

(As an aside, I’ve always personally been a fan of Sprints for this very reason, because of “immutable Sprints”. Even if your Sprint is short, like a week, it at least means for that week you can focus on getting your 1-week’s-worth-of-tasks completed, instead of getting pivoted and leaving half-finished tasks in your wake all over the place.)

But let’s go back to, why do managers constantly re-prioritize? General consensus is because managers have short attention spans and are just chasing the next shiny thing that captures your attention. But that’s not always the case. Not all organizations have the luxury of being able to just focus on the same strategic goal for long periods of time. Many things can happen to cause your top-level engineering focus to shift, and this even happens at the largest of product companies:

• Your largest customer has come to you and essentially demanded some bug get fixed, or some new feature be prioritized. Since they pay 40% of your revenue, you have to keep this customer happy, or they will quite literally leave and go to a different vendor or supplier.
• Some new security vulnerability or compliance finding has just surfaced, and going unfixed introduces a significant amount of financial and legal risk to the organization, and maybe even to YOU personally.
• A new customer has appeared and offered a ridiculous amount in a deal your sales team is closing. This is more than just “chasing quota”…your organization needs this new revenue to make payroll/margin and have everyone keep their jobs.

When you are a developer and you keep getting reprioritized, it can obviously be stressful and frustrating, and easy to blame management for being inept. But that’s not always the truth. Sometimes your managers are honestly just trying to keep everyone employed, and sometimes that means you have to stop what you’re doing to clean up a mess, or pivot to make a stakeholder happy that holds that influence over you.

Of course, this is not always the case. Good managers and leaders can recognize when the pivot truly meets the criteria for needing a pivot, and when it doesn’t. Pivoting away from a $5M delivery to meet delivery risk for a $50,000 job doesn’t make sense; why would you put $5M at risk for $50,000? Managers have to understand how to make solid data-driven decisions and not just “follow the next crisis”, no matter how loud the stakeholder is yelling.

Good lines of communication between managers and developers can help keep everyone’s morale up by understanding WHY you are being asked to change what you are doing, and making sure good decisions are being made WHEN to pivot.