{"database": "pelican", "table": "content", "rows": [["ryan", "musings", "> \"If you think technology will solve your problems, you don't understand\n> technology and you don't understand your problems\"\n>\n> ~ attrib. Laurie Anderson\n\nFrom a [Toot](https://mas.to/@natureworks/113917094844091858) by [Jake\nRayson](https://mas.to/@natureworks)\n\nIn a previous post, I wrote about how to [ask why without sounding like a\njerk](https://www.ryancheley.com/2024/08/22/how-to-ask-why-without-sounding-\nlike-a-jerk/). This is a slightly related concept (at least in my head).\n\nSometimes, as technical people, we are asked to solve problems. The more we\ndig into them, the more we discover that the problem that needs to be solved\nisn't a technical one but a people one. In many cases, it's just getting two\ngroups to actually talk to one another.\n\nThis can be hard and awkward, so people may want to avoid it. Creating a\nreport telling someone they're doing something wrong is way easier. No hurt\nfeelings! However, I've found that the approach tends to create more problems\nthan it solves.\n\n## The situation\n\nThe situation is a real one, and I'm obfuscating details to help 'protect the\ninnocent'.\n\nAt the start of each year, large amounts of new data are needed to be added to\na system. The additions are, by their nature, very manual1 and so the team\nresponsible for them spends much of their time trying to get the data added.\n\nAnother team is highly dependent on this new data being added in order to\nprocess their widgets2. The widgets get loaded into the system and checked to\nsee if the data from team A is complete. If it isn't, then the widget gets\nflagged. This flag directs the members of Team B to reach out to Team A to get\nclarification on the state of the data needed to process the widget.\n\nOnly, that's not how Team A understands it. While they are furiously trying to\nupdate data, there is some basic data that covers roughly 80% of the widget\nprocessing data needs that are already available. So, the vast majority of the\ntime, there is no need for Team B to reach out to Team A because the\ninformation they need is available in the system to process the widget.\n\nThis understanding was either lost or never communicated effectively so Team B\nwould just email Team A with questions about the widget data and then get\ntheir answer and move on. This is despite the fact that the information is\navailable in the system for the members of Team B to review!\n\nThe leader of Team A asked me if I could 'update a report' to 'remove some of\nthese widgets so Team A could better focus on the work of adding the data'.\n\nI thought that seemed reasonable, so I asked Team B a few questions and then\nmade a bit more discoveries and found out the actual problem, which was that\nthe information needed by Team B was in the system. Team A just needed Team B\nto do a better job of looking for it and asking questions about the things\nthat were needed instead of everything.\n\n## The Solution\n\nI proposed that the leaders from Team A and Team B get together to talk about\nthe issue.\n\nAt the meeting, the leader of Team B was horrified to hear what was happening.\nThey had no idea that many emails were going to Team A about questions that\nthe members of Team B should be able to answer on their own.\n\nThis is all well and good, but why did it take a tech person to spot this and\nget the team leadership together to figure it out?\n\nI wish I **knew** the answer. I think part of the insight I had was the\ncurrent pipeline of work, how long it was going to create a report, and the\nneed to have the problem solved sooner rather than later didn't line up. At\nall.\n\nI **needed** to look for a potential non-technical solution. The other thing\nthat I think happened here is that I wasn't weighed down by any history of\ninteractions between the Teams. I was just trying to gather information. In\ngathering information I was able to see what the real problem was and that the\nonly solution that made sense was for the two teams to just talk to each\nother.\n\n## The Outcome\n\nDuring the meeting, Team B committed to retraining staff and helping to make\nsure that they only reached out when there was an actual question about the\ndata for the widget production. Team A was thrilled with this solution, and\nnow they can focus on getting the data into the system more efficiently and\nwith fewer interruptions. A win-win, all because a tech guy got some non-tech\npeople to talk to one another.\n\n  1. yes I would like to automate this, but one step at a time! \u21a9\ufe0e\n  2. Not actually widgets \u21a9\ufe0e\n\n", "2025-02-06", "technical-solutions-to-people-problems", "> \"If you think technology will solve your problems, you don't understand\n> technology and you don't understand your problems\"\n>\n> ~ attrib. Laurie Anderson\n\nFrom a [Toot](https://mas.to/@natureworks/113917094844091858) by [Jake\nRayson](https://mas.to/@natureworks)\n\nIn a previous post, I wrote about how to [ask why without sounding like a\njerk](https://www.ryancheley.com/2024/08/22/how-to-ask-why-without-sounding-\nlike-a-jerk/). This is a slightly related concept (at \u2026\n\n", "Technical Solutions to People Problems", "https://www.ryancheley.com/2025/02/06/technical-solutions-to-people-problems/"]], "columns": ["author", "category", "content", "published_date", "slug", "summary", "title", "url"], "primary_keys": ["slug"], "primary_key_values": ["technical-solutions-to-people-problems"], "units": {}, "query_ms": 0.8821198716759682}