Telling a colleague "Your approach isn't working" is difficult. It’s not easy to say even to those within your own team, but saying it to someone from another team is even harder. When you focus only on the problems that need solving, it becomes clear who should do what. However, when teams are involved, it’s easy to lose focus on problem-centered thinking.
Small teams can efficiently solve smaller problems, but most real-world problems are large-scale. Multiple teams need to tackle different parts of these larger issues. Unfortunately, the boundaries of teams can sometimes obscure the larger problem, leading people to focus on optimizing small problems that don’t contribute to solving the big one. Local optimizations within a team are rarely the solution for the whole system. To optimize the entire system, we must focus on the bigger problem.
How can we maintain problem-centered thinking in a collaborative environment? The answer is surprisingly simple: we need to remind people who have lost sight of the problem to focus on it. By logically proposing that we work with the problem in mind, most engineers would be receptive to the idea. However, many engineers struggle to voice this out.
Here are some common reasons why:
- The “Let’s Keep it Nice” Type: “Why should I be the bad guy? Let’s just get along and avoid conflict.”
- The “Special Forces” Type: “If another team doesn’t cooperate, we’ll just do what we can and leave them out.”
- The “Tit for Tat” Type: “I’ll help this person now, and hopefully, they’ll return the favor later.”
- The “Silent” Type: “...”
Let’s talk about the most common example, the "Let’s Keep it Nice" type. Most people want to be seen as capable. Very few aim to be seen as "nice" for the sake of it. But in reality, we often choose to act "nicely" because it’s the easier path, providing immediate positive feedback. However, this leads to a "greedy algorithm" type of decision-making, where every choice is made with a short-term gain in mind, but the overall long-term result is compromised.
There’s also the "Special Forces" type, who may choose to work alone when cooperation from other teams is hard to get. This is a problem in itself because if a task is something one team can complete, it may indicate the initial size or scope of the task wasn’t correctly predicted. Even highly skilled developers who rely on past experience of working solo may miss out on achieving greater success if they don’t consider the larger-scale collaboration required for bigger results.
The "Tit for Tat" type often tries to balance between getting things done now and building future cooperation. While this strategy might occasionally work, it leads people away from solving the actual problem, focusing instead on personal or team relationships. Often, these individuals are labeled as “political” rather than truly focused on the core task. Let’s remember that as developers, we are engineers, not diplomats.
Lastly, the "Silent" type is the hardest to understand. It’s as though they hope for failure, refusing to speak up and contribute. Sometimes these individuals appear to avoid engagement because they have made mistakes, but silence in the face of problems is not a wise solution. When solving problems, it’s essential to speak up and contribute to the discussion.
If we can challenge our colleagues to say, “There’s a better way than the approach you’re using,” and encourage them to think "problem-centered", we can guide teams back on course. The goal is not just to avoid issues but to steer our collective efforts toward solving the bigger, more significant problems.