Over the years, in various software development roles, I’ve learned to stop thinking of people as individuals. But it’s not a bad thing…
A couple years ago I was working on two layers of an application: the Node.js proxy/translation middle tier, and the backbone-based single-page web app. After some investigation into my highest-priority task, I determined that I didn’t have what I needed to implement it without a change in the third layer: the backend. I assembled a message with the intended customer experience and our high priority for the feature, then sent it off to the backend team.
The response was that they could deliver my requested functionality in three months. I escalated to leadership, and that ETA shrank to two months. I joked that I should just go make the change myself in their system, then moved to the next task on the backlog.
Fast forward to a couple weeks later. The same backend team calls me and asks for my signoff on a change coming in the next release of their system. As I pushed toward clarity with many questions, it dawned on me that this new feature was worthless from my perspective. It didn’t enable any new features for the customer, and would require changes from me to keep key functionality from breaking.
Putting these two situations side-by-side, we just weren’t getting along. How could they be so out of touch with my needs? With the customer’s needs? As far as I knew, I was their only client. Were they just selfish, using scheduling as an excuse to be lazy? Was I being selfish?
The answer: neither. It turns out that we were both being reasonable.
Their system, the incentive structure for their team, was different from my system and its incentives. We like to think of ourselves and others as independent agents, but we’re always inside of a context. What may look like a bad or selfish person is simply someone responding to their system. Unless we make particular effort, we’ll wrongly evaluate others’ behavior in our context.
What was defined as success for me was not defined as success for them. Just like me, members of the backend team were trying to do a ‘good job.’ For them, a ‘good job’ was to deliver what they promised, and to avoid bugs in the features delivered. A ‘good job’ for me was to deliver a different set of features.
Because I was working on features for the browser, I thought I had a better handle on user needs, therefore my requests were better justified. But it’s ultimately their backlog against my backlog.
This kind of conflict is a common problem in large companies.
Smaller companies, especially early-stage startups, don’t have this problem very often. Why is that? It’s because their systems are designed to encourage the right behavior.
In these kinds of organizations, everyone has a clear goal in mind - bottom line impact to the business. You can trace everything you do to that bottom line. So instead of abstract backlog versus backlog priority negotiations, you can talk about each item and its potential for increased customer satisfaction or revenue, using real data.
Additionally, smaller teams frequently empower each individual to do whatever it takes for the business. There’s no backend team, because everyone works on the entire app. It’s true agile, because every feature in the single, prioritized backlog is a true user story, resulting in new business value.
So you’re not at a small, agile organization. What can you do? You can take on a new perspective.
If you’re an individual contributor, try some of these:
If you’re a lead, you can consider a few more, higher-level tasks. Even without the power to directly change these, you could still lobby for them:
No matter where you are in an organization, this kind of approach is useful. And it turns out that understanding the larger context is useful in many situations beyond business.
Some might even call it empathy.