Technical Solutions to People Problems
"If you think technology will solve your problems, you don't understand technology and you don't understand your problems"
~ attrib. Laurie Anderson
From a Toot by Jake Rayson
In a previous post, I wrote about how to ask why without sounding like a jerk. This is a slightly related concept (at least in my head).
Sometimes, as technical people, we are asked to solve problems. The more we dig into them, the more we discover that the problem that needs to be solved isn't a technical one but a people one. In many cases, it's just getting two groups to actually talk to one another.
This can be hard and awkward, so people may want to avoid it. Creating a report telling someone they're doing something wrong is way easier. No hurt feelings! However, I've found that the approach tends to create more problems than it solves.
The situation
The situation is a real one, and I'm obfuscating details to help 'protect the innocent'.
At the start of each year, large amounts of new data are needed to be added to a system. The additions are, by their nature, very manual1 and so the team responsible for them spends much of their time trying to get the data added.
Another team is highly dependent on this new data being added in order to process their widgets2. The widgets get loaded into the system and checked to see if the data from team A is complete. If it isn't, then the widget gets flagged. This flag directs the members of Team B to reach out to Team A to get clarification on the state of the data needed to process the widget.
Only, that's not how Team A understands it. While they are furiously trying to update data, there is some basic data that covers roughly 80% of the widget processing data needs that are already available. So, the vast majority of the time, there is no need for Team B to reach out to Team A because the information they need is available in the system to process the widget.
This understanding was either lost or never communicated effectively so Team B would just email Team A with questions about the widget data and then get their answer and move on. This is despite the fact that the information is available in the system for the members of Team B to review!
The leader of Team A asked me if I could 'update a report' to 'remove some of these widgets so Team A could better focus on the work of adding the data'.
I thought that seemed reasonable, so I asked Team B a few questions and then made a bit more discoveries and found out the actual problem, which was that the information needed by Team B was in the system. Team A just needed Team B to do a better job of looking for it and asking questions about the things that were needed instead of everything.
The Solution
I proposed that the leaders from Team A and Team B get together to talk about the issue.
At the meeting, the leader of Team B was horrified to hear what was happening. They had no idea that many emails were going to Team A about questions that the members of Team B should be able to answer on their own.
This is all well and good, but why did it take a tech person to spot this and get the team leadership together to figure it out?
I wish I knew the answer. I think part of the insight I had was the current pipeline of work, how long it was going to create a report, and the need to have the problem solved sooner rather than later didn't line up. At all.
I needed to look for a potential non-technical solution. The other thing that I think happened here is that I wasn't weighed down by any history of interactions between the Teams. I was just trying to gather information. In gathering information I was able to see what the real problem was and that the only solution that made sense was for the two teams to just talk to each other.
The Outcome
During the meeting, Team B committed to retraining staff and helping to make sure that they only reached out when there was an actual question about the data for the widget production. Team A was thrilled with this solution, and now they can focus on getting the data into the system more efficiently and with fewer interruptions. A win-win, all because a tech guy got some non-tech people to talk to one another.
How to ask why without sounding like a jerk
As technical folks working with non-technical folks sometimes the asks that come through are unclear. In order to get clarity on these we want to ask questions to get clarification on the ask, but it can be challenging to not sound like a jerk when we ask. This can happen even IF we do our best to come across in a positive way.
When trying to ask for more details on a project or request I find it's usually best to get to the source of the issue. I like to ask, "What problem are we trying to solve here?" or something similar.
This helps to put you and the requester on 'the same team' trying to 'solve the problem' and not in a potentially negative 'why are you asking me this stupid question' sort of light.
I can't say that I have 'one weird trick' that will always make this not a problem, but recently at my $dayJob I had an experience that might be helpful in seeing how to navigate this particular process.
The problem
I received an email that went something like this
Please see below. It seems that delivery of paper reports via courrier could be automated by sending them to a portal. What are your thoughts?
My initial thought was, "Yes, if we could automate these reports and send them electronically to a portal that would be more efficient."
However, there are some deeper questions here that need to be asked ... like:
- Why are we sending these reports in the first place?
Just asking this question though puts us into a potential state of conflict, i.e. it's similar to sounding like you're asking, "why would you do this stupid thing". In order to avoid this I reframed the question into 3 deeper questions that tried to frame 'the problem' and put me and the requester 'on the same team' to 'solve the problem'
- What are the reports?
- What are the recipients of the reports supposed to do with them?
- Do the recipients of the reports find them helpful, or do they just put them in the shred bin?
My first response to the sender was
Ideally any reports that are being delivered on printed paper by courrier would be better served to be delivered via some electronic means. Can you tell me, what are these reports and who are the intended recpients?
I wanted to explicitly ask who the intended recipients were (I work in Healthcare and these reports are 'for the doctors' but they might actually be getting delivered to an office manager, a front desk person, or anyone other than the doctor).
The sender responded back
They are reports that show a key metric for outstanding work left to do for a specific population of their membership. Each doctor (or their office) are free to do, or not do, anything with the information in these reports.
Next I asked if the recipients had been surveyed on the usefulness of the reports and that's when the sender indicated:
Actually, no. It's something that we need to do so that we can potentially consilidate reports and/or eliminate unhelpful reports.
The Solution
At the end we decided that before anywork was done to 'automate' the delivery of these reports, that we really needed to address the contents of the reports and determine which parts of them were helpful, and what parts weren't. Once we have a single report, or potentially a suite of reports, the automation and delivery work could actually start.
By working through and trying to determine the actual problem that needed to be solved by asking questions to help both me and the requester better understand what the real ask was, we saved a ton of development time and have a better path forward for making the information we have more relevant and actionable by the doctors' offices.
Will this work in every situation? Maybe not, but I believe it's a good starting point when trying to solve 'real world' problems in a work setting.
Tech folks have a (sometimes deserved) bad wrap, but we can shed this negative impression by showing the people that request solutions from us that we're both working towards the same goal of solving the problem.