At many companies decisions and prioritization tends to be done by committees, in fact Agile itself tends to be very committee driven (the team estimates together, the team determines how things will get done, etc…).

But the Product Owner (or Product Manager in traditional terms) is the key person who’s accountable for the results. They prioritize the projects and features, define desired outcomes, ensure profitability, and accept/reject results.

In the real world many people may have a stake in projects as they are either sponsoring the project, supporting the project, or are affected by the project. So as a Product Owner you will have to interface with stakeholders and sponsors to get their feedback, issues, goals, etc…

Likewise, a Project Manager/ScrumMaster might encounter similar situations where they are trying to garner consensus and agreement.

The problem however is that large committees rarely are capable of making decisions.

[box] Once you’ve got 7 people in a decision-making group, each additional member reduces decision effectiveness by 10%, according to Marcia W. Blenko, Michael C. Mankins, and Paul Rogers, authors of Decide & Deliver: 5 Steps to Breakthrough Performance in Your Organization. Thus, a group of 17 or more rarely makes any decisions.[/box]

Tips:

• Hold a series of smaller sessions (e.g. instead of one 10 person meeting, have two separate 5 person meetings).
• Pre-meet in advance with individuals to gather their feedback, stance, concerns, requirements to that you can factor that in and further prepare for the main meeting.
• Instead of starting with a blank slate and trying to work with the committee to collaborative decide/plan/prioritize/etc… gather initial data and create a good starting point – e.g. a draft plan, and then let people argue/discuss over it.
• Always make sure your management supports where you want to go so that they back you up behind the scenes.

Have you ever cleared your inbox down to zero? It’s the elusive dream we all hope to one day achieve.

One of the challenges we face in this information overloaded work culture of ours is that the sheer volume of information requires constant grooming, categorization, and prioritization.

Consider that your manager is probably getting about 5X-10X more email than you as they’re cc’d on every discussion, decision, and meeting minutes pertaining to the team. Consider that his/her manager is yet another order of magnitude as the scope broadens, and continues to get worse as you go up each management level.

At the executive level you’re going to employ techniques that help you stay on top of what’s going on with the business by prioritizing where your time needs to be spent. Which means they’re going to assess within 2-5 seconds how important an email is and either act on it right away, read and absorb in detail, delete it as non-actionable, or file away for further reading (which they’ll never get around to).

We live in the detail

The problem with people in the technical industry (developers, analysts, project managers), is that our lives revolve around detail. Detailed plans, specifications, unit tests, coding standards, acceptance criteria, etc… it’s all low level detail – and thus our brains are optimized to think at that level.

Executives however operate at a higher, broader, bigger picture perspective. They swoop down to lower level gears when they need to roll up their sleeves, but for the most part they’re focused on where the business is headed.

Follow these tips

Thus the style of communication that works for people who work with low level detail isn’t optimal for executives, so here are some tips to maximize your communication delivery and impact with executives:

• Don’t use narratives

I had always felt that the application could run faster, so I was looking into server performance and by running a number of queries through query analyzer I determined that performance could benefit by adding a number of indices (see initial results below). So I took it upon myself to add a number of non-clustered compound indices that my research has shown to be used in the commonly used join statement, and…

• Narratives are that story telling style of explaining things, where you end up with paragraph after paragraph only to get to the point at the very end.
• They’re time consuming to produce because you’re going to be meticulous considering the audience, and even worse they’ll just quickly scan through it.
• Or if they do want to read the detail, they’ll put it in the read-later category when they have more time, which they rarely do have more time.

• Strategically title your subject
• Don’t use one or two word subject titles, e.g. “performance”. It’s too generic, and not actionable.
• The goal is to try engaging them into reading your email.
• If you have good news, or are trying to pitch an idea that can really help the company – then try to pitch that in the subject line. Many execs deal with a lot of issues, so it’s nice to have an email come in that won’t cause your blood pressure to rise if you read it.
• Tag your subject with the content type, e.g. [idea], [kudos], [proposal], etc…
• E.g.
• [idea] quick solutions to improve application performance
• [proposal] side project to improve performance
• [kudos] Jeff Wilkers landed the Amcom account

• Start with your conclusion/proposal/point first
• The technical/analyst/PM thing to do is build up a case leading to a conclusion. Stating observations, criteria, supporting data, assumptions, etc… Execs don’t have time for this. Get to the point, first.
• Make the rest of your email support that point.
• This opening statement has to be very brief! No more than two sentences. It has to capture the essence, and be written in such a way that it can be absorbed at a glance.

Good news, we’re able to improve application performance by 30%.