How to correct a CEO's misunderstanding of a project?

Question

A recent StackExchange podcast is a perfect illustration of a common problem.

Senior management is aware of a project or department several layers removed. Management may disagree with the value of the project or misunderstand some key details, which may trigger the former, but regardless have a negative attitude towards the project. Additionally, given the demands of senior management it is difficult to sit down for a significant amount of time to really review the project.

However, when this misunderstanding and/or followup lack of interest gets translated down to those working on the project or in the department, it tends to significantly hurt motivation and morale because they realize the senior management ultimately think their project is a waste of time and/or resources.

• How can I, as an individual contributor, change a negative perspective held by senior management for my project/department?

Answer 1

You should not underestimate the role of active individual contributors.

It is true that plainly raising a voice through several layers of management is difficult, but if you take into account that contributor can influence the project, the impact made on a project level can be much more noticeable than simple "screams from beneath".

In one of my past projects, things went exactly this way. Top management decided to freeze it (and by the way they had pretty good reasons for that). But while they were messing and fussing arranging the cumbersome administrative turns to finalize the project, several programmers were just having fun fixing bugs accumulated in a large backlog.

I think it also didn't hurt that we had quite a talented tech lead who managed to regularly spread the information about our progress "up the ladder": this week: 10 bugs fixed (total amount of fixes 50), next week: 15 bugs fixed (total amount 65) - and so on and so on, week by week, month by month.

After amount of fixes went well over 100, upper management decided to just make a "last" update release, "just to please customers before saying them final good bye". Update release was met with a lot of enthusiasm from clients and management decided to postpone the freeze and try yet another update release... long story short, a year later nobody was even talking about freeze and project went fairly well for a several years after that.

As a closer example, the very podcast example you refer to shows that small misconceptions at top level are not necessarily critically damaging. Think about it, as long as the Workplace has an active community of regular contributors, sharing a set of successful, productive values and working together on keeping the site up to these values, could it really matter much if someone else, no matter how high up the ladder, has somewhat different opinion.

I'd venture a guess that as long as it doesn't translate into a serious concern, it remains just that - an opinion - maybe interesting, maybe worth discussing, but not worth making a big deal of it.

---

On a more general note, at one of the soft skills training I've been told that for hierarchical organization to work reliably in a software related industry, it would better be designed to support information transfer over at least one level of management, ie ensuring that manager routinely communicates directly to subordinates of their subordinates. This ensures that important knowledge doesn't get stuck at particular level of management.

^{They also explained that such hopping over the levels is assumed only for communication - that is, if you're the boss, you still don't tell a subordinate of your subordinate what to do. Instead, you just learn how to more effectively manage your "direct reports", who in turn pass that further down the ladder.}

An interesting, although maybe a bit extreme example of this approach has been outlined in an interview of Eric Schmidt to Harvard Business Review about his venture as CEO at Novell:

...you can’t just look at an org chart to find your most important employees. The key people here are our most creative engineers - they’re the smart people, the ones who control our future - and they can be very well hidden in the organization. They’re not necessarily at the top of any hierarchy.

I used a kind of algorithm to locate these people. A few days after I started, I was on the company shuttle from San Jose to Provo, where our engineering staff is centered, and I was sitting knee-to-knee with two engineers embroiled in a fascinating, heated argument. They were obviously two extremely bright people. I asked them to give me the names of the smartest people they knew in the company. They gave me a list, and over the next week I set up half-hour meetings with all of those other smart people, and I asked each of them to give me the names of the ten smartest people they knew. Because the smart people in an organization tend to know one another, I eventually found out who they were—about 100 in all.

I met and talked with each of them. It helped that, as an engineer myself, I understood their intellectual and technological needs and what their concerns were. I listened intently while they told me about their experiences and their frustrations...

Answer 2

You can't influence management significantly higher than you.

But you can be a part of the solution. You need to get your immediate manager to use their influence to get the positive message back up the chain. That message might be updated information and status, or a demonstration of how how it will generate revenue or reduce expenses.

You and your manager will need to discover where the disconnect is; and then determine how it can be overcome. It may be an iterative process because there might be multiple reasons.

Motivation of the team is important, but the bigger concern is that the misunderstanding can lead to starving the project of resources, or termination of the project. The lack of encouragement can also lead to decreased performance and the inevitable termination of the project.

You need your immediate mangers to be a champion of the project. They need to provide adequate resources, and they need to ensure that their managers understand the importance of the project, and keep them informed of the status of the project.

Answer 3

I'd say, don't focus on the top, focus on your area of influence.

It will be hard, particularly when there are several layers of gap between you and the Sr. Management for you, yourself, to change that particular individual's perception. Even the management chain may not accomplish it.

Instead, I'd focus on being the voice for the project on the level at which you are already operating - the people you work with. The team (hopefully) thinks the project is cool and useful. So they are already on your side. But what about the next team over? Those guys you eat lunch with but don't share work with? The people you collaborate with to get major portions done? The people who provide you with necessary tools and services?

What do those folks think of the project? Do they see the reason that it's cool? Can you explain it to them - in their terms.

A big thing here is being able to explain a project to a listener in the terms that the listener themselves can understand. Even if everyone in the audience is technical, just because everyone knows a lot about computers or networks doesn't mean they understand the world or the business in the same way. Don't explain or monologue, have a real chat with some of these folks - hear where they are coming from and explain why you are excited about the work that you do.

It may or may not help - but if you can get through to people, you'll generate a positive buzz. Somewhere in here are a few people who probably do have the ear of upper management. If the next conversation with upper management about your project is "I don't know much about it, but everyone seems excited about it" - then you have started to turn the tide.