High-Output Management for Remote Teams and Companies Part II
High-Output Management for Remote Teams and Companies Part II
In the first installment of this two-part series, we looked at the characteristics of high-performance remote teams. We discussed the key methods I use to ensure my teams are in the best possible position to perform at the highest level.
I explained my process for setting quarterly goals, communicating those goals to the entire organization, and how every level of the company has OKRs that tie into the larger objectives. I also shared my thoughts on check-points and how we use OKRs and check-ins to stay on track and identify any problems as early as possible.
High-Output Management for Remote Teams and Companies Part II
In this second installment, we’ll dive into the finer points of decision-making for leaders, and I’ll be sharing how we use these principles at Turing.
Next, we’ll talk about feedback, and how honest, transparent, and immediate feedback facilitates speed and continuous improvement. Finally, I’ll give you my blueprint for establishing a high-performance organization.
The secret to making fast, but high-quality decisions
I can’t emphasize enough how critical it is to have the right decision-making structure for your company. One attribute of a high-performance company is that the team makes fast decisions that are also correct.
Reversible vs. Irreversible decisions
From my perspective, there are two kinds of decisions companies make; reversible decisions or irreversible decisions. Ninety-nine percent of the decisions a company makes are reversible. Only a very few, who you raise money from, who you choose as a co-founder, are irreversible.
Typically, the best approach for a company is that anybody except the CEO should make reversible decisions. If it’s an irreversible decision, the CEO makes the decision. In both cases, high-performance companies make high-quality decisions fast.
How not to suck at decision-making
Generally, there are three ways companies can operate when it comes to making critical choices.
One way they can operate is purely top-down. For example, somebody with authority just says, hey, do this, and everybody does what they’re told. The benefit of this approach is that it’s swift.
The negative is that you don’t have enough buy-in from everybody on implementation and people don’t feel heard. Frequently, valuable insights from others in the team don’t get incorporated into the decision. So that’s not ideal.
Have one decision-maker but consult key stakeholders
A much better approach is to have one decision-maker who consults with key stakeholders. These are people with insights and perspectives relevant to the problem. Often, there is a very high-quality decision made when all the right people are sharing their inputs.
But you will want to maintain one arbiter who weighs all the inputs and makes the call. This approach has the benefit of factoring in everyone’s expertise, and it increases the likelihood that everyone feels heard.
Product design decisions
At Turing, for some of our product design decisions, the approach I follow is the same pattern described above. Having one decision-maker — someone who is a key stakeholder. All stakeholders are consulted, then we have the decision-maker also be the person who’s responsible for implementation.
How frustrated have you been when somebody else makes the decision, but you are the person that ends up accountable for implementation? That’s not great. I believe it’s always good to have the decision-maker be the implementer and the person who owns the metrics associated with the decision.
Decide who decides
So for our product design reviews, we use the following process.
A decision owner (could be someone from the Product team or Engineering team) reviews the design for a new feature, takes inputs from key stakeholders, and then decides. This person also owns the success metrics for that feature.
The decision can be a) good to move to implementation, b) identifies a few changes that need to be made before it moves to implementation c) decides it’s a no-go.
Once the decision is made, the decision-maker identifies the next step. E.g., “ship to staging by Feb 10th.” We track what was decided, share it with the team, and move to implementation. The decision-maker is the DRI (Directly Responsible Individual) for implementation.
You can do much of this asynchronously. At Turing, we’re using Google Docs, so our designer, Alejo, leaves the Photoshop designs in the Google Doc so the people involved can leave comments on the doc, and everybody signs off.
The beauty of this process is that it allows you to use meeting time to go over anything that is genuinely contentious or something that needs further hashing out.
Reserve synchronous meetings for resolving blockers
Synchronous meetings are used more for resolving any bottlenecks, conflicts, or anything that needs further discussion while doing the simpler stuff asynchronously. But one of the most important things is having that separation between a decision-maker and team members that provide input.
Too often, companies err by having a decision-maker but no group of people to be consulted.
So then things get into the product, and there is not enough buy-in. Afterward, people sort of complain about the decision behind each other’s backs — or follow-through is lackluster on implementation and support.
Making decisions made by a committee is another mistake companies make.
Everybody will try to get on the same page and reach a consensus. The problem is that getting to an agreement can be very costly for a startup because you can lose so much time. Purely democratic decision-making does not work for fast-moving technology companies.
That’s why I call my approach a reversible decision — because 99% of all company decisions are reversible. Keep in mind that you should be making a lot of reversible decisions knowing full well that some of them will fail, and you can always internalize the learning and move forward.
Embrace feedback loops for continuous improvement
High-performance organizations have a strong culture of feedback and continuous improvement. Ideally, once a month, you must take some time to internalize areas for improvement to go faster.
At Turing, for example, I have a document that’s solely focused on the next improvements.
I call the document the “Next Improvements Diagnosis.” What I try to capture are all the negative things that can happen within my company. A trial can fail, or a developer can fail a customer’s interview. Or, for some reason, collaboration breaks down.
What we do is track every single case of any fail happening. Then we try to understand why this error occurred? How could we have detected the problem earlier, and how can we prevent it from happening next time?
Instill a culture that learns from failure
One of the hardest things to do in a startup is to have a culture that learns and improves from failures without falling into the blame game or feeling too negative about it.
When I see these things breaking down, this may seem odd, but I have a big smile inside me because the most challenging part of building a high-growth company is if you can’t find the headroom to go faster.
I love when we find big, meaty problems because solving them means unlocking a lot more growth and business value. (Rubbing hands together with glee.)
It’s also helpful to keep the team focused on the positive outcomes of some of these adverse situations to learn from them and get stronger.
Do you analyze your lessons?
Too often, non-high-performing cultures fall into the trap where people are saying, “It’s not my fault; it’s that person’s fault.” Failing to analyze lessons from failures and therefore never improving is even worse.
If you are still on the first level — you’re not even tracking all these failures; you’re only showing things going up and to the right.
Track failures to get better more quickly
But I want to track every single failure where we didn’t deliver on our promise to a developer or a commitment to a customer and use this data to keep getting better continuously. High-performance cultures share a common attribute of continuous improvement and constantly leveling up.
How to build a high-performance organization – a simple blueprint
How do you distill everything I’ve written into a simple blueprint that makes it simpler for your team and your company to perform to your utmost?
It’s simple but not easy. Here’s your cheat sheet:
- Make sure everyone understands what high-performance looks like. Remember, high-performance teams, establish clear goals, write them down, share them widely and then meet or exceed them.
- Leadership at the team and the company level should establish the next set of objectives, makes sure that everyone in the company understands what we’re doing, why we’re doing it, and how we’ll measure success.
- You’ve developed a method of creating checkpoints and making adjustments when you see something isn’t going as planned.
- Write everything down. Writing simplifies, clarifies, and makes it easier to drive alignment. Writing also makes it easier to refine ideas through iteration and feedback, so your final version keeps getting better.
- There’s a clear decision-making process that secures buy-in from all involved parties, but with a single decision-maker who’s responsible for implementing the decision, tracking performance, and determining what needs to happen next.
- Be sure to create a culture that embraces failure and leverages mistakes to unlock untapped speed.
- Never become complacent. High-performance teams and companies focus on identifying areas for improvement and continuously working to better themselves and deliver on plan and on schedule.
Final thoughts
Building a high-performance team is not something that happens overnight. I’ve worked for years to develop the skills that have enabled me to attract the right kind of people and hone them into a highly productive, collaborative, and unified team. I have an outstanding executive team that has helped me distill these lessons and contributed to this blueprint.
Becoming the sort of leader that inspires people to build a great product and company that can change the world isn’t an endpoint; it’s a continuum.
You won’t start this process at the top
Remember — you’ll be bad at this before you’re mediocre and mediocre before you’re good and good before you’re great. But at each stage in your process, you should be able to see where you want to go.
By applying the techniques I’ve outlined above, you’ll be on your way to getting high-output management for your remote teams and companies.
Image Credit: krakenimages; unsplash; thank you!
The post High-Output Management for Remote Teams and Companies Part II appeared first on ReadWrite.
(36)
