Let’s clarify: I am not against using objectives as a tech executive to guide your organization. In fact, I believe they are a fantastic tool for gaining alignment and focus. However, I have an issue with bad objectives that serve the exact opposite. This article covers what should be your default focus for objectives, what are the common pitfalls, and when it does make sense to add others.
The Obvious
We’ll start by getting the obviously good objectives out of the way. Virtually every R&D organization I work with has “delivery of product goals” as part of its objectives. After all, Product people can research and make plans, but those will never move the needle if they are manifested in features for clients. Therefore, many teams have objectives that are around this.
Some companies invest in translating different product objectives into how those would look like for R&D. Others go for the plain “deliver on the product roadmap, so we achieve business goals X.” And, of course, there are those aiming for empowered product teams, where those cross-functional teams have a business objective that they work on together to achieve. While some of these are certainly better than others, they are similar in that the objective stresses that the team should deliver product progress.
This is obviously a good thing. After all, that’s the main reason your organization exists. No one hires engineers to rack up prettily indented code. So, these might not be exciting from a technical point of view, but they are great for alignment and focus.
Further, objectives regarding specific business health or quality KPIs can also be beneficial. For example, aiming for a particular SLA, reducing the number of new bugs introduced, or improving the marginal cost of each additional customer.
The Dangerous
When we try to add objectives beyond the basic product roadmap ones, things get messy. I usually ask what triggered the addition of these extra objectives. The responses I most commonly hear from my clients are: a) “The CEO asked me to add something,” b) “I wanted an objective that’s not just about Product to differentiate us,” c) “The ICs wanted to see something about their craft and tech advancements.”
That’s how we end up with objectives about moving to Kubernetes, adding a micro-service somewhere, or refactoring parts of the system. Those are very technical and don’t fit the classical definition of an objective. Other times, we see objectives like “hire X more engineers,” which I feel is similarly lacking.
These goals are all doable and can probably keep entire teams busy for months. However, merely achieving them is unlikely to move the needle. In some cases, it’s purely detrimental to getting other, more important things done.
Adding extra objectives for weak reasons mainly dilutes the importance of all other objectives and splits your group’s focus even further. Therefore, in most cases, the above goals are better off serving as key results for different objectives, and only after you’ve concluded they are genuinely part of the best route to achieve said goals. Anything else is busywork or tech for tech’s sake.
Similarly, working to “reduce tech debt” is rarely attractive. Tech debt, like most things, obeys the 80/20 principle. We often get value out of the first 20% but allow ourselves to go on even though it doesn’t make sense.
The Vigorous
All this is not to claim that R&D organizations must solely focus on delivering product goals. When I talk about transforming engineering teams from cost centers to innovation centers, I make the exact opposite case (more details in the free sample chapter you can get at the bottom of this post). Teams that merely execute the roadmap, while maybe better off than others, are lacking in ambition and are not fulfilling their potential.
However, this expansion of focus should occur at the right time and with the right goals in mind. Contrary to the above examples, these efforts should originate from impact and not tech interests. Examples can include spending time to work on engineering velocity so that your releases, builds, and deployments are faster, safer, and less error-prone.
Another would be an initiative stemming from R&D to research what ML, IoT, or AI might mean for the company. These aren’t just techies obsessing over the new shiny thing but coming up with ideas for innovation and placing calculated bets on them. The right time is usually after the company has reached product-market fit or when the product has enough certainty to allow some defocusing. Don’t just mindlessly add objectives because you want to make your slide for the board meeting look spicier!