Overcooked and software development
Part 2 of 2 — How a video game illustrates common team issues
The first part of this series has the parable that we will be using to explore common software development team issues. Go here for a refresher about Ron, Larry and David.
Lets illuminate some issues
Some obvious team issues from our parable that stick out are:
- Duplication of work
- Bad Communication
- Egos
- Bad tooling
Duplication of work
It would be interesting to see the foot traffic in the kitchen by individual. I’m not a betting man, but I’d bet my last nickel that all 3 coworkers walked the same paths throughout the round. Not only are they walking the same paths but 2 of the 3 washed dishes at different times, 2 of the 3 cooked burgers, and they all grabbed ingredients. There are lots of tasks that every team will have to do to build and maintain software effectively. Duplication of work can happen a lot in tooling. Some stuff that comes to mind immediately are:
- logging
- tracing/debugging
- local development
- build, test, and deploy
- talk to data bases and talk to other internal services
- authorization/authentication
- feature flags
- store media files
- architecture of apps and webpages
- shared components
Warning shameless plug for my dope development team coming up
At Weave we have tried several things to make sure these tools are built. When Weave was a small development team (5–10) these tools were shared by everyone. When someone needed a feature flag, they would take the time to build a useful service so that everyone could use it instead of implementing a toml file in just their service. Now that we are bigger (70–90), we have 2 mostly full teams who own these shared services and all they do is make the tooling better so other teams can ship better and faster.
Obviously having dedicated teams isn’t the silver bullet. And you may not work at a company as great as Weave where the business leaders are ok with 2 full dev teams working on mostly non customer facing features. There are cons to having 2 dedicated teams on tooling/shared libraries/features. The lines of ownership can be very blurry. The lines are never 100% known, but we embrace this and are always working on making the lines more clear.
Bad Communication
All kinds of decisions were made in this story that weren’t communicated to the rest of the team. When David ran Ron over, there should have been a converstation about why it happened and how to prevent it in the future and who should clean up the mess. There were dishes left 1/4 cleaned in the sink that David should A) finished cleaning or B) communicated where the dish was and why it was left like that.
Sometimes we have to leave a feature half finished and rush to an issue in production affecting tons of users. However leaving a comment in slack, or on the pull request can help your team mates know where they can help or help you remember where you were when you left.
It may have been better for one of the 3 to actually not do any work and just be the director of work. One of them could have yelled out what the order was, and gave specific instructions for the others to follow. This way when someone says “Pick up the lettuce and throw it away”, there is no cognitive battle on whether or not to pick up the lettuce (tech debt) now, later or never. It has already been decided so just go get it done.
This process of getting work done works great with work that is repetitive and doesn’t require deep thought. Unfortunately that type of work is not common for software dev teams, however it can show up during migrations or moving to new tools. Having a Coxswain whose only job is giving directions and strategy can be highly effective for non deep thought work.
It feels like most teams could always use more developers. So taking a fully functioning developer and making them just do communication seems like insanity. However as your company grows, communication gets WAAAAY harder. Having someone whose job is to make sure everyone is on the same page can be helpful for everyone.
Egos
Ron had a hero complex which led to him being a useless team member. This hero complex can sometimes come from the team member who is insufferable and on a team of one, but is the smartest one in the room . I frankly don’t have any good ideas on how to deal with this scenario so I’d love to see some comments for this. Luckily at Weave our smartest people are not jerks 😁.
Another way hero complex shows up is when 1 person keeps saving other teams. It is fine to help out, but when 1 person is doing 3 people’s work, then there are 2 parties at fault. The hero and the company. Having a hero can be awesome. The hero can do whatever they want, move quickly and ship more features. But when the hero goes on vacation and stuff breaks, now what? Either someone has to step up and will have some very stressful days (not a chance the new person is going to be able to navigate the heroes leftovers in a day) or there is the expectation that the hero has to be on the clock 24/7 and take their laptop everywhere. This will not only lead to your hero (usually the company’s highest performer) leaving your company, but the rest of your devs not knowing the core components of your system.
Larry who seemed to provide the most value and was the glue that held the team together could have been a little more proactive in leading the team that was so desperate for leadership. Sometimes teams have senior devs with years of experience who have been burned by previous companies so they stay aloof and make consistent decisions to not get too involved.
Let me be very clear, I am not advocating that any one give their heart and soul to a company just because you are employed there, nor am I saying just do the bare minimum so you don’t get fired. But there is a middle ground where Larry can offer some of his experience and not get get screwed by the company. Putting Larry in more of a coaching position, or consulting him before decisions are made are a safe middle ground for the company and Larry.
David is the team member who is relentless about process and effective tools. These types of team members often try out the cool new javascript framework or some hot new thing they heard about at QCon and implement it before it’s actually ready to use. Which in the long run doesn’t actually save time and just frustrates every one on the team.
David shouldn’t have used a brand new skill (sprinting) without some more thorough testing. There needs to be a space and time for devs to explore new tools and ideas, and defined way to get those new tools introduced to the rest of the team and rolled into production.
Bad tooling
In the parable, there was only had 1 cutting board and 2 plates. Think how much faster they could have delivered their orders if they had 1 more cutting board. Often times lack of physical resources can be a real drag on a team’s effectiveness. If they had 6 plates and never had to clean plates for the whole round they would have saved lots of pain.
Having the right computer and build system so devs don’t have to wait for 5 mins for their builds to finish can keep distractions down and keep developers motivated.
A warning about introducing new tooling. No matter how great your new tooling is, or how much time it will save, the migration to it will be painful. The why it’s great, why it sucks and who is helping have to be over communicated so team’s know what to expect.
Trying to implement more than 1 process or implementing too quickly will slow your teams down. Imagine if on the first order from our parable, their boss came in and said “everyone has to sprint all the time”. Ron, Larry and David may not have ever gotten the first salad out at all.
Avoid all process unless it protects and empowers your teams. Your development teams are smart, hungry and eager to build great software. Trust your dev teams and they will build great things.
THE END
I briefly mentioned Weave, and have much more to say about how great it is for developers (maybe in another post). I won’t pretend Weave doesn’t have its issues but everyone is actively working to address our biggest issues and our leaders listen to complaints with open arms. I’d know I complain the most! If you are looking for a job please reach out!
As always thanks for reading!
