Empowering a Hybrid Technology Team as CTO
The questions linger on the minds of professionals worldwide, including technology leaders:
Are we ever going back to permanent full-time work?
Is remote work here to stay forever?
What does the compromise look like?
Companies are making their decisions and the needle is pointing towards the hybrid workforce, at least for the immediate future.
Effectively managing a technology workforce isn't about reacting to what the world throws in our direction. It's about providing a framework for employees to be successful, regardless of which circumstances may come in the future.
Why do we at Gtmhub believe that OKRs help us do this?
Why should all technology leaders pay attention to this methodology?
The Hybrid Workforce and OKRs
Whether you are a CTO working cross-functionally with other c-leaders and your team, or an aspiring technology team leader looking for upward leverage in our rapidly shifting world, empowerment is the competitive advantage you should be fighting for.
At Gtmhub, we believe in the future of work as hybrid and have developed our strategy for hybrid team management since before the pandemic. Now at over 200 employees and growing, the way we manage our teams must scale as efficiently as our organization does.
This is a great vulnerability and a great opportunity. How do we scale the unscalable? OKRs are my methodology as a CTO, helping me establish empowerment as a pillar in my hybrid technology team. So, how do they do this?
OKRs: Bringing Focus, Eliminating Redundancy in Organizations
We have a meditation at Gtmhub: "how much is this meeting costing us?"
Every time a meeting is called, it eliminates hours of progress towards our outcomes — we consistently assess if meetings are going to help us better achieve our outcomes, or if they are redundant. Not every meeting can (or should) be eliminated, but this is one of the superpowers of OKRs — focus.
Rather than focus on the day-to-day operations and instructing teams on what to do, OKRs help CTOs empower teams focus on where to go. We align through our desired outcomes. I trust my team to pursue their own processes to reach outcomes and update the team consistently on their progress.
This is the ultimate flex of remote/hybrid work — fewer meetings, more focus on work. OKRs give us the middle ground to achieve more without foregoing the culture-building team rapport we need when scaling.
Our OKR-focused technology team favors self-service information, AKA "go find out for yourself instead of having a meeting." We have transparent, consistent updates on the progress of the technology team's initiatives through Key Results tracking, showing us quantitative updates on progress, such as new feature implementations.
We don't have to waste time in meetings talking about information that's already available to everyone. Meetings are focused, based on OKR updates from each of the team members. OKRs offer more depth on our meeting meditation, helping us structure meetings around questions like:
Which Key Results or KPIs do we need to discuss?
Are there any red flags?
Should we shift our focus in any areas or continue as is?
OKRs: Collaboration Through Documentation and Seamless Process
Our engineering operations could not be successful without taking the time for consistent documentation, especially in a hybrid environment. OKRs demand this documentation, which could be incorrectly assumed as a time drain. How do OKRs help us achieve more while wasting less time?
It begins with understanding that no single team can do all of the work alone.
We have product value chains that define the rules of engagement between design, product, and engineering. While each of these teams has its individual outputs, our outcomes cannot be achieved without cross-collaboration between these teams. OKRs help manage our rules of engagement and enable cross-collaboration via documentation.
Checking off task lists and improving outputs are not how we empower teams through OKRs. Providing consistent documentation by updating Key Results and giving commentary is the first step in enabling cross-collaboration.
When you have engineers and designers that are working 12 hours apart from each other, documentation is no longer a bonus: it's mission-critical.
Even though it takes time, we have to have this documentation and understanding so that other teams can do their jobs with as little friction as possible. Each team has to be able to pick up the work from the others and know exactly what they are looking at without calling together three different meetings (a much bigger time drain than simple, consistent documentation).
Whatever we do in product development must align with the priorities of engineering and design, and vice versa. If we want to do something new, and we’ve modeled our process correctly, OKRs allow us to make consistent progress on our KRs while experimenting with new ways to get there.
We can use our Objective to understand why a new initiative connects to our purpose and our Key Results to keep transparent progress on the initiative's impact. OKRs make us ask about the specific outcome that we are focusing on, informing us “why” we are doing something instead of basing the rationale on assumptions.
OKR-enabled documentation leads to a seamless process, allowing for flexible, yet productive technology teams.
OKRs: Efficiency or Effectiveness?
In an ideal world, we want to have the capacity to produce outcomes at high quality and quantity. One of the main arguments against a hybrid/remote-first workforce is a loss of productivity and efficiency due to lagging/asynchronous communication. In a workplace without OKRs, this is a reasonable argument.
OKRs give technology teams the structure they need for effective collaboration despite physical separation, thanks to the focus on outcomes over outputs. While technology teams may be looked at as output engines, efficiency is not necessarily indicative of team success.
Pushing high quantity on minimum viable products isn’t our definition of winning. These MVPs can lack the quality to push the needle on our desired quarterly or yearly outcomes, serving no purpose to the organization and only to our egos. This is where OKRs come in, challenging with the collaborative question of "Why?" between engineering, design, and product.
OKRs keep us focused on quality control while not being obsessed with perfection.
Technology teams target velocity and constant Key Result progress, satisfying the efficiency/output argument. Simultaneously, they take into consideration "why" certain initiatives must take precedence to push desired outcomes through cross-collaboration, satisfying the effectiveness/efficiency argument.
Software engineers should not have to think about UI tests.
UI designers should not have to obsess over technical code.
OKRs allow departments to focus on their initiatives while considering the ultimate goals, outcomes, and limitations of the entire team.
Want to continue learning about how to leverage OKRs for improving technology strategy and operations?
Feature photograph by Chris Montgomery, source: Unsplash