February 28

Trent the Tortured is a Victim of Chaos



Oh boy, where do we start with this one?

If you are a solopreneur, you do it all. You discover the problem, you ideate around the solution, you validate the solution, you build the product, you test the product, you sell the product, …. you do everything.

As you get traction and have money to invest and you then hire people to help. As you progress from scrappy team to startup to small business to enterprise you amass teams of super heroes .

Inevitably, every additional person you add to the process complicates things because your handoff points multiply. To streamline activities you begin to have individuals and teams focus on specific activities.

These team members become extremely efficient at their activities, but this focus also begins to create a set of blinders where they understand their area really well, yet begin to evolve (or rather devolve) into having alligator arms.

If you are unfamiliar with the term, alligator arms is the opposite of being “ready and willing to wear multiple hats”. Instead of being ready to stretch slightly into someone else's domain (and willing to allow someone else to stretch into your domain), the individual takes a step back and stays firmly planted only in only their domain with a “not my problem” style perspective.

This is one element that causes handoffs to become more and more problematic. At the far end of this spectrum you recognize individuals throwing tasks (issues) over the fence to another team.


Generically speaking, with more and more specialization, every handoff point can become contentious.

This generally happens due to poorly established expectations between individuals and departments. Often this is exacerbated by overlapping swim lanes where clear ownership has not been outlined.

In some circumstances you will see one person step up and assume control over the task and/or gather people to hold multiple people accountable, but that is not the norm.

Any situation where where multiple people "own" a task, you are inherently establishing that no one owns it. If individuals are stepping up to fill the void, it may not be visible to you. However, if you witness things falling between the cracks, now you know why.

As such, leaders must attempt to find ways to keep swim lanes and rules of engagement clear. Leaders must set expectations and objectives in a way that make owning the grey area a shared responsibility.

Tactically speaking, there are a number of universal software product development cases that trip up most organizations:

  • Executive Leadership <–> Product Management
  • Product Management <–> Product / Marketing
  • Product Management <–> Sales
  • Product Management <–> Software Engineering
  • Software Engineering <–> Quality Assurance
  • Software Engineering <–> Release Management <–> System Operations
  • Product Management <–> Customer Success

In each case the root cause is that the object handed from one group to the next is a black box without an instruction manual.

Think of it this way, let's say that someone gave you a box, you couldn't see what was in it. You were given no clues as to where it came from and only made clear that it must safely be delivered to someone across the country.

If you received that instruction, what questions would you have?

Do you want to know what is in the box? For sure!

What if it contains eggs? You want to unpack them and repack them to ensure that you can personally guarantee the best possible chance of being delivered safely.

What if it is rocks? Your risk level of something breaking in the box is a lot lower, but maybe the box is too thin so you want to reinforce the box itself.

But, is it more complicated than that?

Yes, because work tasks reflect upon job security which reflects upon personal and psychological safety.

Let me dig into that a bit to explain what I mean.

If someone is provided a task which they are unable to complete successfully, and the impact may result in them losing their job, then this adds friction to their life that they will invariably bring to the performance of their job.

Taking that to the next step, for many people, when they lose their job that eliminates the certainty that they can pay their bills. If they cannot pay their bills then they may lose their homes.

So, while the work task may seem innocuous to the person issuing the command, the hidden context of linking poor performance to the strain of potentially losing their home impacts both physical and psychological safety – thus impacting work performance.

Let's dive deeper into a few examples to quickly shed light on the cause and resolution here.

Product Management & Software Engineering

From the engineering perspective, a key problem between theses departments tends to be a lack of knowledge provided to engineering to truly understanding the root issues they are attempting to solve. This is most often the case when product has skipped discovery and or validation steps in the process. Thus the engineering team is only being told what they need to do and not why it is important or allowed to be part of the creative process.

However, with the proper context provided to engineering, including who has the problem, how painful it is, what alternatives are not working for them, etc. then engineering can become part of the solutioning process and not just the implementation crew of the feature factory.

You must establish a role expectations and ensure that individuals understand what they are responsible for and what is a shared responsibility. Many friction filled environments are created by individuals having a difference of opinion of who owns what. Clearly outlining these ground rules is what reverses the effects of alligator arms.

Software Engineering& Quality Assurance

In the case of fast and loose agile, the only thing for the QA team to reflect upon when performing testing actions is the user stories that the engineering team was supplied. This often means that the wider context is unavailable to assess if the resulting product features are conceptually working as desired vs technically working as designed.

Product management is in a good position to be able to set these expectations through strong contextual communication. Engineering also has the opportunity to provide additional documentation to the QA team (instead of just checking in code and moving to the next task). This can significantly help with the engineering to QA hand off.

Taking this a step further, and following the shift-everything-left movement, many teams have opted to remove some of the specialization surrounding QA and have incorporated this role into the engineering teams duties. This includes things like adding more compile time checks like code coverage to enable establishing automated testing tasks as part of the user story acceptance criteria.

You must ensure that your team members understand the role expectations of their cross-functional partners. When they lack an understanding of what their counterparts require to be successful, they cannot optimize the handoffs that they are part of. And while some individuals are excel at advocating for what they need, others do not. It is your duty to help bridge these gaps and improve communication and collaboration by generating coworker empathy.

Development & Release Management & System Operations

Guess what is the issue with this handoff chain… Yes, another case where a lack of communication and setting clear expectations is the root problem.

The code will eventually needs to be released, but …

  • What are the requirements of the release?
  • What are the requirements of running the code?
  • What are the requirements of monitoring the code?
  • How do I know that it is behaving properly?
  • How do I know that it is misbehaving?
  • How do I fix things after I find they are misbehaving.

The list goes on and on and is exacerbated when you do not have strong shared principles. You must optimize every opportunity for alignment. Set and document a clear vision, formalize critical tactical processes, establish shared principles, and ensure a win-together culture.

Ensure that you are establishing shared success expectations. Having individual or team level goals can be great at helping the team push forward on a specialized initiative, yet it can cause cases of conflicting goals. i.e., engineering feeling heat to quickly push an alpha feature to production behind a feature flag while DevOps is mandated with enforcing 100% testing code coverage for React components before releases can go to production.

Finally, while clear expectations, context-setting communication, and shared measures of success are important for improving handoff points, the alternative is to eliminate handoff points to simplify process flows. It is important to find the right balance of specialization and minimizing handoff points – especially during phases of rapid team growth.

The more handoff points you have, the more potential you have for weak chain links to occur. When you can shift tasks left, you eliminate much of the burden for documentation and communication. There have been many examples of this over the last decade in our industry including:

  • Front end + Back end = Full Stack
  • Dev + Operations + Release Management = DevOps

As a leader you have a great opportunity to help smooth these transition points, but what can you do if you are experiencing difficult handoff points with your peers? My advice is to step up and take leadership of your handoff points.

While you may not be able to change the structure of your team, you can amp up the communication with your peers. Express your expectations, what success looks like for you based on the requirements you received from leadership, and seek to understand your counter parts expectations and measures of success. This alone will establish new common ground from which all parties are able to more effectively mitigate handoff decay.

Take time away from your tasks to check in with your peers and partners to understand each other's perspectives, frustrations, and stressors. We get so busy working IN the business, that we forget to work ON the business by establishing stronger working relationships that go beyond the task of the day. Even if your partner is uncomfortable with transparent communication, the act alone will provide you with a heavy deposit in your reputation bank which will help smooth operations.

Corrective Advice Recap

  • Establish goals that are measured the same across departments.
  • Align teams on shared principles – including a principle that the team wins when the customer wins.
  • Establish trust with clear expectations – a required component of accountability.
  • When you amp up context-setting documentation and communication early in the project phase you significantly improve all downstream handoffs.
  • Evaluate handoff points to ensure that alligator arm syndrome is identified and corrected.
  • Remove unnecessary handoff points by redistributing tasks where applicable
  • Ensure you have established strong bonds with your partners by understanding each other's expectations and measures of success.
  • Product Management has the unspoken challenge and duty to be the conduit between all departments, ensuring clean communication lines, operational adherence to corporate principles, and that everyone is acting in the best interests of the customer.


You may also like

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}