What makes teams predictable ?

To be honest, I actually don’t know. Ok, let me rephrase that. I don’t think there is one definitive list of things to do or levers to pull that will make teams predictable. It is highly subjective and contextual to the situation that the team is operating under. A team might be crushing it in one moment and down in the dumps within six months. Instead of doing yet another, ‘Here is how to make your team successful’ post, I decided to do something different. Here is a list of successful teams I have encountered over the years, the type of problems they were working on, the context around them at that time,  and what I think made them successful. I leave the interpretation of the rosetta stone to all of you readers.

Team A

Company Size: Late Stage Startup

Team Size: 8 full stack engineers, fully remote

Tech Stack: Ruby on Rails 

Project Management Process: Shape Up

This team was one of the most predictable teams that I have encountered in my career. They would set semi-aggressive dates and hit them consistently. In times when they needed to hustle they would and hit their dates 80% of the time. This team was what I typically call the oldest child of engineering teams. The oldest child is the team that has been around for the longest time. This means that they worked on features that hit the product market fit the earliest. It also means that this team has to consistently deal with complexity in the code base that exists simply because of plain old age. Typically complexity and predictability don’t go well with each other, but the fact that this team was able to predictably deliver while dealing with code complexity was pretty impressive.

The tech stack this team used was Ruby on Rails and everyone on the team either had a Ruby background or quickly became proficient in it after joining the team. The engineering manager used to be a developer on the same team before they moved up and took over the team as a manager. They knew everything about the code base like the back of their hands and could comfortably estimate projects without needing too much help from their team. It’s not just the code base the engineering leader was proficient in. They also knew the ins and outs of the product and its customers as well. But their biggest superpower was checking their team’s estimates. If they ever got the feeling that their team is sandbagging, they would question it and get it down to a point where they thought the estimates were reasonable. Lastly, the relationship between the engineering leader and their product counterpart was rock solid. They were two peas in a pod. 

This team used a project management process called Shape Up which was invented by the folks who created Basecamp. A quick primer on Shape Up. Shape Up essentially doubles down on the concept of fixed time, variable scope and aims to ship fully usable customer facing features in six week blocks. Four weeks for development and two weeks for cool down where the team tackles bugs etc. Essentially, the team comes up with a set of projects they feel they can deliver in six weeks. They get alignment from leadership on the project. Next, heads down for six weeks for development. They scope hammer ruthlessly on everything that will push out the timelines, and if the team ever comes to a point where they think nothing usable can be delivered in six weeks, they stop development and go back to the drawing board. Pencils down at the end of six weeks and ship to production. 

When I first encountered Shape Up I was convinced the process won’t work for larger organizations, but somehow it did for this specific team. There were other teams who were using Shape Up and eventually transitioned to Agile/Scrum mostly because of familiarity bias. But this team was like an MC Escher painting where the stairs actually went somewhere.

This team’s hiring practices were also non-standard and went counter to everything that I have been taught about hiring the best. This team’s manager made sure all new hires got along with the existing team. Yes, they made sure all new hires ‘fit in’. I tried to break that habit when the manager ended up reporting to me. I tried to push the team into aligning on company fit vs team fit, but after seeing the results this team was delivering, I just left it alone. 

Team B

Company Size: Large

Team Size: 8 specialized engineers (mix of full-stack, front-end and DB engineers), fully co-located

Tech Stack: Java 

Project Management Process: Agile/Scrum 

I might be biased here because I was an engineer on this team. We were the first team in the R&D department to experiment with a newly invented project management technique called Agile. Up until the creation of that team, the entire R&D department was organized into functional silos. There was a back-end department, front-end department, UX department, DB department etc. Project sponsors would work with the department heads to staff their projects and use project managers who relied heavily on waterfall techniques to push projects from one phase to the other. Our team was breaking all the organizational norms that had existed in the company for decades. 

The leader of our team brought together individuals from various departments and physically moved them to a corner of the floor. Next he removed all the high walls from our cubes and replaced them with shorter walls so that we can talk to each other without walking over. He instituted weekly pair programming sessions and bug bashes. Lastly, he got us all special permissions to work across the stack. So now, I, a backend developer, could work on the front end code without getting special permissions from the front end team.

We were faster and more predictable than any other team in the engineering department. We spent nights and weekends when there was a need to. We powered through technology stacks we had no experience in. We pair programmed without grumbling. We essentially crushed all expectations. I made quite a few friends during my time in that team that I am still friends with.

I have a few theories on why we were so successful. I think the biggest thing that helped us win was that we were freaking motivated to win. Every single one of us on that team wanted to win. I also think the leader who picked us knew that as well. I don’t know if the act of doing Agile made us agile, but breaking down silos was a huge boost to productivity. Our project sponsor and team leader was extremely charismatic. He was on a mission of change and we all felt we were part of something bigger the entire time we were on that team. Lastly, he empowered us to make decisions and move quickly without asking for permission. 

Inspired by the success of our team, the concept of full stack, agile powered teams was quickly adopted everywhere in the company, but I don’t think it universally created successful teams. Some teams were more successful than others, but no team came close to my team that pioneered this radical new way of shipping software. The biggest thing that made us successful were the individuals on the team and our leader.

Team C

Company Size: Late Stage Startup

Team Size: 8 full stack engineers, fully remote

Tech Stack: Ruby on Rails with some Go mixed in

Project Management Process: Agile/Scrum (they planned out about a month in advance)

This team was the opposite of the team I talked about first. This was the youngest child. They worked on mostly green field initiatives and seldom had to deal with the complexities of a legacy code base. 

This team was fast (faster than Team A) and predictable from the inception and the fact that such a young team was this fast was pretty impressive. The engineering manager was new to the company and new to the role but they were pretty technical and pretty hands on. Hands on in the right way. They were hands on so that they could understand the system well enough to talk shop with their team and earn their trust and not necessarily for adjusting down sandbagging. They gave a lot of runway to their team and in some cases a bit too much. This manager consistently scored high on eNPS scores for their team.

The cornerstone of this team were two senior engineers who shared some common traits. They never over engineered and almost always optimized for getting the product in the hands of end customers as fast as possible. They wouldn’t spend too much time thinking about some grand design that will solve climate change for everyone. Often, they would duct tape their way to a decent enough product launch and iterate from there. Their attitude was also pretty infectious. All the new hires that joined the team would get assimilated into their way of thinking in under six months.

The one thing to note here is the shape of work this team was working on. While Team A was working on delivering full baked product features, this team optimized for smaller experiments. Team A worked on the core product features which means they worked on a part of the product that saw a lot of customer usage. This means they have to consistently deliver a MLP (minimum lovable product) or risk customer churn. Team C on the other hand worked on important features, but it wasn’t as heavily trodden as Team A’s feature set. This means they could take an MVP (minimum viable product) and iterate. This was the biggest reason Team C was the fastest team in the organization. 

Team D

Company Size: Late Stage Startup

Team Size: 10 full stack engineers, fully remote

Tech Stack: Ruby on Rails 

Project Management Process: Agile/Scrum (they planned out a quarter in advance)

This team was not the oldest child of the organization but close to the oldest. Just like Team A this team also worked on a heavily trodden part of the product. This team wasn’t the fastest but was the most predictable. 

The team had a lot of solid senior engineers who could deliver without needing much guidance, but the secret ingredient this team had was its superstar product manager. This product manager knew ALL the details. They knew the surface area of their feature set like the back of their hands. They also knew what customers wanted and had really strong opinions on what should be built and in which order. This PM is probably one of the best execution machines I have encountered in my career. 

However, flawless execution comes with one giant tradeoff that most people don’t realize they have to make. To flawlessly execute consistently, you have to control every single aspect of the software development lifecycle. Think of airplanes. How do they manage to take off and land mostly on the advertised time? They do it because the FAA (and the ICAO internationally) controls every single aspect of the act of flying commercially in the US. There are numerous FAA manuals available online. Just pick one up and see how thorough it is. The FAA blueprints that airline companies have to stick to standardizes everything. 

Yeap, the key to flawless execution is micro-managing the heck out of everything and that is exactly what this PM did to make sure their projects stayed on track. 

This attitude rubbed a lot of people the wrong way especially their engineering manager counterpart who wanted equal say in what got prioritized. With some help they found a happy medium, but it was definitely contentious in the beginning and there would be regular flareups along the way. I do understand the PM’s perspective though. On one hand their leaders praised their flawless execution but on the other hand they asked them to disagree and commit with their engineering counterparts or the engineers on the team. In the end their direct manager and myself figured out a way to keep the peace and also allow the PM to keep executing. One last note to call out, the engineering and product leaders were both good at calling engineers out if they felt they were sandbagging project estimates. 

Finally, here are my observations around the attributes of predictable teams

1. The leaders (engineering and/or product) know ALL the details and have strong points of views on what to build and in what sequence. 

2. The leaders on the team knew (because of #1) if their team was sandbagging project estimates 

3. The engineers on those teams are self-motivated and understand the impact they are making to the company’s bottomline

Yeap, that’s it. Find the right engineering and product leader and staff their teams with motivated engineers. Predictability! Easy! Win! /sarcasm