This post is the twenty-sixth part of a ramble-rant about the software business. The current posts in this series are:
This post is about how the business people and developers interact. It's also a T-SQL Tuesday post!
"You Want What?"
Sometimes business people don't know what they want. There's nothing wrong with this. In fact, it's more often true than not true and Agile methodologies are based on a recognition that not knowing the requirements when a project starts is normal.
Let Go That Ego!
Every recipe for disaster includes the line: Add 1 ego. Egos are great sources for metaproblems. Metaproblems are self-inflicted wounds and you can read more about them here and here. I described my toughest career challenge a couple years ago and I believe that's the first post that mentions the Crappy Job Test.
Egos are usually a symptom. They indicate fear. Fear of what? It could be anything, but most likely it's fear of what others think. I'll let you in on a little secret: Whether you care what others think or not, you can act as if you do not. If your actions are in accordance with the opinions of others, you are communicating that they can tell you what to do. If your actions are all self-directed, you communicate this. In other words, you tell others how to treat you. Insecure people will take advantage of you if you let them - it's what they do. Don't let them.
Egos just don't work well in our field. Or any field. Egos are the source of pride and pride is the root of all kinds of ugliness. Some folks believe I'm self-deprecating, and in some sense that's true. But in another sense it's not. At the risk of sounding preachy, I try to live by Romans 12:3. Sometimes that comes across as self-deprecating.
One Solution
One way to address personality clashes, collisions of style, and differences of opinions is to communicate. Most business people do not know everything they want when the project starts. One valuable skill database professionals (and software professionals) can cultivate is communication, and communication skills will help you here. Communication is really a two-phase commit that consists of the message-sender initiating commmunications and the message-reciever interpretting the message. What is actually communicated? The intepretation of the received message. Now that may be wildly different from the intended message from the sender.
A good story (or storyboard) can introduce the developer's vision to the business. User Experience tools (like SketchFlow) provide this capability, as does Visio - or even Paint or a cocktail napkin. The point isn't the tool used to communicate the interpretation of the message received; the point is to close the feedback loop by showing the business person how you interpretted the message!
Conclusion
Drive: The Surprising Truth About What Motivates Us is one of the best books I've read - period. It helped me with my business communication because it focuses on the things that motivate us, and that's actually behind what we're trying to communicate.
:{>