The game has changed

If you compare modern football teams to their predecessors 20-30 years ago, I think you can spot some interesting differences. Taking a look at the typical players for instance it seems to me that they were much more stereotypical than today.

• Goalies prevented the goals, but everyone got nervous when they had the ball at their foot

• Defenders were mostly about destroying the opponents game, participating in the game with the ball itself came second. Think of Jürgen Kohler for example

• Creative mid-fielders and strikers were often completely freed of any defensive responsibilities. And we often had single players that dominated the games. (We still have Messi and Ronaldo, but they’re probably the exception). Some famous mid-fielders or strikers were even smokers (Mario Basler anyone?)

In a nutshell teams were composed of highly specialized people focusing on their respective duties. If memory serves me right, I also remember much more independent actions in the past and the system that squads were playing back in the days was pretty static compared to today.

One thing seem to have changed in the last decades: The game has become much faster and more intense, requiring much more fitness, more collaboration and faster reaction times.

Just to name a few stats I dug up via Google

• Players do cover around 50% more distance in a game than 20 years ago
• The amount of sprinting and high-intensity playing activities (like sprints) has doubled since the year 2002
• The ball is in play, and live, for almost 15 minutes (17%) longer than was the case in 1990

As a consequence the squads we’re seeing today play the game radically different to what I was used seeing in my youth. Gone are the high specializations of the past.

• Goalies need to be good with the ball
• Defenders are often the ones who open up a counter attack either over the wings or through the center
• The offensive that’s freed from all defensive duties is pretty much gone. Defensive is now starting at the frontline. Mid-fielders and strikers do have to play their role in it

All of them need to be highly trained athletes in order to be able to compete at highest level. Gone are the smokers of the past. And another fascinating thing seems to have changed: The dynamics between the coach at the sidelines, the system and the players on the field.

Now with the game being so fast, decision making solely happens on the field. Players need to thoroughly understand their role in the larger context, their expected behavior in certain situations and their options for adapting when situations arise that weren’t on the preparation sheet. They have to, so that they can make these split second decisions that make or brake the game without a lot external sign-off.

If you ever watched a top squad from the higher ranks of a stadium, you’d also probably realized the magnificent coordination that seems to happen intuitively. Gone are the static positions in the past. You see coordinated changes of the system in offense and defense depending on the game situation. Obviously it’s not intuitive, it has been trained to the excess into the squad, but sometimes it looks to easy and natural that it has the feeling of intuitiveness.

So why am I writing about this?

I find that fascinating and beautiful. When I was looking for inspiration on how I wanted to lead an engineering team, I peeked into all sorts of disciplines and professions. Besides the typical management literature two areas that you often end up at are competitive, squad based sports and the military. And I usually prefer the former.

I see a lot of similarities between the increased need for delivering faster to customers, iterating faster on our product while maintaining or even increasing the quality of the delivered product in the IT world and the development I described earlier about football.

I also think from that you can derive some broader principles and deeper understanding about teams and on how to lead in such environments. At least it had a dramatic impact on me and shaped how I’m running my team for the last 2 years.

A lot of the insights I’m going to touch on next are probably worth their own detailed look. I’m leaving this for other posts though to see if there’s enough interest and effort of jotting them down is justified.

Please also note that these are my conclusions. There’s a chance that they’re wrong in the broader context and not applicable for everyone. I’m just a flawed human being like everyone else. But I’ve seen these things working and producing tangible results.

So let’s dive right to it

There is no such thing as too much transparency

A lot about what is perceived as performance often (but not always) boils down to speed of making decisions. In order to be able to make the adequate ones, I think you need proper context. You need to have a thorough understanding of the “Why?” in order to derive the “What?” and the “How?”. And usually there are plenty of “What?”s and “How?”s.

Some managers work with information, but wherever I can I try to make as much information available to my team as possible, the good ones and the bad ones, so that the proper decisions have a chance to be formed within the team.

I also learned that there’s quite a bit of loyalty involved when you’re open about the negative and not working things from the start. Some applicants thought I was trying to talk them out of an open position when in fact I was being transparent about what working in my team compared to working to what he/she was used to. But the ones that took it on are still with me, even if it has been stressful sometimes.

Explicit more often than not wins over implicit

Some people do get pleasure from being the sole point for authority of their area and that all important decisions have to be acknowledged by them. I’m not one of those people. On the contrary I think it hinders day to day team performance when an engineering lead or manager is asked for permission on all sorts of things.

As the enemies of Admiral Nelson in the battle of Trafalgar found out, things get slightly messy when you’re relying on a central authority which is not available and the rest of the gang is suddenly without direction.

Similarly in the pitch as a player, you can’t wait for someone else to make decisions for you, you’re forced to make the decisions yourself under time pressure.

The point here is that the more information you’ve got available and the clearer your picture is on what your responsibility and authority is, the faster the decisions will likely happen. You simply have more mental capacity available for the job at hand.

I’ve used Delegation Poker and Delegation Boards to sort out and clarify decision making with success in the last 2 years and it feels right and natural to me.

Generalists over specialists

The engineers in my team are jotting down and discussing requirements, implement features in multiple programing languages (we’ve used Scala, Ruby and a bit of Go in the last 2 years), doing QA, giving workshops and internal trainings, organizing all major agile-ish meetings (like groomings, retros), talking to customer teams (we’re building an internal developer oriented product) and many other things.

There’s no Product Owner in my team, no Project Manager, no Agile Coach or Scrum Master. They simply do everything themselves.

Funny side effect of this, is that they seem to support each better than any specialist team I’ve worked with in the past. Does it mean that everybody is awesome in everything? No, but we’re all improving in multiple dimensions and it’s a pleasure to see how this group adapts to new situations. Because there’s nobody in my team that pushes back on things that need to be done with “That’s not my job”.

An in the face of a more fast paced world around us, I believe we need exactly that. Teams that are able to adapt and change gears quickly, that are not afraid of loosing their past investments when going into an area where are they’re not the expert anymore. For me that’s true agility.

Constant inspection, feedback and tinkering creates highly performing teams

The intuitively looking collaboration you see in successful squads on the pitch, is actually the result of many, many months and years of training. Successful teams train different game situations over and over again, stopping them, discussing them, correcting them. Both as a group, but also at an individual level. It’s tinkering in its pure form. But because of this inspect and repeat loop, when the situation requires it, most of the action happens on autopilot and the mental capacity can be used for other things such as creatively resolving whatever situation is in front of you.

What you can take from this is that there’s value to standardize, codify and/or document how your doing things and iterate on that. To capture tacit knowledge and to make it visible and available to everyone.

In my team we went to the extreme and defined everything as an MVP (Most Valuable Product, in the lean sense), so that the way we work and the software we produce is constantly inspected and refined based on hypothesis. It has served us well and is I believe one of the reasons why we were successful in the last 2 years.

You can sprint, but not forever

Football as a game has become much more intense as described earlier. Interesting side effect from this is that we don’t have a constant level of intensity, but more like alternating phases of rushing and slower phases in the game where it’s usually less pleasurable to watch.

Similarly in software engineering or IT teams, no matter how many Scrum enthusiasts are saying it out there, you can’t always sprint. It’s just not sustainable. You need these less productive phases to recover, if you sprint.

Even more controversial to some probably, the more sustainable and at the same time more predictable way is actually not to sprint at all, but working at a constant throughput and slightly below 70% utilization.

Totally boring, but effective. And a topic full books have been written about, so I leave it at that here.

You’re measured by results only

There’s an ugly truth to competitive sports: No matter how ugly you play, nobody will probably bother as long as you get the job done and deliver the expected results.

On the other hand, how many trainers do you know of that are still in their seat, whose teams played beautifully but weren’t really successful?

For IT professionals that like to argue about technical excellence, code quality, testability etc. this is sometimes hard to swallow, but a product that has 100% test coverage but fails to deliver value to the end user, will go down as a failure in the history of the organization no matter how good the technical bits were.

Similarly, and that’s even harder for someone like me to swallow, it doesn’t matter what good, productive atmosphere you created, how adaptable your team is, how fast it makes informed decisions, if you’re not delivering on results, you’re likely not positively remembered. Even worse, you might be replaced by an old school, top down guy that ensures in his own ways that the job gets somehow done.

Your expertise from yesterday is slowly but silently depleting

Remember when Jose Mourinho still called himself “the special one”? That was before he was fired three times from Real Madrid, Chelsea London and Manchester United.

For me he seems to be a pretty good example of someone that used to be successful, but wasn’t able to adjust his skills while the football was changing around him. And now most opponents have understood the defensive style he’s playing. My guess is that without re-inventing himself, he won’t be able to get back to his glorious days.

In a similar vain, as a technical person you direly need to continue learning. Either that or things might become very frustrating on the job market. Engineering managers have also the tendency to be an endangered species, at least the ones that want to be involved in technical solutions to a certain degree. Very often their day-2-day duties don’t involve coding and knowingly or unknowingly their former knowledge slowly but continuously gets outdated to the point where they’re maybe making decisions about things they’ve never used or touched. Usually a recipe for disaster.

I’m personally trying to spend more at least 20-25% of my time per week on operational topics (such as coding, documentation, technical support, etc.) with my team so that I don’t loose touch with them.

Embrace that we’re all on a way to somewhere

Like players in the pitch, there’s high demand for really great IT professionals on the market. You can try to fight that, but you can also choose to embrace that. Allow your team to be in the spotlight wherever possible. Give the thing you’re working on actual faces that people can relate too. Increase their marked value. Aim for having a good and successful time together. Cherish it, because eventually like all good times in life, things will come to an end. One or more of you are going to leave. That’s normal and fine. But the relationships stick and your team culture and spirit might also be preserved even when you’re not part of it any more.

Closing thoughts

Things have become noticeably faster and ever changing compared to 10 or 20 years ago in our profession. Decide for yourself what this means for knowledge work and collaboration. I gave you a brief overview about the conclusions that I derived from this by looking outside of our profession, namely professional football.

In the end of course all metaphors and analogies break down, but that doesn’t mean they’re completely useless. I use them as guiding principles that drive the way I make decisions and approach work together with my team. Am I perfectly following all of them? Nope, I struggle every now and then. Because things are usually neither black nor white, but gray. But I try to follow them wherever I can.

If you’ve got questions on this, feel free to connect with me on Twitter. My handle is @bjoernrochel. I hoped this was somewhat useful to read. At the very least it was for me for structuring my thoughts regarding this.

See you next time around!

:wq