OKRs from a development team’s perspective

I guess?

But I, as an engineer, don't know accounting, or how to setup a healthcare plan, or the intricacies of VC funding documents, etc. Thinking about how people use what you are building and how to make it better seems like table stakes for engineers in the startup world.

Thinking about the product and users is the job of engineers. So is coding a solution. And so is not coding a solution when there is a better option.

I guess if you get to a later stage startup, where you are working on very specific technical problems, you might be forgiven if you don't know what it means to the larger organization, but I can't imagine working in that environment and being happy. A fancy algorithm is cool I guess, but if I don't know how it's moving the business forward it's basically meaningless to me.

YMMV

Because we're too expensive to waste on something another employee could do. The bitter irony is we're so expensive largely because being siloed leads to wasted effort and rework.

OKRs do force you to put down your company's priorities and metrics to measure their success. Unable to do that usually is a symptom of being too tactical and reactive and not having a strong strategy/vision.

Company-level OKRs are only as good as your leadership team's clarity on strategy and long-term direction and conviction to largely stay the course for at least 3 month chunks.

If you feel your company OKRs are bad or you are unable to connect with it, it is because your leadership team has not done the necessary homework to define and socialize it well.

If you agree your company OKRs make sense but you are unable to connect it to your work, think of it this way:

For a functional feature engineer, the team OKRs should clearly and directly connect the features they are working on to the company OKRs. If not, then you need to engage with your product managers to achieve that clarity.

For a senior platform engineer responsible for evolution of tech platforms, it is critical to have a good sense of the direction in which business will evolve and expand. (Annual OKRs and strategy articulations are crucial for this). From this, you should be able to draw out a mind map of the kinds of features and capabilities needed by your platform. Then you can articulate this to your team to build those required enhancements to the platform while also ensuring immediate feature building activity is moving as productively as possible.

If you are unable to connect the dots between the business OKRs and tech platform OKRs, it is usually a sign that there isn't a good functional model for your business domain and your tech platform isn't really a platform that supports that functional model. For architects, this should be the most important deep work – to keep the functional model of the business and that of tech platforms in sync. Without this common model, teams cannot collaborate effectively.

Having worked with hundreds of companies on their OKRs at Weekdone, I've seen many hack OKRs on individual level and use them "wrong" by having the KRs as milestones, tasks and projects. Yes, absolutely illegal by some leading OKR consultants and thinkers. But works like magic to keep goals in front of people.

Having the choice of having a developer or designer a visionary KR of improving x or y by z% vs getting a project, milestone or task done, in many cases the latter keeps them focused vs them rolling their ideas on the % KR.

Or you could just fix all the bugs that are upsetting customers and causing them to flee.

I've been in the situation where the metrics were used at a detailed level. Net Promotor Score (NPS) was used by the company and I tried, somewhat successfully, somewhat unsuccessfully to use OKRs at the team level. I agree with everything that has been said in using these to set the overall the direction and strategy at a high/medium level but down on the front lines it's very hard to do anything that will move the needle in the right direction in a clear cause and effect way.

If you try and map tasks to strategic goal then you just up window-dressing everything to keep management happy and since the components of goal X are many any varied your chances of success are limited.