I’ll tell ya a story.
Once upon a time there was a team that had it pretty good. They were internal-facing in a VBCA, supporting a variety of analysts of different types, with about 3 dozen small projects clustered around a large but mostly stable analysis model. The work was mostly about fronting the analysis model in several different ways to several different other teams, each of whom had different (fairly cool and interesting) needs.
So they rolled C#, and some webbish stuff, and even some custom excel. They did a lot of re-use, because each individual project was actually reasonably small, assuming one had grokked the analysis model.
And they were killin’, our team. They were shipping more value faster to more people than any other internal team in the org. They were modest-sized, a dozen folks. They got along, they worked hard, they were generally relaxed-with-pep, which definition is a whole ‘nother story.
But they wanted to soar. Sure, they were doing well, but they wanted legendary. Which was cool. Is cool. That’s cool, and I totally get it. A refusal to settle for "good" when you can clearly see "better", that’s a thing I can get behind.
Anyway, they had just one complaint. They couldn’t soar, because their user base just would not leave them alone. Just wouldn’t stop calling them, slacking them, stopping by and chatting them up. It was non-stop.
Some of all that was people trying to cut and line and get their next little story by speaking directly to a geek. (That’s a good problem to have if you know how to say "No.") But not most of it.
Most of what they got was either a) questions whose answers were right there in the document, b) requests for features it already had as described right there in the document, c) deep analysis model questions that were answered carefully and well in the document. That constituted something like 80% of their interruptions. And had those bozos — ok, professional mathematics and engineering and economics bozos — only spent time with the intense, up-to-the-minute, well-written documentation, our team could spend its time soaring.
So the team, however foolishly, asked me what to do. Except they didn’t really. I mean, they didn’t ask me what to do. They asked me how to pull off what they had decided they needed to do. The questions amounted to: how do we yell at users so they stop bothering us, and if that means re-structuring user contact what’s the best way to structure it, and if it means new rules what should they be, and if it means power-politics how should we gain leverage?
Do you know we spent nearly two hours trying to get past a problem-description that was anything other than "users are
Two hours.
The users were dumb, lazy, irresponsible, poor-disciplined, malevolent, it just went on and on. And with each of those negative adjectives, a slightly different solution-approach came to the fore.
They listed maybe twelve all told, each of which consisted of some combination of walling the users off from the team or making the users into better people. "Which mixture of A Cask of Amontillado and The Tell-Tale Heart should we apply, oh overpaid if highly attractive consultant? We’ve been debating this amongst ourselves for months?"
[Editor’s note: that’s not exactly their words.]
You know the answer I gave. I told them to put their copy of Poe away and address the root problem: …
…the users come to you with dumb questions because they have dumb questions. If they didn’t have them, they wouldn’t come to you. What if you made it a good deal more difficult to use the program and still have dumb questions?
We came up with five ways to reduce the dumb-question-ableness of the program in about twenty minutes. The one we liked the most? Just-in-time task-oriented help permanently on the screen. It was even easy to code, because the documentation was already task-oriented and already well-factored and well-written.
It amounted to having hypertext links that set a couple of context variables, followed by each field-exit altering the context variables and letting the next piece of text fill the window. We sketched out an iterative approach to altering the code — remember this code would be used by a few dozen projects, many written in different languages.
Now, I honestly don’t know whether they implemented it or not. When I left, though, they were gung-ho, so I like to think they implemented something other than a wall or a tribe of new superhumans.
So what did it take?
It took them changing their description of the problem. They went from "users interrupt us all the time with their dumb questions" to — wow, so similar, but so different — "users have dumb questions when they user our system".
This is relevant, of course, to today’s muse, which was about interruptions. The case from today is definitely different, but the muse triggered the recollection, and I think the primary moral of the story is really the same, and that it’s broadly applicable in lots of contexts.
That moral is this: It is often the case that you can get much better solutions by changing how you define the problem. The problem today could be described as "interruptions must be stopped". Or it could be described as "interruptions make us have to start all over". One of those problems is a lot easier to address than the other.
Take it away from the interruption thing. Here’s a real-world case that is taking place with me right now: "Write microtests against JavaFx" vs "Write the JavaFx in such a fashion you don’t fear its testlessness". The former was killing me. The latter — I’m closer every day.
And one more for the road: "We need to not make mistakes." "We need to find our mistakes before we ship them."
Same problem, really, but the solutions are the difference between 1980’s geekery and 2019’s geekery.