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.
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 your team is asking some other team to do something really hard so that *your* team can do something really easy. We’re all guilty of this move!
Let me explain with an example. Say that you work in a large software company with many hundreds or thousands of engineers, quality engineers, documentation people, support people, product managers, and product marketers, all trying to release a product. Now, let’s say that your product is a platform for another team (ahem, like Red Hat Enterprise Linux where I work). Let’s call this Product A.
Now, also imagine that a new team comes online to deliver a product built on top of your platform, and they need a specific library or tool as a dependency for their product. Let’s call them Product B. It would be very natural for team from Product B to ask the team from Product A to just add the software to the platform so that Product B can just consume it, instead of maintaining it themselves.
Hold on a second, it’s not nearly that simple is it? No. It’s much more complex than that. Adding a package to a platform requires engineering work, testing work, documentation, maintenance work to patch CVEs over the life cycle. Heck, somebody has to go gather the requirements to even understand how long does the package need supported for. That’s a ton of work. The team from Product B probably can’t even answer all of the questions about requirements for security and life cycle because their product is new and may not even succeed in the marketplace.
It feels really easy for the team from Product B to just ask for the other team to do this work, but it’s actually quite a lot of initial work, and maintenance work down the road. This pattern is common for anyone who works in a large bank, manufacturer, software company with platforms. It’s familiar if you’re a systems administrator, SRE, programmer, or architect. It’s even common between sales people and product managers (What SKU do I sell?). Heck, it’s common if you’ve ever participated in a mailing list, news group, or Reddit group. People ask a question that seems really simple, but never search the list first. They ask you to do something really hard (or tedious, or time consuming) so that they can do something really easy.
Better Alternatives
First off, learn to respect every other function as a business partner. Respect the other engineering team. Respect product marketing, quality engineering, technical writers, program/project managers, support engineers, product managers, etc. Everyone is a business partner, and they should be respected. You should think about your long-term relationship with these other teams. That’s a start, but not enough.
It’s easiest to explain this in the context of engineering, using math. If you’re familiar with Big O notation, it represents the amount of work done by an algorithm, but I’m going to abuse it to represent the amount of work done by a team. And as one of my beloved Computer Science teachers used to say, “if it’s between a better algorithm or more resources (CPU, Memory, etc), I’ll take a better algorithm every damn time!” The same is true with teams.
For example, let’s say that Team B needs a dependency. They have two options. They can do the work of maintaining a library for the life cycle of their product, or they can ask the Team A who owns the platform to do it. If the product succeeds and lives for the entire planned life cycle we’ll call the workload O(n) for Team B, or alternatively with all of the QE, Docs, and Engineering work necessary to add it to the platform, it will be O(n^2).
Even better, let’s say product being built by Team B fails a year into their work and is cancelled, now the workload becomes even lighter. Let’s call it O(1) instead of O(n^2) because Team B can stop supporting it after a year, instead of 10 years.
Now, let’s do a thought experiment and scale this out over several products, customers and partners. If the platform Team A does all of the work, the total of work is:
O(n^2) + O(n^2) + O(n^2) + O(n^2) + O(n^2)
This is quite expensive, because the work is not scaling yet.
Alternatively, we can imagine another way of doing the work, where the platform Team A only takes the work on if it scales to multiples teams, customers or partners. In this next drawing the total sum of the work is much less expensive. Note, I gave Team C an O(n^3) because perhaps they’re being asked to do something for which they have no expertise and it will be very difficult to learn and operationalize:
O(1) + O(n) + O(n^2)
This is orders of magnitude less work. This math is why platforms work, it’s why products in general work. Products and platforms give you approximately what you want, but you still have to do some of the work yourself:
Conclusions
This article is in the context of the relationships between engineering teams but lessons really apply 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 do something difficult
- Often, sysadmins, network admins, and storage admins ask each other to do difficult things so that the other one can do something easier
- 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 this exact question 42 times
- Sometimes, product managers will ask an engineering team do something really hard, which doesn’t scale, because one very valuable ($$$) customer asked for it
This is really a people problem which creates inefficiencies within an organization. The better we can learn to manage this pattern out, the more efficient we can become, and the more total work we can get done!
With the platform example which I focused on in this article, the initial cost of adding a dependency to a product or platform is quite expensive. However, as more and more customers, partners, and internal teams express a need for the same dependency, there comes a point where the math flips. At scale, it’s much cheaper to have the platform team do the work instead of each individual team duplicating the work for their specific needs.
Of course, there are caveats. The platform example above is extremely simplified. Different customers, partners and engineering teams may need different versions of a particular dependency, with different life cycle requirements, and different security requirements, and different performance requirements, etc. To be more efficient, we all need to compromise!
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 still could be a case that the other team just doesn’t want to do the work. 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.