Chris Heisel

Understanding roles is a perennial issue, but especially as a company scales and small-group communication breaks down it becomes more and more of an issue….

• Responsible. The people who do the actual work.
• Accountable. The one person on the hook. ‘The Decider’ as Bush II puts it.
• Consulted. Opinion contributors.
• Informed. One way updates.

(Via. RACI — Just about anything)

First off, I love the RACI pnemonic and I’ve used it for years with my teams. In my experience mentoring new leaders there are couple of things to watch out specific to RACI:

1. Make sure the person you’re making Accountable understands that it isn’t automatically assumed they’re Responsible as well. A lot of new leaders take on the assignment and don’t enlist their team for help performing the work.
2. Ask them to think thoroughly about whom should be Consulted. Enthusiasm for a new assignment can lead them to run off with their team leave out some key stakeholder. Ask them up front who needs to be Consulted and provide some guidance based on your knowledge of the organization if they’re far afield.

I’ve been looking for a way to up my and my team’s game as competitive pressures, deadlines and customer demand increases. 

OKRs got their start and Intel and made their leap to Google, LinkedIn and other valley companies. In a nutshell: An OKR is a qualitative objective that’s inspirational and some challenging quantitative key results that measure your progress against that objective.

It’s a simple concept, but there’s a lot of nuance to make it something that drives your team forward. Otherwise it’s just another way of doing MBOs.

Here’s my highlights thus far:

• Objectives should be qualitative and inspirational, time bound (a quarter, a year, etc.), and can be achieved independently by the team.
• Key results quantify the inspirational language, they are measurable
• Key results should be hard — the sweet spot is when the team is 50% confident they can achieve it. More confident and you are not driving growth, less confident and your team will give up.
• Key results should be something that happened because of what you did, not what you did. Good: Customer satisfaction score increases by 10% vs. Bad: Meet with customers, devise features that will please them, implement them.
• OKRs should result in failure — If the team is achieving all the key results then they were set too low. Most companies and teams are extremely failure averse. If you adopt OKRs, you have to set the stage culturally with the team and with your management above you that you are going to try hard things and miss. 
• OKRs are not a performance review. The quickest way to keep people from aiming high is to punish them for missing.
• OKRs shouldn’t change during the Objective’s time box. OKRs should help focus the team.
• Start small: One OKR per company with supporting OKRs per team
• “OKRs are not the only thing you do, they are the one thing you must do.  Expect people to keep the ship running.”
• OKRs at every level should be available publicly.

Here’s some sources to learn more about OKRs

How Larry Page Changed Meetings At Google After Taking Over Last Spring

Every meeting must have one clear decision maker. If there’s no decision maker — or no decision to be made — the meeting shouldn’t happen.

No more than 10 people should attend.

Every person should give input, otherwise they shouldn’t be there.

No decision should ever wait for a meeting. If a meeting absolutely has to happen before a decision should be made, then the meeting should be scheduled immediately.

I really like these guidelines, and I’m tempted to adopt them whole cloth with my team.

My team meeting agenda is mostly updates on what’s happening within the teams and within the larger organization. There’s a lot of value in seeing someone’s reaction to news and having a chance to answer questions and stop misinterpretations before they start in a setting like that.

On weeks when we haven’t been able to meet, I’ve often sent out my notes of news from the organization I wanted to share. Inevitably the next week I take a few minutes to breeze through it and uncover that someone didn’t understand or made a faulty assumption about what I wrote.

(Via. Business Insider)

Refactoring organizations to increase your impact: “So we changed the meetings to focus on proposals instead of problems. Stating and identifying problems is fine, and sometimes it’s all we can do when the solution eludes us. But proposals are the heavy artillery in meetings. They force us to focus on possibilities, and they force us to do our homework and weigh the alternatives.”

Things I love about this post:

• Proposals as the management equivalent of “pull requests” or “patches welcome”
• It’s a more sophisticated version of the old management trope “Bring me solutions, not problems”
• It’s another post about management from folks in the technology industry, something I wish there was more of

One of the most insightful and challenging things my boss has ever told me was: Communication is what the listener does

Think about the ramifications of that statement:

• Another developer didn’t understand your architecture proposal – It’s on you
• No one bothered to reply to your code review – It’s on you
• You try to convince your team that a new library will make your jobs easier – It’s on you

Successful communication is all up to you.

Here’s the basic communications diagram they teach every journalism student, ever:

With the responsibility of successful communication squarely on the the stick figure to the left, what might she do to make sure the listener does what she was hoping for?

1. Tailor the message to suit the listener. How do they like to be communicated to? The sky’s the limit when it comes to their preferences: in person, via text, audio, slidedeck, interactive game, with data, grounded in values, all of the above, and more.
2. Account for interference. It can be technical interference like a bad video connection or too much background noise on a conference call. It could be on you.  Maybe you get really defensive about this subject so that gets bundled in along with your message. It could be on the listener’s end. They might not be in a good mood because of something at home, with a friend, or their pet.
3. Pay attention to feedback. Is the person tuning out? Are they on the edge of their seat? Are they telling you they understand what you’re trying to say, but they don’t agree and “here’s why.”
4. Remember that feedback comes with its own interference. Pay special attention to the interference you bring to the feedback. Maybe you don’t like to be interrupted but the listener is doing it anyway, that doesn’t make their feedback any less valid. Maybe you were so excited about your idea, you weren’t at the point yet where you could take any feedback. That doesn’t make the feedback any less valid either!

How many of us when confronted with an unsuccessful communication attempt, fall into one of these or other mental traps:

• My idea was so good, they’re clearly not smart enough to understand it
• I told them this was a problem, they didn’t listen, so it’s on them
• I spent 4 hours diagramming the whole thing, why couldn’t they follow my instructions!
• It’s patently obvious why this is a good idea, why won’t my boss approve it!

If you do, and you don’t remember that communication is what the listener does, then don’t be surprised if you’re continually unhappy with the results.