SEP and its evil twin Someone Else's Problem

Someone Else's Problem is a term that declares that some work out of our control or scope. Sometimes we declare someone else's problem so that we don't have to take any action. In the best situations, we evaluate and declare SEP so that we can focus on our core needs.

Maintaining focus and scope control is one of the hardest things to do when creating new software systems or implementing various types of programs.  Every decision or new requirement spiders off to touch other requirements that demand other decisions.  

Some of those touchpoints belong to other teams.  This means your success is dependent on the actions of those other teams with other priorities. Sometimes that means you have to get heavily involved with the other team's activities to ensure that they do what you need.  This takes focus away from activities that are truly within your charter.

SEP as avoidance

One of the downsides of SEP is how people can use it to avoid strategic thinking or effort.  This is especially problematic when an issue is in the gap between teams.  The problem stays a problem because ownership isn't obvious and everyone looks inward ignoring edge issues.

This can lead to situations where individual teams are successful on a program that ends in complete failure.  

SEP for good

I worked on a team where we did a SEP evaluation every time we created a new dependency or identified external changes.  That evaluation basically determined if this task, its analysis, scheduling or, work really belonged to another team.  We'd talk about the need, declare it SEP and then we would move on.   We would revisit these decisions over time.

External dependencies beyond our ownership sphere were declared as SEP.  We 

1. Documented the dependencies, 
2. Pushed them onto the other team's backlog, 
3. Reviewed their backlog in an SoS type meeting on a regular basis.  

Teams supported work in the boundary overlap but avoided any detailed effort of the SEP systems beyond that. We only pulled SEP work into our system late in the game after negotiations with the other team.  

This was a way for us to maintain focus.

Nothing is Someone Else's Problem

There is a whole school of shared responsibility that opposes SEP.  One faction believes that you raised it you own it".  I view this as an extension of our first SEP above.  We own making sure the correct team has it in their backlog. 

This is like the Rescue vehicle dropping off a patient at the emergency room. It was their job to keep the patient alive until hand-off. Then the hospital owns it.

Another faction believes that you found it you own solving it because you recognized it. Proponents argue that you are the best person to solve the problem since you were the first to identify it. I'm not convinced this works for complicated issues like enterprise software systems. 

This can be crippled by management behavior if the highly motivated become buried under because of their ability to find issues.  If you take this approach then pay attention to the workload generated so it doesn't morph into keeping your head down.

Video

References

Yup I googled them

• https://www.urbandictionary.com/define.php?term=SEP
• https://en.wikipedia.org/wiki/Somebody_else%27s_problem
• https://medium.com/conveyor-ideas/designing-in-a-culture-where-nothing-is-someone-else-s-problem-8b9040f40d33
• https://www.encompass-inc.com/the-problem-with-its-someone-elses-problem/