Provide requirements not solutions
Being an engineering team that serves internal customers comes with its ups and downs. One of my biggest pet peeves on such teams is the task of customer requirement gathering. While I can’t speak for non-infrastructure, non-internal development teams, this pattern is highly prevalent on internal teams serving other engineers and technical staff at a company.
It usually goes this way. A customer using your systems has additional requirements or needs that they would like met in order to accomplish a goal. The customer proceeds to communicate this to you as something along the lines of “System X needs to implement feature Y so that I can do Z. Oh, while at it, you should add feature R and fix bug Q that’s been slowing us down”. In the most extreme of cases, you get sent a technical specification detailing features and modifications you should make to the system; diagrams included.
Unfortunately, the biggest challenge you then face, is that you don’t understand what specific problem the customer is trying to solve. You don’t know the exact requirements needed from your system. Sure the customer is presenting a solution to you but they don’t have the same depth or knowledge of the system. They are neither knowledgeable on all the design decisions and trade offs made nor are they typically able to propose a solution that gels with your current ecosystem.
This leaves you in a bit of a bind. It will take a long time to read through the document and understand the proposal. Similarly, it will take significant time to consider the impact of their new feature suggestions on your system. However, you can’t tell them no because they’ll ask why and you don’t know exactly why. You are frustrated that this happened yet again, but eventually suck it up, go through their requests and formulate a response.
Deep down though, you wish they’d tell you what problem they’d like to solve and then give you the opportunity to design a solution that solves it. “We are trying to build this new feature and will require data X,Y,Z from our service. We’ve got an SLA to meet and so need at least an RPS of Q. Per our current tests, our current service infrastructure seems unable to support that. What do you propose?”. That, right there, is the dream. Having grasped their requirements, you’d go ahead and either propose changes needed to your systems/infrastructure or explain why their request is unfeasible.
Instead, you end up going back and forth on their feature request(s). You discuss the details, and the trade offs. You explain and provide more context on your current system and then rinse and repeat. Finally through this dialogue, you grasp what their needs are and provide a possible solution. However, you are both frustrated, and have both spent a lot of time getting to this point. It could have be better.
Why does this happen? Why do attempts to be helpful end up this way? In most cases, the engineer that made the request is trying to be helpful. But, in their attempts to be helpful, they make things worse. I think that situations like this are very common among collaborating engineering teams because of what I like to call the expert fallacy, but that is more commonly known as the Dunning-Kruger Effect.
In the case of the solution provider, this boils down to a little knowledge leading to overconfidence. The phenomenon is best illustrated in the graph below in the difference between an expert and someone that is moderately acquainted.
The mismatch between what people in the Young category think they know versus what they really know is huge. As they believe that they know a lot, they don’t hesitate to provide solutions. I think this happens a lot in engineering because we all fundamentally do similar things: we all code, and build software. This makes it easy to assume we have a good handle of other’s systems. A good enough handle to tell them how it should evolve to meet our needs. Unfortunately, the receiving party of our proposed solution is typically an expert of the system. The expert sees all that is unknown and shudders inside.
How then do we prevent this scenario? I think there are two improvements that can be made on both sides. Firstly, to get better at dealing with customers that propose solutions, harness the skill of asking follow up questions. Focus on understanding what the underlying customer need is so you can propose a good solve. Harness your inner product manager and remember articulation of needs is hard.
On the flip side, if you are requesting changes to a system you neither own nor understand the nitty-gritty of, provide requirements for what you’d like and not solutions. Get better at articulating exactly what you need and leave the proposal of how to solve the need to the system owners. This will save the time of everyone involved and foster a good relationship between you all.
No one goes to their doctor and tells them what to do. Why then do we do that to other engineering teams? Because WebMD came along and we all now think we are “doctors”…