Part 1: Asking Other Teams to Do Something Really Hard

Background

There’s a common move with software teams; one team will ask another team to do something really hard so that the first team can do something really easy. Most of the time, we don’t even mean to do it. But, it causes a lot of stress and wastes a lot of time. It reminds me of the Seinfeld Episode where George’s Dad gets super-fire mad at Kramer for stealing *his* move. It’s pretty funny if you haven’t seen it (Part 1 – Kramer Stops Short, Part 2 – George’s dad gets mad!).

Hopefully this article will help you recognize when other teams are asking your team to do something really difficult so that they can do something really easy. Conversely, hopefully it will also help *you* recognize when you or your team is asking some other team to do something really hard so that *your* team can do something really easy. We’re pretty much all guilty of this move!

Example #1

Let’s start with a super simple example: forums (Twitter, Reddit, etc) and mailing lists. One day, a friendly new Ferrari owner shows up on the Ferrari forum and asks a super simple question (so they think): How do I change the stereo in my Ferrari? Literally, that’s all they ask. They don’t specify whether they mean the head unit, the front speakers, the back speakers, the antenna or all of the above?

It’s such a deceptively simple question, right? But what does it mean? Inevitably, a long time forum member responds with a snarky response, asking more questions. The original poster gets annoyed because he thinks his question was super clear. A second long-time forum member tries to explain that the original poster should search the history and find a post written by a locally famous forum member that explains “everything you need to know to change the stereo in your Ferrari”

Anybody that’s ever run a forum, or been a subject matter expert will immediately identify this painful pattern. People ask the same questions over and over, and they ask them in unclear ways, but they have no idea they’re causing chaos. The long-time forum members hate searching for the answer, and posting the link, because they rightfully feel like the person asking the question should do that work. This new Ferrari owner is asking the people on the forum to do something kinda hard (let’s rate “searching for or writing up a new answer” as a 3 on a 10 scale), so he can do something really easy (let’s rate “reading a custom answer specifically for him” as a 1 on a 10 scale).

 

 

Instead the person asking the question should search the forum history, find the answer, read it, digest it, try to understand it (let’s rate “doing all the home work” as a 3 on a 10 scale), and then post clarifying questions like: “I don’t understand, what tool do I need to take the strange bolts for the speakers out?” Or, “has anything changed since 2017 when this was written?” Doing some work, putting some skin in the game, would get a much better set of responses, and save long-time forum member time, energy and stress. Volunteers don’t mind doing “new” more fun work (let’s rate “answering of clarifying questions” as a 1 on a 10 scale). It’s rewarding to help people.

 

This is a perfect example because it’s so benign. Nobody is doing anything malicious, but it clearly demonstrates how a different but similar amount of work can be shifted from one party to another, with a small change in behavior.

Example #2

Now, let’s move on to a slightly more advanced example. Say, you work in a small team of engineers that write and maintain a small call center program. Let’s call them Team X. Now, let’s say that another team needs access to the the call logs you have saved in your database. Let’s call them Team Y. Team Y innocently asks, “hey, could you guys add an API so that we can access the logs?” Sounds good at first. APIs are a natural way for software systems to communicate. That is, until Team X realizes that there are all kinds of strange performance, security, and testing requirements. Team X realizes that it’s going to take 200 hours of work, and 10 hours per month of maintenance. And, there’s only three people on Team X. Instead, Team X says, “how about we just export the data nightly and let your team do whatever you want with it?”

Team Y gets annoyed. They just want a simple API call! They think to themselves, “this should be easy!!!!” They ask Team X again and say, “it’s your data! We don’t understand the format, we need you to create a clean API for us!” Team Y gets annoyed and says, “you’re the ones with the complex business requirements and you understand them better!” The two teams are at a point of contention, a common problem!

Team Y is asking Team X to build an an entire API (let’s rate it as a 6 on 10 scale) so that they can make a simple API call (let’s rate it as a 1 on 10 scale). All of the work testing and maintaining a full-fledged API falls on Team X. Also, notice that the total amount of work, between both teams, is a 7 on a 10 scale!

 

Instead Team X wants to just export the data (let’s rate this as a 1 on a 10 scale), and let team Y import it and do whatever processing they need to do locally (let’s rate this as a 3 on a 10 scale). Notice that the total amount of work, between both teams, is a 4 on a 10 scale.

 

There’s a solid argument to do what Team X wants to do. First off, there’s less maintenance, less testing, less role based access control work, and potentially less performance challenges when the data is imported and utilized within a single system designed, written and maintained by Team Y! We can take the total amount of work from a 7 on 10 scale to a 4 on a 10 scale. This is an oversimplification, with made up numbers for this fake example, but this is a common scenario I’ve seen many times in interactions between engineering teams. Sometimes asking another team to build “more software” for you, so that you can build less software actually causes everyone to write more total software. This is part of the reasoning used in Martin Fowler’s Monolith First approach. The idea is to add complexity only when it’s necessary (and sometimes it is indeed necessary and we’ll discuss that in the next article).

Conclusions

This article uses two fairly simple examples but the lesson really applies to any set of human relationships where the two parties are seeking productivity. I’ve seen this exact pattern manifest itself in many different contexts:

• Often, sales teams will ask Product Teams to answer a bunch of hard questions about what the customer needs, even though it’s all written down in blogs, product documentation, or sales plays
• Often, programmers will ask sysadmins to do something very difficult in the infrastructure just so they don’t have to figure out how to do it in the code
• Often, sysadmins, network admins, and storage admins ask each other to do difficult things so that the other one can do something easier or more elegant in their configuration
• Often, users on a mailing list will ask the same basic questions over and over and over, even though very smart people with very valuable time have already answered these exact question 42 times before
• Sometimes, product managers will ask engineers do something that doesn’t scale because one very valuable ($$$) customer asked for it

So, how do we avoid this problem?

First off, you should always respect the people you are collaborating with. Whether it’s as simple as asking a question on a forum, or as complex as asking another engineering team to build and maintain an entirely new piece of software. Learn to respect the work the other party is doing for you, and think about how it will affect the long term relationship. Respect and trust are a great start, but you also have to think about efficiency! This is really a people problem which creates inefficiencies across the entire organization, and even between organizations (customers and vendors, etc). The better we can identify and mitigate this pattern, the more efficient we can become, and the more total work we can get done!

So, the next time somebody asks you or your team to do something hard and the hair stands up on the back of your neck because you know it’s not right, re-read this article and share it with them. Or the next time you’re asking some other team to do something that seems so simple, yet they’re pushing back, think about this article. Careful though, it could be a case of efficiency, but it also could be a case where the other team just doesn’t want to do the work. Seek the truth. If it’s more efficient, try to find a way to do the work. But, feel empowered to push back if it doesn’t scale.

In the next article, Part 2: Asking Other Teams To Do Something Really Hard: Platform Software we’ll dive deeper into how this problem expands at scale with platform software.