© 2004 Esther Derby
This column originally appeared on Stickyminds.com
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 data base 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 some times it just gets your butt kicked.
Communicating effectively up the chain requires some finesse:
Suspend Judgment
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 of-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 improving 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 or 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?”
Perhaps you aren’t the one missing some information. Perhaps management is missing some information. Hierarchy tends to act as a filter: often at the top of the company, managers are making decisions based on financial statements and cost benefit analysis (CBA). 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 some savvy and some planning.
Assess the Lay of the Land
Hold off on the reply button a bit longer and don’t barge into the VPs office just yet. Look around your organization to see how information flows up. Can the newest programmer sit down and talk to the VP of development? Does communication follow the org chart? If you’re not sure, watch for a while. What happens to people who bring up problems to their bosses boss? Do they get a fair hearing without retribution? Or are they sidelined forever?
If your organization communicates only along the chain of command, work the chain. If you hit a brick wall at the first level, you need to decide how important it is to you to push the issue further. Is it worth having your boss chew you out? Is it worth loosing your job? I’m not saying those responses right, and it is the reality in some organizations. Look around and decide how much it’s worth to you.
Some organizations are different in different areas. I worked in one company where it was ok to skip levels in the development organization, but not in the test organization. The key managers in the test organization were ex-military. In the test organization, issues went step-by-step up the chain of command or they didn’t go at all.
Speak the Same Language
State your position in a way that maps to management concerns and in language they’ll understand - which usually means money. Going technical on a manager who has never worked in the technology arena will cause his eyes to glaze over.
First, identify one-time costs like development, testing, additional hardware or infrastructure, documentation, conversions, and rollout. Then list on-going costs: continued maintenance and support, modification of new versions, licensing agreements, and so forth. Don’t forget customer-related costs and consequences.
Do Your Homework
Don’t just walk in and say “Hey, this will cost a lot.” A complete cost analysis isn’t necessary, some level of factual information is. If you aren’t fluent in budgets and capital expenditures, find someone who is knowledgeable to coach you. If your manger is supportive of your efforts, she can help you with fully burdened development costs, equipment costs, or license costs for the product you work on. And I have found that the folks in accounting are often quite happy to explain how budgets work.
Sum up your findings in financial terms and lay out customer consequences.
Persist, within Reason
If the manager you approach doesn’t take you seriously, ask “What information would you need to see to reconsider this issue,” or “Who would you trust to tell you that this is an important issue?”
If the manager tells answers positively, dig up the information and interview the people he mentioned. This can be a lot of work - but it show that you take the issue seriously; you’re not just a whiner.
If he answers that nothing will convince him to reconsider or there is no one he’d listen to, be willing to drop it.
Take a little trouble preparing how communicate up the chain. It may take a little while, but if you do it right, you’ll look like a leader and you may save the company a serious misstep. When the SalesSupport team showed the VP that it would cost $2 million to migrate existing customers to the ClientMaster(SM) database, he changed his mind.