Links and Posts: 4/1/19

Don’t solve the problem. — Signal v. Noise

Don't solve the problem.

What makes a great manager isn't the problems they solve, but the questions they ask. Start with these 16 questions…

m.signalvnoise.com

An employee comes to you and says, “I have a problem.” If you’re trying to be a great manager, what do you do?
Your initial instinct might be to roll up your sleeves. “Time to be the boss,” you think to yourself. You’re ready to step in, solve the problem and save the day.
Or something like that. You just want to be helpful.
In reality, your instinct is theoppositeof helpful. Startlingly, when you jump in to solve a problem as a manager, it’s one of the biggest leadership mistakes you can make.

Yes. This is the hard part. Everything that got us where we are is probably the opposite of this. We likely were the ones that hopped in to solve problems. So it’s quite difficult to completely pivot your responsibilities. Now your job is to provide guard rails of enablement.
One of the most difficult things about management is having enough information on what’s going on. You are expected to present to other stakeholders what your team(s) are doing and where they are going. That can be difficult in an environment that pushes autonomy. But these questions are great ways to get to that info, without coming across as untrustworthy. Also, be honest about why you’re asking these questions. It’s not about a lack of trust. It’s about you needing to understand enough to help provide guardrails when necessary and let them find the answer with soft touch guidance, but even more to help align stakeholders.

OKRs aren’t going to fix your communication issues — Craig Kerstiens

OKRs aren't going to fix your communication issues - Craig Kerstiens

Talking with a startup a few days ago they asked for my opinions on OKRs. I have slightly mixed opinions on them…

www.craigkerstiens.com

Talking with a startup a few days ago they asked for my opinions on OKRs. I have slightly mixed opinions on them overall and started to disclose some of those. Though in sharing some of this I had a few immediate realizations that might be broadly applicable. The crux of his question was, at what stage should we put them in place. I’ve seen a few companies try to put in some form of OKR, and most were met with pretty mixed results. The reason is that OKRs need to change something about your behavior otherwise why put them in place… either change something about the goals you would otherwise have or the methods at which you went about achieving them.
Stepping back a bit, my first question and a very focusing question on almost any situation to ask is “What problem are we trying to solve?” In our conversation he actually paused a bit. As he paused a bit longer it was clear that question had not been fully asked or answered.
The first and most common case I see with startups trying to put in place OKRs, v2moms, management by objectives is that the team is not aligned and focused on the same goals. But my follow-on question is consistently, have you communicated what you decided you goals were.

I like OKRs but this does a good job explaining some of the shortcomings. OKRs are not a solve all solution (nothing is). But even more, like metrics in general, OKRs can cause an over-focus on the signal. Chasing the numbers while losing the meaning. They also won’t solve structural issues in your organization. They are a potential piece of the puzzle but you should use caution as much like agile, you can forget what the point of this is.
I also think it’s a mistake to use these at a micro level. OKRs are about helping coordinate across an organization. They for sure don’t need to be done at the individual level, nor potentially even team level. Thus, if you are small and don’t have big communication issues than OKRs might not need to be much more than the company level and department. And even then if you’re still in discovery phase you’ll want to be careful that you haven’t locked yourself in on assumptions. A young company should overvalue agility.