Have you ever read the latest memo from top management and wondered, "What are they thinking? This will never work!" Sometimes we have information that management doesn't have. How we put that information in front of management can determine whether they hear us or not. Esther Derby gives some advice on communicating up the chain.
Imagine this scene-you've just gotten back from lunch and you're checking your email. The first email you open is from the VP:
Effective immediately, starting with the release currently under development, our flagship product, SalesSupport, will be converted to use a proprietary database in place of the current SQL DB . Deploying SalesSupport with our ClientMaster(SM) database will enable us to realize cross-marketing opportunities and increase revenue substantially.
As you read the email, you start to feel queasy. You realize that changing to this database means that the third-party contact management component you are using won't work. You'll either have to get the vendor to build a one-off that will access the ClientMaster(SM) database or modify the component in-house.
Good luck waiting for the vendor to make the new version. And, if you change the component in-house, it won't be a one-time job: every time the vendor comes out with a new version of the component, you'll have to customize that code, too. How could the VP make this decision? How could he be so dumb? You know this will cost money and customers. You hit the reply key and start to list all the reasons this is a really bad idea.
If you've ever been in this spot, you know that sometimes telling the big boss he's about to be an idiot works and sometimes it just gets your butt kicked. Communicating effectively up the chain requires some finesse.
Most likely, the managers in your company aren't stupid people. The decision may make sense from a perspective that you can't see right now. One day I came to work to read an edict that every project must provide evidence of compliance with a certain off-the-shelf methodology. Never mind that most of the department had no training in the methodology and didn't have access to documentation for it. Development managers were told they must comply or provide evidence explaining why their project should be exempted from the requirement. In terms of changing the way teams developed software or improved project performance, this was about the most nonsensical thing I had ever heard.
Then I learned that top managers in the company had made a strategic decision to enter a heavily regulated line of business. In order to receive approval to compete in this arena, the company had to pass an audit-an audit to establish that the development area adhered to a repeatable development process.
That bit of information explained the focus on compliance and producing documentation for exceptions. The goal of implementing a methodology wasn't to improve the quality of the software or the predictability of projects. As long as the methodology helped the company past the audit, it was a success.
If you can't imagine a scenario where the management decision would make sense, ask around. But, ask in a way that doesn't imply anyone is stupid. Questions such as "What's the intent behind the database decision? I'm puzzled about how the vendor upgrades will be handled," will work better than "Didn't they think about the upgrade path?"
You may be able to pass important information upstream. Hierarchy tends to act as a filter: Top management may not be in touch with all the detailed operational aspects of how employees actually move product out the door. If this is the case, you may have information that will help them make a better decision. Figuring out how to get information up the chain effectively requires savvy and planning.
Assess the Lay of the Land
Hold off on the reply button a bit longer and don't barge into the