
Making the Switch: The Reality of Moving from Windows to Mac for Your Software Engineering Team
If you have a team of software engineers and want to move them to Mac, you will need to consider a number of things before you do so.
If you have a team of software engineers and want to move them to Mac, you will need to consider a number of things before you do so.
Here’s what’s new in our January 2023 Release Notes:
* Tables Columns Sorting Improved
* Reconcile Commits Count Between KPI Card and the Table
* Efficiency Tab Improvements and Efficiency KPI Cards Align
What should be your goals as a software engineering manager? What are the goals for your team? And how do they align with your company’s goals, vision, and mission? More than just goals or kpis, the best way to answer these questions is with Objectives and Key Results. Some people do more before breakfast than most people do all day. Today, though, we’re going to look at more goal-setting techniques (and acronyms for them) than most people will do all year.
If there’s one overarching goal for all software engineering managers, it’s likely to be the continuous development of your team to support your organization’s vision and mission. Yeah, that’s part of the job description. It’s all-encompassing and it’s worth striving to perfect. By the time you realize perfection, your standards for it will have changed. Goals evolve over time and as organizations grow.
This one goal encompasses a great many other objectives, each very important in their own right. These can range from hiring the right people with the right skills for an early-stage startup to reducing code complexity with a rapidly growing team, improving velocity (story points per sprint), and the list goes on, and on.
Objectives are general, but ambitious goals associated with the company vision and mission. They are meant to focus efforts on “a few things that will have the greatest organizational impact. OKRs are often associated with “Moon Shots” – stretching or 10x’ing ordinary achievements into spectacular ones. Let’s expand on this briefly.
Making the effort to do OKRs for what you know you can achieve and will probably accomplish anyway is a waste of time. OKR objectives are meant to push you into getting all of the fruit on the tree, not just the easy pickings. Even if you don’t get ‘em all, you’ll have a lot more than if you stuck to the low-hanging fruit. OKRs are meant to be very difficult, a stretch on what you know or believe to be possible.
Additional points about Objectives and Key Results that you should know include:
Key Results are verifiable and measurable. If you can’t put a number to it, it’s not an OKR.
Key Performance Indicators measure performance trends – what you’ve done and are doing to help you plan for the future. While you may have performance standards and goals for your KPI’s, they’re likely self-contained and not tied to a strategic chain of events to some ultimate outcome.
OKRs start with an Objective and then define the Key Results needed to reach it. Some of the Key Results may indeed be KPIs as we’ll show in some examples, shortly.
Do you have to choose? Yes, you do – though it boils down (mainly) to asking yourself one very important question:
“Do we want realistic and achievable goals or ambitious ones?”
Here’s what the two Goal Setting Acronyms mean:
SMART Goals | FAST Goals |
---|---|
|
|
Or, to put it another way:
“Do we need more glorified To Do lists or… or… OR… Do we want to kick some buttocks?!”
Feel free to use another word other than buttocks. Many engineers might prefer kicking rear ends or back-ends – for a more distinguished euphemism.
Objectives and Key Results have a very simple format and are easy to write. Coming up with effective and meaningful OKRs that align them across individual, team, project, and company tiers is more complex.
So, let’s start with the simple tasks and establish the three core elements of an OKR:
In large organizations, it may also be helpful to define if there are additional individuals or teams that may need to be involved in another team’s OKRs.
Thus, an OKR addresses who is involved (Team + any collaborators), what they intend to accomplish, its conditions for success, and when it must be accomplished. Why, one way or another, relates to the company vision/mission. The one thing it doesn’t define is how it will be accomplished.
The following provide some simple, generic, but ambitious examples of OKRs that engineering managers might use. It’s an easy format. Aligning your Team OKRs to your Company OKRs is what’s most important.
Key Results:
Any company that releases software benefits from increasing quality.
Key Results:
For more on CyberSecurity news and resources, checkout:
Key Results:
There was once a game, still exists, but every freakin’ time I went to play – it was down. Eventually, it’d come back up. Good game. Fubar reliability. I’d like to single out the company, but won’t. You want customers to have confidence that your software works – when it doesn’t, it can induce feelings of WTF/Rage Quit. On the other hand, Standing Stone Games took it over – and it’s vastly improved.
Oh, yes, that’s right, we were talking about OKRs!
Key Results:
On a long enough timeline, all automation will provide an ROI. Often, it’s not how much the automation will cost, but how much effort will be needed to integrate it into your work processes.
According to WhatMatters, the benefits of OKRs boil down to FACTS, you guessed it, another acronym for Focus, Alignment, Commitment, Tracking, and Stretching.
OKRs provide a means to focus the collective efforts of your entire organization on “what matters most” in the pursuit of your company vision and mission, on a periodic basis.
What really sets it apart is the Stretching – the 10x’ing Moonshots, or even Mars Shots. It’s not a matter of knowing how you will accomplish a given goal – that’s part of the discovery process. Once someone commits to making something happen they’re inclined to be highly resourceful in finding a way to make it happen.
I remember back in 1996 or so, using Yahoo as my search engine of choice, even though it was really more of a searchable directory. Then, suddenly, everyone was using Google. And we’re still using Google. We can even use Google to search for what other people are searching for. That’s a reflection on Google’s use of OKRs to 10x efforts.
Search Volume for OKRs on Google Trends:
Lastly, there’s a debate whether to conduct OKRs at the individual contributor level or not. Doing so adds complexity and effort while most people adopt realistic goals instead of aspiring to Moonshots. OKRs should not be part of any performance evaluation. OKRs are also not tied to any kind of financial reward. Many managers drop individual OKRs to make sure all team members are focused on team OKRs. That’s a perfectly valid option and it keeps everyone on the team aligned to identical objectives.
The time to manage individual OKRs doesn’t scale well. It might be a small effort to cover OKRs with three to five team members, but fifty or five hundred?
On the other hand, great software engineering managers should regularly interact with their team members. Where three to five OKRs might be overkill, it can be worth customizing one team-based OKR to the “one thing” they can do to have the biggest impact. This is prone to vary from senior to mid-level to junior developer.
If nothing else, this provides you a good reason to interact with your developers on a regular basis.
We’re hard at work transforming our software development analytics into an AI-powered Digital Assistant. This could make it a lot easier, 10x easier – to extend OKRs to individual developers.
Here’s the thing. With analytics, an engineering manager could spend an hour digging through a developer’s metrics to find an actionable insight to help improve their throughput, for a realistic (even conservative) 1,000% ROI.
With AI, you only need to ask your Digital Assistant questions about how to help your developers, or teams, and get data-driven, actionable insights in minutes. It improves your “Cycle Time for Insights” to about as fast as you can come up with a question, review the data, and decide if it’s valid. AI is a lot faster about finding patterns in Big Data than we are.
Most engineering managers can use this to quickly prepare for One-on-One Meetings – common to most development teams. But, the same extends to supporting Objective and Key Results for individual developers and teams. Instead of spending 7-8 hours sorting and comparing developer metrics for your entire team (say 5- 9 members), you could have all the research done in an hour and even fit in a ten-minute break.
There’s a lot more to it than that, of course. If you’re curious, we invite you to check out the following articles about how AI can help you 10x your team’s performance – however large and distributed it may be.
Post updated: February 16, 2022