December’s T-SQL Tuesday is brought to us by Steve Jones (Blog|Twitter). His announcement is titled “What the Business Says Is Not What the Business Wants” and he asks the question “What issues have you had in interacting with the business to get your job done?” On first reading Steve’s announcement, I didn’t get it. What does he mean by “the business”? I read it a second time more carefully and it began sinking in. By “the business” he means the person who causes developers to do things in ways that don’t make sense to them. The person who causes DBAs to do things that seem unnecessary. This is the person that Steve is referring to when he says “the business.”
In other words, me. Yes, me.
At my company, I am “the business.” My title is Vice President, and I have what is broadly termed as “business” responsibilities. So it’s quite possible that developers say “My way is better, but I had to do it this way because Noel said so.” Or that admins say “This is a waste of time, but I have to do it because Noel said so.” Of course, I’ve never told anyone to do something “because I say so.” However, that can still be the feeling when all is said and done, even though I try to minimize the chance of anyone feeling that way. There’s a lot more to be said here, and I’ll come back to it later.
Now, Steve’s announcement says “”What the Business Says Is Not What the Business Wants.” As I just stated above, I am “the business.” Well, I want a pony. Or do I? Let’s save that for the end of this post. Before getting to that, I’ll tell my funny “business” story, share a little advice that’s helped me in these “what the business wants” situations, and return to the “because I say so” misunderstandings.
The Error Message
With this post, I didn’t want to give any specific stories, but this one happened a long time ago, and I won’t use actual names or anything else that could be identifying in nature. It’s meant to be told in a fun spirit, plus it fits the topic of issues encountered in business-to-technical communication.
I encountered an error message in a company’s internal application that caused me to laugh. With a little asking-around, it appeared that the error message was well-known, laughed at, and tolerated. Still, I had to go to the developers who created the error message and find out why they wrote it in such a funny way. The developers were still employed at the company, but the business analyst was not. So I only got one side of the story, and it goes like this…
A business analyst, let’s call him John Smith, went to the developers and asked for an error message to be printed to the application log when a certain event happened. So the developers obliged and the following message was generated the first time this event occurred.
ERROR CODE 0x123 ON LINE 100
Upon finding out that this was the message produced, John Smith went to the developers and told them that this wasn’t enough information. When seeing this message, the computer operators didn’t know what to do in response to the error message. According to John Smith, the computer operators should have called him and informed him of this error. So the developers modified the error message according to the specifications that they heard. The new error message became the following.
ERROR CODE 0x123 ON LINE 100. CALL JOHN SMITH
This message “worked” because when it showed up in the application log, the computer operators called John Smith. Of course, this isn’t what John Smith had in mind. I would imagine he foresaw a day when he’d be promoted to management and no longer be the lowly business analyst who deals with error messages. So with a frustrated disposition, he told the developers something to the effect of “I didn’t mean for you to put my name there!” With this, the error message morphed into it’s third and final form.
ERROR CODE 0x123 ON LINE 100. CALL BUSINESS GUY
It shouldn’t come as a surprise that John Smith didn’t go back to developers with a fourth attempt at getting this error message in proper form. While I couldn’t verify the reason, I imagine he just gave up on trying to communicate his idea of what the message should be. To the developers, on the other hand, this message was properly implemented because they did not receive any further complaints. When I suggested modifying it, they became quite upset with me because, in their minds, I was asking them to break something that works.
The Worst Vice is Advice
This is just an approach that has worked for me when the circumstances are right. I’m sure it’s hardly original, but thought I’d mention it anyway. Either way, take this with the same warnings that we all give regarding not blindly using source code without testing it, etc. I say this because it’s something that isn’t always appropriate or allowed, so don’t try it because I’ve mentioned it here. I was leaning towards eliminating this section, but decided to leave it in with a speckling of warnings.
Sometimes, you have the feeling that “the business” is going to change their mind once they experience the implementation of their specifications. You’ve argued with them about this, tried to let them know that they really don’t want this, all to no avail. It’s at times like this that I often look to configuration parameters. Broadly put, I consider implementing what they say they want, as well as what I think they want, with the ability to choose between the two using, for example, a parameter in an application configuration file.
You can’t always do this. Some industries or audit conditions might not allow such a tactic. Sometimes you might not be able to devise a way to do this without over-complicating the solution, increasing project cost to a prohibitive level, increasing some form of risk, etc. So please, don’t do this just because I suggested it.
And if you are able to use this approach, then use it with kindness and a polite attitude. If done right, it’s an opportunity to display your professionalism. If “the business” says they were wrong, and asks you to modify a solution to what you thought they wanted, then don’t gloat. Don’t say anything to the effect of “Yeah, your idea was really stupid, so I also implemented my idea, I just have to flip a switch to turn it on.” Likewise don’t tell them it’s going to be a new project that will take weeks to implement, if in fact all you have to do is 2 minutes of work to change a configuration file. Yet, also consider whether this alternative configuration was properly tested… perhaps it’s not 2 minutes of work after all.
How often have I done this? Not a lot, but where it has really helped is with specifications for application logging. Sometimes you realize that what is requested could result in megabytes worth of log messages generated per hour, and “the business” doesn’t really want that. In such a situation, you can utilize tools like log4net to specify log levels that can be set in configuration files to control the volume of application logging.
Business To Technical Communication
It’s time to come back around to the “because I say so” communication issue from earlier in this post. Steve’s announcement described a situation where a technical person implemented a solution because “the business” said it had to be done their way. Steve characterized this particular case as impedance mismatch. I would not be surprised if most business-to-technical communication issues fall under that umbrella. However, I’m going to, modestly if I may, suggest that I might be immune to this cause. Here’s why I would suggest this.
On the technology side, I’ve been involved with developing solutions since the late 1980s. I have a degree in computer science (primary area in database systems, secondary areas in software engineering and networks). I’ve worked in development and production DBA roles. I’ve designed and/or implemented a good chunk of the current solutions at my current company. If I interact with a developer or an admin, it’s rare that I’m not familiar with the component in question.
On the business side, I have degrees in finance and economics. I’ve worked as a financial analyst and taught economics at a university. In addition to my day job, I’m a co-owner of a management consulting business. This firm also provides business intermediary and related services, which is why I’m registered with my state’s Securities Division.
So if we could imagine, at least for the purposes of argument, that I speak the languages of both business and technology, then impedance mismatch could be ruled out as a factor. If I was strong-arming people into doing something, that would explain feelings of “because I say so.” However, let’s give me some credit and assume that’s not the case. Then what could be responsible for leaving a developer or admin feeling that “the business” wanted things done in a way that they don’t agree is best, or, say (hint, hint), optimal?
Is it possible that, yes, there’s a mismatch, but it’s at the level of what type of optimization is being considered. In other words, this might be a case of global optimum versus local optimum. The developer or admin is considering the optimal way to implement a solution or task. On the other hand, I am probably juggling a few other items in the midst of this decision. Let’s see if we broadly break those items into three groups:
- Items I can explain to the developer or admin, and they appreciate their impact and understand the decision. No communication problem has to occur here.
- Items I can explain to them, but the developer or admin doesn’t appreciate why such items are a factor. This causes a disconnect, thus we have a communication issue here. Things that fall in here include office politics and user complaints… they might seem petty to a developer or admin, but these two things can make or break my ability to do my job effectively.
- Items I can not explain to them. So we have a communication issue here as well. Naturally, I can’t provide examples here, but these items might involve issues that are confidential due to relationships with outside parties, regulations, business policy, etc.
Item 1 shouldn’t be an issue if I’ve done my job properly. I (we) have known managers who won’t share information that they could, because they enjoy the power trip or whatever (no need to expand on this unfortunate characteristic). Item 2 might be manageable, or perhaps it’s also a form of impedance mismatch, but either way it happens and you have to deal with it as best you can. Item 3 is something a manager hopes doesn’t happen too often, because there’s an information problem that’s preventing the developer or admin from knowing the global optimum (at least at the point in time when decisions are being made). It’s situations like this that I hope I have a good ongoing relationship with the developer or admin, because I might have to rely on saying “please just trust me on this one.”
My Little Pony
In the introduction, I said that I want a pony. But as the picture to the right clearly shows, I already have one. However, when I said “pony” you probably didn’t imagine a tiny plastic pony. Also, that’s not even a plastic pony, it’s a plastic horse. As you can see, I’m able to create communication issues with even the simplest of things!
So if I don’t want a pony, then what is it that I do want that’s relevant to this blog post? Well, I enjoy interacting with developers and administrators, and I don’t want them to avoid conversations with me. I want them to bounce ideas off me. I want them to share something cool that they just learned with me. I don’t mind if they correct me in front of other people in a meeting, and I want them to feel free to do so. I want them to challenge me if my first reactions are counter to their ideas, and I hope that I encourage this behavior. This is necessary to my company’s success, because I’m not always going to have the best idea on how to implement a solution, an administrator might have come up with a cost-saving plan, etc. Fortunately, 90% or more of the time, these interactions are easy and pleasant, at least from what I can tell.
However, when a developer or admin and I have differing ideas, and my idea is the one that we go with, I play that experience over in my head… sometimes for weeks. I want to make sure, at least as much as possible, that nothing I did or said left the other person with negative feelings. I try to learn from it. Not just to learn what I could have done differently, but also to learn about the other person, their characteristics, and what I can do to better express ideas with them. Because I hope we go toe-to-toe on another issue someday, and (silently, in my mind) I’ll be cheering for them.
I might be “the business” now, but I’m still a hard-core geek. I hope to someday return to focusing on development or DBA work. Yet even with this, I’m still party to these mismatch issues in communication.