How can I encourage a coworker to report problems and describe those issues but not to suggest solutions?

Question

I am a software engineer. My team and I frequently work with a team of data analysts to help them load and retrieve data from our software.

The analysts we work with are simply brilliant. They are very astute men with a keen eye for detail. Inevitably those detail oriented men find bugs and issues in our software.

When reporting these issues they very often suggest solutions. While input on a solution is appreciated, their suggestions are often not implementable in software because of other software requirements which the analysts are not familiar with.

We often get bogged down explaining why their suggested solution won't work instead of getting more details about the problem itself. I think that our analysts would be less stressed and my engineers would be better able to solve problems if we could focus on reporting and understanding the problems and requirements then getting the engineers free to work on the solution.

How can I encourage my analysts or any other internal or external stakeholder to report issues and problems and stay focused on the describing the issue and requirements rather than directly suggesting solutions?

Answer 1

This is one where I'd look for sideways solutions. Say point blank that you don't value their input and you won't get it. But (as you've reported) - spend lots of time validating the idea, but explaining why the solution won't work, and waste lots of time and get very little value.

I've had a lot of success with guiding the conversation to meet my own ends on these. My goal is to - (1) confirm and clarify the issue (2) clarify what the criteria for a solution are (3) vet an approach that leads to a final answer

Confirm issue

So that's where I start - I don't start with whether or not the solution will work, I start with getting the full details of the problem, clarified in engineer-speak (not analyst-speak). I don't know quite how the issues come to your doorstep - phone calls can be very different from something with a time-delay like email or trouble tickets.

But in all cases, I'd make it clear that you take their input and the nature of the issue very seriously. But I usually like to have a checklist and I don't mind telling the users that I need to fill this out before we get to the solution part:

• What did you see that was wrong/bad?
• Was is the data or the way it was presented?
• What were you doing when it occured?
• What is it keeping you from doing?
• Does it happen any other time? Can you make it happen again? Can you give me steps so I can make it happen again?
• What's the priority here? (should be somewhat corrated to "what is it keeping you from doing?")

I know it sounds crazy, but also make sure the users are very much aware that you are taking notes, and getting it all down. Paraphrase what you heard back and make sure you've got it right. A bunch of rapid fire questions asked perfunctorily will generate a hostile response. A deep conversation about the problem will soothe the fear that you aren't going to do anything about it.

It needs to stay somewhat on track, but when you get to "what were you trying to do?" and "what can't you do with this problem happening?" - let it go a little into the analyst's world. While you can't solve the problem "their way", you do need to solve the problem in a way that works for them, and that means you need to know more than a little bit about what they are trying to get done. It's a mushy space - you can spend infinite time here, and smart people LOVE talking about what they do - so there's some work guiding the conversation on these.

Clarify the requirements of a solution

Unless the issue is mind-bogglingly clear, there are probably numerous available solutions. But a solution for the analyst is not necessarily feasible and a solution for the SW developer many not actually be a solution for the analyst. Side step the "I'm right/you're right" conversation and talk about the requirements for the solution.

Sometimes I can break it into two parts: - If I was to give you something quick and dirty, what is the absolute smallest change that I could make that would satisfy you? - If I had a magic wand and could fix it right now for no time and no effort - what would the solution look like?

From there, it usually falls on the software person to redefine these solutions as requirements. Although analysts are really smart, factual, information aware people - they are not software developers and they don't understand the very specific jargon that is used in the methods of designing a user experience. So I usually end up stating what I think is obvious about the requirements of the two solutions - "must haves" being anything in both the bare minimum and the gold plated option. "Want to haves" in the ideal solution only. I ask for two peices of data, because I often un-cover a lot of hidden "I don't need it it at all, it's just my assumption" type stuff in that "bare minimum" solution that doesn't ever show up in the "nice to have" solution.

Just like developers assume things about users, users often make assumptions about what's "easy" - usually they are decent and don't want to be a bother, so they ask for what they think is "easy" and then get stressed when you tell them their solution is not at all easy...

How's this?

Usually a simple change is something that the developer and user can agree on on the phone at this point... but I'm going to bet that the degree of frustration you describe is not usually of that type.

So the developer may need some time to craft something. But this is a good time for prototypes, screen shot samples and other ideas to get vetted back to the user before any heavy lifting occurs. It's like a mini-agile project - throw something at them and get insight on whether it works before really implementing and testing anything.

Taking time here is OK. I know I always feel pressure to jot something on a whiteboard and be done with it... but this is the time where you can stop for a sec and really think it out before promising the impossible. I've found that taking a few moments to think here actually builds trust, because at this point they realize the problem isn't "easy" but you are as engaged in making a solution as they are in getting the problem fixed.

Conclusion

This usually builds a lot of trust. You've never said "no", "you're wrong" or "your ideas are utterly impossible", so you never built the resentment that comes from being shut out. People usually like providing the details of their problems, their dreams of a perfect product and giving opinions about something that isn't made yet - so you're not asking for anything crazy.

I've found that very rarely do people (even high level people) expect that you will do what they ask for with no questions, concerns, or alternate ideas. In fact, most smart people realize that there has to be a round of question asking before going forward.

It's just how you pace the questions and which ones you ask.

Answer 2

I don't think the fact that they want to suggest fixes is a problem, I think that is in fact very good, because sometimes it may work and if they constantly don't work for the same reason, it may be worth trying to fix that limitation.

What does need to be trained is the trust that when the engineer says that it won't work, they shouldn't have to explain why. They should be thanked for their suggestion and encouraged to continue to think of possible ways to fix stuff, but also need to trust that engineering will do it's job and if the idea won't work, they don't need to know why it won't work, just that their effort to help isn't simply being ignored.

Answer 3

(Full disclosure - I am a very senior data analyst.)

Data analysts are developers too. Start treating them with the same respect you would give another developer working on an application related to yours. That is what they are. Of course they should make suggestions. Of course you should be free to do your own fix. You know things they don't about the application, but they know things you don't about how the data is used outside your application. Work together for solutions that fit the needs of both groups.

If they are frequently making suggestions, it means that your solutions have probably frequently been causing problems for them. You need to hear more about why the solutions you have don't work for them and listen to their suggestions seriously and try for a middle ground solution that gives both groups what they need.

If the suggestions has something to with the structure of the database (including things like constraints, Foriegn keys, table structures) then they are the experts and you should listen very carefully. Sometimes things that make life more inconvenient for you will drastically improve the quality of the data which is very important to the people who have to write reports and data exports for the clients. It's pretty embarrasing to explain to the client why you have duplicate records for instance because the application developers didn't put any controls on data entry. When the data is used for regulatory reasons, it can go beyond embarrassing into the realm of serious legal trouble for the organization.

I have often seen developers design for the short term considering only what will be fastest and easiest for me. When accessing data, that is a losing strategy because bad data or bad database performance is far more critical. Often application developers don't see the real performance and data problems because they don't have to pull reports with thousands of records. They don't have to explain poor data to the client. What seems a good solution when only looking at entering one record at a time or pulling the 15 records you want to show on a screen is not a good solution to the people who have to consume the who data set later on.

So listen to the suggestions and treat them seriously. If an application developer on a another project made a suggestion because your product affects his, wouldn't you take it seriously? Would you resent having a conversation with him to explain why that won't work or to expore other possibilities. Data analysts deserve the same treatment.

Answer 4

This is a great question and one that has come up in all organizations I have worked for. When tackling the problem it's important to keep in mind that most people offering solutions think they are being helpful without realizing the additional legwork required to deal with solution based feedback. The root of the issue is of course cultural but can typically be boiled down to two things:

1. A lack of understanding of your process
2. Confusion about the roles/skills of the different teams and/or team members

It might at first seem obvious, but understanding how development works in your shop is key for all teams. What does the development process look like from above? What players are involved at various points? What is your iteration cycle? Where are your checks and balances? A short presentation/conversation about how the moving parts fit together is crucial for teams to develop a mutual understanding and respect for the process. This discussion will set the stage for your follow-up (and more pointed) conversation regarding team roles.

Understanding one's role is essential within an organization but equally important is respect for expertise. It sounds like you have excellent teams but their understanding of where their expertise fits into the process is misunderstood. Addressing the issue as a group by visualizing and discussing the hand-off from analyst to engineer will help. Make sure the team has some discussion around the efficiency gained by making the feedback cycle more streamlined. Your team should be able to go from: problem -- engineer proposed solution (getting additional feedback when necessary) -- development. Again, this is a good place to highlight essential parts of your process: code review, iteration cycles, user testing, etc. to help everybody trust the team and the checks and balances you have built into your process.

Another strategy I have used is the "I have your back" strategy. The relationship between analysts and engineers can really solidify when people feel like they are backing each other. If analysts focus efforts on understanding problems, requirements, and good reporting, they can release the engineers from the stress and distraction that results from having to backpedal. Getting the analysts on board with how key their role is, will build pride and help them stay focused.

And finally, a third issue often presents when teams providing feedback lack the terminology used by development teams (eg. bugs, enhancement, new feature). This issue can usually be quickly corrected through a simple presentation explaining the differences, posting the agreed upon definitions, and creating of mechanisms for feedback. This issue doesn't seem to match your particular situation (it aligns more closely with customer service units providing feedback) but I thought it was worth mentioning.

Answer 5

In the reporting tool, give them two fields:

Please Describe The Issue in Detail
[                                         ]

If you desire, please add a suggested fix
[                                         ]

Then just ignore the second field on the back-end.

;)

Answer 6

Trying to get them to change their communication style is going to be an uphill battle at best. You need to focus on the side of the conversation you can control: yours. Use their description of a solution to come to a description of the problem, then lead them to a description of a solution that fits requirements they are not aware of.

When they first come to you with a solution, don't start talking about why it won't work. First talk about why they think it would work. Lead this conversation to get a good description of the problem. Then propose an alternative to their solution that meets requirements or uses technologies they may not be aware of. If they still object, only then do you describe why their solution is unfeasible.

It's also helpful not to think of these sorts of conversations as getting "bogged down." It's an important part of the job, and is one of the reasons you had to take those non-technical classes in order to get a degree. By all means, strive to make communication as efficient as possible, but if you need to spend time educating your analysts, you shouldn't consider it wasted time.

Answer 7

Be thankful you're not just getting solutions without any identification of the problem itself.

Make sure you provide an explanation for the solution you implemented. You don't have to cover every possible scenario, but you could mention something about their suggestions. For most problems, they should be able to figure out why you had to do it your way. If not, you would have to elaborate.

Look at this as part of the learning process. If I think things should be done 1-2-3 and you have a reason for 3-2-1, I'm going to be at a disadvantage in trying to implement your solution if you don't tell me why. I'm guessing what you do is very complicated and it's important for everyone involved to be on the same page.

Answer 8

This appears to be a flaw in the process of issue reporting in your organization.

Take a Doctor's visit for example. Many people have become wikipedia doctors thanks to a few hours researching their symptoms online. Now, the model for diagnosis encourages and even requires user(patient) feedback. You now have patients poisoning diagnoses with stuff they read online.

The current model of your error reporting permits or probably even encourages too much feedback from the bug reporter, forcing you to have to play 21 questions with your analysts. I'd recommend

1. Establish a formally documented error/bug reporting process/procedure that clearly outlines the players involved and their respective roles

2. Invest in tools/methods that will put some distance between you and the analysts (JIRA at least). The distance/disconnect fosters some measure of encapsulation between the parties involved. When most of the issue tracking/reporting happens over a forum like JIRA, IMO, the issue reporter will find it less convenient to banter/discuss likely solutions (given the proper definition of roles within the system that is). Your team can basically pay attention to the important bits of any given JIRA and not pay attention to the more time-wasting discussions

Answer 9

I originally wondered if there was a disconnect in the groups between what my company calls "bugs" and "enhancements." Quite often an issue can be slotted into either category, but many fit better into one or the other. Information is returned as the wrong datatype: bug. Analyst wants the ability to have data converted between types upon retrieval: enhancement. So perhaps the analysts were suggesting solutions as part of enhancement requests. Some comments by the OP on the question and the various answers imply that might be part of the problem, but only a small part.

Hold some cross-group seminars. They could range from an explanation of the various software that the developers have to deal with to analyst workflows. Videotape them so that new employees can watch them too. I think that would help both groups understand what is and isn't possible.

I don't feel this is a complete or the best answer of course, but it's too long for a comment!

Answer 10

The proper solution for this is a bug tracking database, where the analysts can not only report bugs, but also submit their ideas as feature requests (instead of wasting time discussing it with you). There could be some diamonds among the coal pieces there.

If someone comes up with a very good idea or two, you can incorporate it as a feature in the next milestone.

[T]heir suggestions are often not implementable in software because of other software requirements which the analysts are not familiar with.

The analysts are not actually telling you what kind of code to write? Lead them to describe the solutions in terms of use cases. Things that look unimplementable in the short term as a bugfix can be doable with the proper planning and investment of resources.

It's difficult in software to get ideas, so you should pick as many brains as possible.

Answer 11

Perhaps the best solution would be to empower them to generate ideas that are actually implementable based on the limitations that you are manageing, in order to do this you could streamline the documents with the scopes and bounds of the proyect.

In case the ideas keep being overwhelming, implementing a format to submit bugs including a possible fix field (which you could decide to ignore) might be the way to go.