Has someone ever asked you a question that's left you feeling like: "Hmm… but why do you want that"?
Imagine you're spending a weekend in Cariló with a couple of friends. You've brought everything you need, and you've already planned your meals. Just as you're getting ready for dinner, one of them tells you that he needs to go to the supermarket and asks you for directions.
The only supermarket is outside town and it's a thirty-minute drive. It's been raining all day, so the town exits are muddy. Going to the supermarket is definitely not a pleasant trip. You ask whether he’s sure he needs to go and he insists, so you remind him of the best route. He takes off in his car and returns about an hour later all wet, with mud in his shoes, and holding a single item... an air pump.
“Thank god you're here, we're starving. What's that?”
"A pump! We wanted to play football at the beach tomorrow, but the ball's deflated and I left my pump at home..."
You now realize something went terribly wrong. There's a bike repair shop just down the street that would have gladly inflated your football for free.
If you feel like you've been in this kind of situation, you're not alone. This has been studied and it's called the XY problem. The most common definition is "asking about your attempted solution rather than your actual problem." In the above example, our friend needed to inflate the football, and his solution was to go to the supermarket and buy an air pump. So he asked us how to get there, instead of asking about the ball.
When faced with such a situation, we can take one of two approaches. One is just answering the question: "Here's how you get to the supermarket." The other one is to ask about the problem, that is, asking why he needed to go to the supermarket.
From the beach to the office
The XY problem is especially relevant in software development. A fundamental part of our jobs is working at different levels of abstraction, so our procedures have a lot of steps, and we want to make the best decisions in each of them. Let's take the process of a typical feature request as an example:
- Our customer will speak to one of our client-facing teams, such as Consulting or Account Management, about something they need from Avature.
- This team will figure out how the customer's need can be solved within the application, but sometimes it can't. At this point, they might say, "If only Avature had Feature A, then we could use it like this and like that to solve the customer's need."
- Now they will formally request Feature A. The next team in line, Product Design, will figure out the best way to integrate this feature into Avature while remaining consistent with the rest of the application. This includes writing a detailed functional specification (SPEC) that will be used as a reference for the rest of the process.
- Now it's Development's turn: they will read the SPEC and make all the necessary changes in the code to make it happen.
- Once the new code is ready, QA will ensure the quality of the changes and verify that they match the SPEC.
- Finally, Feature A will be officially integrated into Avature. Product will communicate the new feature to all of the interested parties.
You can tell that there are a lot of moving parts, with many teams highly specialized in one dimension of the process. While we can definitely trust one another to do a good job, we are still human, so errors can happen. Here I want you to consider a broader definition of "error." I don't mean an obvious blunder like putting salt in your coffee. To me, an "error" is any decision that we can all agree was sub-optimal.
So for example, what if someone along the way realizes that the Development team is already working on Feature B, which could be used to solve the same requirement as Feature A? This might not be strictly their job. Development can just go on and code Feature A, and QA can just go on and test it. I can just tell my friend how to get to the supermarket. However, if we take the time and think outside the box, we might save everyone a lot of work down the line. In a complex system such as this one, there are a lot of reasons why we might not arrive at the optimal solution. So how do we make sure we don’t miss it?
Here are my three tips:
- Understand the context of what we're doing: to do this, we can use a technique called the 5 whys. It’s a tool used for understanding the root cause of a problem, but we can apply it whenever we need to step back and look at the context. It’s something like this:
Problem: I need directions to the supermarket.
Why? Because I need to buy an air pump.
Why? Because I need to inflate the football.
Why? Because I want to play football with my friends tomorrow.
Why? Because we want to have fun at the beach.
Why? Because we want to make the most of our weekend trip.
You have now laid out each step of your reasoning and you can examine each of them separately. In this example, we might look at line 2 and realize that there's a better way to inflate the ball.
- Always work as a team. If you're asking a question, share the context. If you're being asked a question, make sure you understand the motive before answering. That way, both you and your colleague will be looking at all the steps before making a decision.
- Be open to change. A critical part of teamwork is understanding that sometimes we don’t make the most optimal decisions, and it’s OK. This is only human and we have to be ready to accept it.
Fortunately, working at Avature makes it super easy to apply these tips. As a self-contained SaaS company, nearly everyone working on the product is our teammate, so we can reach out to them very easily. But most importantly, you will find that people here are always willing to help. It’s just part of our culture.
As we work in a large, fast-growing company, it’s increasingly difficult to gather every participant of a project together at the same time for a meeting. Working effectively as part of a pipeline is a key skill for Avaturians, and avoiding the XY problem is a huge step towards that.
Going the extra mile
A couple of years ago, one of my managers gave me a solid piece of advice: "To grow as a developer, you need to learn more about the product." What he was actually telling me is that you can't excel at your job if you only know about your job itself. I'm not a functional analyst, but I'll be a better developer if I know a bit about how functional analysis is done. I'm not in a client-facing team, but I'll be a better developer if I understand a bit about the interaction between customers and Avature. In the same way, colleagues from other teams will benefit from knowing a bit about development even if they don't have a technical background.
The XY problem is a communication issue, so it doesn't depend on your technical skills at all. To prevent this issue, we need to go the extra mile between "answering a question" and "helping your coworker with their problem." It does require us to do a little more extra work, but it’s this work that has made me grow in my career.