Technical teams must be more disciplined to be as effective as others

Without a feedback loop teams are less effective. Some roles have a natural feedback loop, technical roles often don't. Here's how to establish a loop that keeps your efforts relevant.

Photo by Xiaolong Wong on Unsplash

Software product teams often proudly share their practices far and wide. Working in smaller batch sizes, conducting various ceremonies designed around shorter feedback cycles - daily stand-ups, weekly planning and review sessions etc. Good enough, right?

In the worst cases, I’ve seen this being championed in a judgement-filled way where software professionals are smirking at the lack of agility displayed by sales teams, customer service teams or any of a variety of teams. The state of the software is often slow, unreliable and full of functionality the users don’t need and missing what they do need.

At the same time, the frontline teams are responding to shifts in market sentiment, fluctuation in sales, customer support trends or big movements in the market. These are teams who have an actual feedback loop in place to see how their efforts are translating in terms of value for their customers or value for the organisation. Well-meaning preaching about agility with the limited context of the situation understandably is not often received favourably.

This hubris is one of the areas of self-awareness I explored in:

When compared to the style of important but less-than-inadequate feedback that can be covered in a typical stand-up meeting it’s often the software product team that has further to go to have a more useful feedback mechanism in place. This is because often we may have established feedback around what is working and not working from a delivery perspective but lack signals around the actual value being delivered. This is because the latter can take additional effort in areas that the team may not have full control. The barriers to establishing these signals may be higher.

For example:

• What understanding of how the software we are improving is being used by its intended user base?

• Do we understand how well the software is performing from the perspective of how that translates into the user experience?

• What opportunities do each of the team members get to regularly watch or participate in user interviews?

• What user feedback is regularly collected from the software users? How close to the time of collection does this reach the team?

Collecting the usage data for consumption by the software development team might require negotiation with traditional IT teams or analytics teams. Access to users might require negotiation with other department managers or sales staff to get access. These often mild barriers can be enough for software development teams to settle for focusing on feedback focused on delivery. These are important also but are not enough.

The result of this dynamic is that software teams may have lots of practices which could tick some boxes of being ‘agile’ but when it came down to it their efforts are more disconnected and thus less responsive to what the organisation needs.

As a consultant, I’ve had the opportunity to observe many organisations. I noticed the effects of this pattern over extended periods. The IT organisation has adopted faux agile practices which are very inward and delivery focused and the overall approach to Technology has not shifted as the needs of the organisation shifted.

It's not always the case in other areas of the organisation which may still have been locked in fairly traditional practices but nonetheless shifted to the needs of the customers, market forces or whatever unavoidable feedback they were exposed to. Hey, there are exceptions - I’ve seen such teams be completely immune to sales tanking or market shocks or new competitors, but those are their own special dysfunctions.

Anyway, I’ve done my fair share of preaching over the years. I try to maintain the discipline of first ensuring that for the results I am responsible for, we’ve established the richest set of feedback signals we can, and we are actively using this information to prioritise and adapt to meet the organisation's objectives and ensure the best possible user experiences.

The importance of feedback loops

One side effect of bureaucratic organisations is the number of employees who lack an effective feedback loop. After all, any team without a natural source of feedback will require effort to establish feedback mechanisms.

The chance for rational responses and change is higher where there are natural feedback mechanisms such as purchases or customer feedback.

Conversely, the likelihood of irrational responses and reluctance to change increases in areas where organisational aspects have cut off access to feedback. The greater the distance, the more irrational. The greater the distance between the priorities of that team/function and the value the organisation seeks to deliver and capture. The rise of local optima over the needs of the organisation.

A way to correct this is to understand the causal relationships between the team, its purpose, the valuable activity that serves the organisation's customers, and its business model.

There may be many steps between. Evidence of progress in satisfying or invalidating the outcomes at each link in the chain can act as a source of feedback for the team. For instance, a service team helps another team successfully fulfil a capability that supports the value the organisation provides.

How effective are your organisation's feedback mechanisms for software product development teams? Share your experiences in the comments.