Work and Team Breakdown

Posted on Dec 10, 2020

The breakdown of work and the relation it has within development teams has interested me for a long time. There is no question as to where the thoughts began but they have led me down a larger path of discovery. The journey began by reading The Phoenix Project by Gene Kim, in it he talks about the four types of work, how work should be scheduled and broken down into easily repeatable tasks much like a manufacturing plant would. This made sense to me, what is all work but a sense of easily broken down tasks and steps? The smaller the tasks the easier it is to complete and increase throughput.

But not all work is like that. In fact in all work problems arise or improvements can be found. In the Phoenix Project this seems to happen as if by magic. All of a sudden the throughput is so great that additional work can be added to improve constraints found within the system. Great, so all a successful team needs to do is to break down the work into chunks and voila, instant improvements can happen.

A couple of months ago I got my first real shot at leading a team. As the lead in that team I wanted to start implementing the ideas I had learned from The Phoenix Project and The Goal about breaking down work, reducing work in progress, and delivering. Combined with ideas from The Lean Startup we as a team worked towards delivering small incremental chunks that added early value to customers. We found some early success and had had established a fairly good relationship among our team members in how we did this work. At this point we were only a team of four: a lead, a senior developer, a junior developer, and an intern.

My team merged with another after completing two sprints and delivering some promising features. This is where things sort of went down hill. Initially the team was small enough that it was easy for me to break down work and discuss with others what we were doing and what the vision was. But in doubling our team and dividing leadership roles with me and another developer soon made it seem like this system wasn’t going to work as well as I had thought. At first we were able to break down the work still and deliver small tasks to other developers and our ability to deliver was just as before. Sure, it took me longer to break down the tickets but with the increased productivity of the team we were able to identify constraints and deliver great customer features.

Yet, as the project went on it became clear that the developers on the team were not understanding what we were building. They were people on an assembly line putting pieces together without knowing if they were building a car or a toaster. Sure, we had discussed the “system” we were building but they had no idea of how the whole thing was fitting together. When I started to allow people to break down their own work it started to underline that they didn’t know what was going on. Corrections had to be made, and processes were put into place. We were still mostly able to deliver but something just didn’t feel right. Me, as the lead, couldn’t be the only one thinking or solving the problems. People on the team did not have enough situational awareness to identify issues in the system or look for improvements, they did the work and moved on. Was this how successful organizations were run? Is this how technical work gets done?

In the book Team of Teams, General Stanley McChrystal discusses the evolution of the US military from an ordered well-oiled machine, the epitome of logistics and delivery into a flexible, agile group capable of delivering and adapting to the ever changing world around them. He discusses the idea of empowering others to make decisions and the problems of breaking down work too much for others. Similarly, Captain David Marquet outlines the need to empower team members to make decisions while informing superiors in his book Turn the Ship Around. So was I wrong to think that the best way to run a development team was to follow what Gene Kim and Eli Goldratt outline in their books about manufacturing and delivery? Or was this empowerment model not fitting with the scenario I was in?

I’ve had time to reflect on this and am still working on an answer. Software development does follow the basic principles of manufacturing. Feature requests come in, raw material in the form of thought goes in, code is created, tested, and eventually delivered. From a very high standpoint that is what it is. But the more you zoom into the actual process you see that not every ticket is cut and dry, people need to adapt and change and think for themselves. Sure, there may be particular elements that are repeatable tasks. “Create a new service”, “build this API endpoint”, “create this deployment file” but these are easily identified as part of any piece of work and yet complex or intricate business problems may be lurking in that task. This is the good stuff, this is what a developer wants to tackle and try to solve. That’s why there are so many different tools out there to help abstract the boring stuff and focus on delivering the business needs.

Yet, what I was taking the fun part away from the team. I was breaking down the tasks, highlighting the easy portions and tackling some of the complex portions myself. This made sense to me, I was lead on the team and I had a lot of junior developers that were still learning. We needed to deliver and soon. By doing this I was thinking for my junior developers and not allowing them to be empowered in their work and learn. As the project progressed I tried to let them go on their own to break down and do the work but it was too late. They had inherited a substantial amount of debt because they didn’t have insight into what we were building. They couldn’t see the car because they were building a toaster.

On the flip side, I did not do much to break down the work of the other lead and senior developer on the team, thinking that they could manage this on their own. What I found was that these individuals worked on their own and did not provide enough insight into what they were doing to allow anyone on the team to help out. They were off designing and creating an engine and telling us where it would go and what it would look like. In the end these individuals were under the immense pressure of integrating their solutions because no one knew how to help them. They weren’t communicating the work just doing it.

What General McCrystal and Captain Marquet tell us is that we as individuals should be empowered to do whatever work we can as individuals, and yet we are part of a larger team and that team needs to communicate well with each other. This communication is through email, chat, video, in person and even tickets. I was too focused in providing work to junior developers because I did not think they could handle breaking down work that I neglected to push our senior developers to allow others to help. This caused issues later on and forced us to deliver late.

The magic in The Phoenix Project was somewhat remedied in its sequel The Unicorn Project where the main character is a developer, not a member of the Ops team. Here we get a different perspective of development, teams, and the need to coordinate. Upon reading this book again and while listening to Drive by Daniel Pink I realize that in both development and operations teams we want to solve complex problems, we want to create, and that old manufacturing practices don’t always work. But this was also an incorrect thought. Sometimes we have easily repeatable tasks and sometimes we have complex tasks. The complex tasks are what people want to solve and no one wants to do the repeatable tasks.

This is where I think things get interesting. To many this may already be clear and easily understood by many who’ve read books from IT Revolution, but please bear with me.

Easily repeatable tasks often get relegated to inexperienced individuals (like I did with my junior developers) this increases the lead time of those individual tasks but we often treat that as an investment. These individuals are “learning” and we teach them by saying, “look at this code and do the same thing”. This isn’t teaching, it’s asking others to copy and paste. In the article I wrote See One, Do One, Teach One I leaned into this notion maybe a little too hard. Yes, we should show people how we do things, yes they should attempt to do one on their own, and yes they should pass the knowledge along. But when you deviate from the cookie cutter example is when things get hard. Dev and Ops work is not all uniform and therefore developers need to adapt and learn.

So giving repeatable work to junior developers doesn’t sound like a great idea because it increases lead time with little or no benefit to the junior developer. Yet giving it to a senior developer would decrease the lead time significantly but be under utilizing the abilities of the developer and take them off of important work. So in a DevOps world what do you do with repeatable tasks? You automate them. This transforms a boring task into an interesting one. Have a developer (senior or junior) work on automating a task. Research a framework, create a code generator. This is an investment into your team and helps with the flow of work through the system. When complexities or deviations arise, look at ways of improving the product, process, or framework you’ve put in place.

Developers and Ops people need to have the bandwidth to improve the system and the way they build and do things to help them focus on “interesting work”. This allows the company to grow and the team to have slightly more predictable delivery times. This is why frameworks and ORMs are so popular, they allow you to accelerate quickly and focus on the interesting problems your business is trying to solve. Once you reach a certain scale or complexity these frameworks fall apart or no longer fit. But at that level you hopefully have a larger team to tackle some of these issues on their own. I’ve never been a huge fan of frameworks because I see what they do in the end, yet this has been the wrong way to look at it because you first need to understand how a product is used before you know how to improve it.

How does this solve the training of junior developers? It doesn’t. That is something I really don’t have an answer for at the moment. The closest solution I have is this notion of “get a swim buddy”. A swim buddy is a concept in Navy Seal training where recruits need to pair up with somebody that keeps them in check while also providing support. In a developer world this can be called mentorship but I feel like all too often this falls under the category of “how are things going?” from a senior developer while a junior developer asks a bunch of questions. In reality it takes a long time for this knowledge transfer to happen and if the senior developer is busy the mentorship goes by the wayside.

I would suggest changing mentorship to full on “swim buddy” where tasks an tickets are assigned two developers. These developers work in coordination with each other by breaking down work into subtasks or by pairing. This transfer of knowledge and working together not only creates a relationship between team members but also allows for better knowledge transfer between individuals. Working together builds a bond that will help a team work closely together while independently.

Answers to all of this may be obvious to many but to me it was a revelation. Something that I am still thinking on and working through. On paper delivery cycles and feature development seem like easy things to accomplish. Yet without the right mindset from a team or a culture of improvement these things are almost impossible.