I was at a developer conference this week, presenting an opening keynote on Architectural Fitness Functions and running my Tech Lead Masterclass. I noticed a couple of times individuals were talking about simply using the latest tool and technology if they felt like it. I can empathise with them, about where this comes from, and a statement I’m sure other developers get assurance from. However, what is good for one individual is not always good for a team or always good for an organisation. What is often missing is a long or missing feedback loop.

Let’s take a concrete example. During my consulting days, I saw an extreme example of this in an enterprise. They had an “innovation” team who got to research and play with the latest technologies. They would prototype a technology, leave a skeleton application and then leave it to a product team who had to bring it to production, as well as evolve, maintain and support it.

If you were on that innovation team, you can imagine how fun that might have been. If you were in the product team that inherited the prototype, you can also imagine how that might feel. I supported several of those product teams, and the general feeling was frustration. Frustration that the code produced by the innovation team was scrappy, full of “bad practice” (e.g. copy-paste, autogenerated, had bad naming, extremely coupled concerns, difficult to test and don’t even get me started on the complaints that the poor operations and support team had with the applications that made their way into production so quickly (i.e. nightmare to operate and support).

The two separate teams are not necessarily bad. What is not good is that there was only a single flow of information. The innovation team never heard of the longer-term consequences of what they had built and how they built this. They had no ability to learn what was working and not working for other teams and the organisation and therefore no ability to learn and improve.

Similarly, when individuals simply throw in a new library, framework, or new programming language, they don’t see longer-term consequences like increased cognitive load, difficulty to hire/learn skills or even if it’s easier to support and how well it does in production.

I’m not saying that teams shouldn’t innovate and try new tools. This is essential in our industry, but if individuals are going to try something new, they should look at the wider impact of decisions. Leaders can encourage this by shortening feedback loops or introducing a missing feedback loop. Think of Amazon’s “you build it, you run it"-philosophy.

Your challenge for this week is to look for very long feedback loops or to notice potentially missing feedback loops. What can you do to shorten the long feedback loops, or what feedback loop can you put in place.

Enjoy this week’s newsletter, and please pass it on to a friend or colleague who might benefit.

Join an online guided course, Shortcut to Tech Leadership (IC track) or Engineering Manager Essentials (Management track) to level up your skills. Or grow your value as a technical leader with self-paced courses at the http://techlead.academy