How Much Does My General Manager Need to Know About My Department?

Question from a reader:

Dear Dave,

How much does my general manager need to know about my department?  Frankly, he/she doesn’t seem that interested in what we’re doing or spend that much time with us — which I suppose is a good sign in some ways.  On one hand, I’d love to deep dive into all the great things we are doing.  On the other, I don’t want to bore him/her with a lot of unnecessary detail and be seen simply as yet-another engineering manager who doesn’t “get” the business.

The first answer to this question reminds of an 800-pound gorilla joke.  Q:  Where does an 800-pound gorilla sit?  A:  Wherever it wants to.

That is, your GM needs to know whatever he/she wants to know about your department.  So I’d listen closely about what he/she requests in terms of information and make sure you deliver that.  Don’t make the all-too-common mistake of not providing what is asked for, but offering lots of other information instead.  That’s like serving more icing than cake and, personally, I see it as either incompetence or a deliberate diversion.

Because (I happen to know that) your GM is not a functional expert in your department, he/she may not have a clear sense of what information is of interest.  So he/she may place the burden on you of figuring out what information is appropriate, say, for a 30-60 minute quarterly ops review presentation, or a 1-1 meeting.

In that situation, we can use some first principles to guestimate what the GM wants to see.  All good GMs care about:

• Sales, which is typically measured by ACV in a SaaS company.  Remember, this is the raison d’etre for the GM role — i.e., the reason the company has a unit GM is precisely because they want someone focused on and accountable for the unit’s sales.  Because sales is a trailing indicator, GMs are usually focused upstream on pipeline as a leading indicator of sales.

• Customer satisfaction as measured directly through surveys, anecdotally through escalations, and indirectly through renewals.

• The team.  Who are the top performers and how are we retaining them?  Who are the bottom performers and how we are improving their performance?  Who is in the middle and how we are developing them?

• Objectives and accountability for achieving them.  What objectives are you working towards, why were they chosen over alternatives, how do they tie to the unit and company goals, and how are you doing on achieving them?  Personally, I am a stickler presenting prior-period objectives in a verbatim form, because too many people try to hide the very normal tendency to miss some of them.  Far better, in my opinion, to reach a bit in setting objectives and miss a few than game the system so that you are always hitting 100%.

• Key departmental metrics.  I think every manager should have 5-7 topline metrics that they use consistently to measure the department over time.  Because they will be used over time as the company scales, it is often best to normalize these.  Cases/agent or cases/customer is more interesting over time than just the number of cases.  Bugs/customer or bugs/engineer is more interesting than total bugs outstanding.

So let’s try to apply the above to answering your question.

1. I’d sit down with the GM and determine what your topline metrics should be — this is often a long and interesting series of conversations.  This exercise is, in my experience, never as simple as it might appear.
2. I’d sit down with the GM and ensure you are aligned on quarterly objectives.  In a matrixed organization where you are reporting to both a product line GM and a functional vice president, this can be harder than meets the eye.
3. I’d think hard about how what your department does ties to sales.   While your functional boss will focus on about  best practices, your GM will — as noted — invariably focus on sales.  For development that might be about neutralizing competitive features.  For QA/QE, that might be producing a higher-quality product on faster cycles than the competition.  For UE, that might be studies reflect not only on how designs work with existing customers, but particularly on how prospective customers react on an first-impression basis.  For techdocs, that might be how can the documentation make the product sufficiently better so as to influence sales, perhaps by highlighting competitive strengths in examples and tutorials.
4. I’d think hard about how your department ties to customer satisfaction and renewals, using the same approach as above.
5. I’d provide a quarterly update on the team citing top/bottom performers, key hires and informally discussing team issues within the quarter.
6. Finally, I’d make a point to make myself “more than a department head” by spending as much time as possible learning the product / market / competition and talking live with customers, e.g., during corporate visits, user conferences / groups, et cetera.  This will facilitate all the prior points and help  you get ready for your next promotion!