The Abstraction Problem
A few weeks ago I was in a status meeting, listening to the test tooling problems with the current project. The conversation was down in the details, talking about how the blizblang won’t connect to the floob-flob, and maybe if we use XML to serialize the data we can create a web service that blah, blah, blah.
I want to avoid the details here to protect the client, but also to note that the details don’t matter. What management wanted was some sense of when is this thing going to be done, while the technical people wanted to talk about the challenges and problems with this thing.
The truth is, the technical people don’t know when it will be done. They have all week to figure it out. They’d like to talk about figuring it out, and this seems like a reasonable topic.
Management has an hour or two for this conversation, but not all week. And management needs to report to senior management, who has at most fifteen minutes.
The information needs to be compressed.
As technical people, we like to say, “It’s not that simple,” which is true. There are too many unknowns. But when we give too much information, we overwhelm the other person. Worse, if we don’t answer the implied question (“When is this thing going to be done?”), the other person will go somewhere else for answers.
In my experience, “somewhere else” tends to be bogus metrics and made-up dates. At two companies I worked for the gap between technical-speak and management-speak was so wide that the executives created an entire middle-management layer to figure out what was going on. There was a real opportunity for the technical people to work with the business decision-makers, solve problems, and make themselves the next generation of middle management . . . and we ended up talking about problems getting the XML to serialize to the RSS twinkilator.
“Speak in the language of the business” is more than a bit of a cliche, I know, and telling people that things will be done if you don’t know when seems like very bad advice. Here’s a simple, concrete idea: Leave a trail of breadcrumbs for management to figure out for themselves when things might be done.
For example: Collect data on how long things were supposed to take and how long they actually took, or how many builds/tests/fix cycles similar projects took. For our test tooling project, the communication is more like, “We split the work into stories and are knocking out about two per week. At that rate, we’ll be able to run the tool on a virtual machine by the end of the week, it’ll run overnight by the end of the next week, and it will start emailing reports the following week. Or would you like to change priorities?”
If possible, divide the work into very small chunks—what we’ll get done today versus tomorrow. A prediction for the next day is much more accurate than for the next three months, and being off by 100 percent for a one-day task is a much smaller deal than being off 100 percent on a three-month task.
Giving concrete answers will help everyone get on the same page. Figure out what management needs to know, then talk in their terms and provide them with information to make their own decisions.
