As an engineer OKRs are a bit of a conflicting thing, and here's the reasons... - I don't decide what projects come my way. Product or management decides that.

As an engineer OKRs are a bit of a conflicting thing, and here's the reasons... - I don't decide what projects come my way. Product or management decides that. - My concerns are: "Is the company going to be around for > 6 months?" because if the answer is yes than my concerns are "In 6 months, make sure we don't hit a wall that will be a stop all development situation". I've seen it. - OKRs are always going to be goals of the company. My question will always be: What can eng do to actually affect these OKRs? Are customers leaving due to bugs? Eng will prioritize bugs. Are customers leaving due to lack of features? Eng will build features. Is the company about to run out of money? Eng needs to build as much and as fast as possible and ignore any long-term problems because we need to get customers. Basically either department heads need to take the current OKRs and transform them into department specific OKRs or they become meaningless. There needs to be engineering OKRs around things that engineering can affect. Not product OKRs which product will affect. Not sales OKRs which sales affects. Example of a product OKR: - increase customer conversion rates by 0.5% every 2 weeks for the next 2 months. Example of an engineering OKR: - enable product to A/B test - enable product to measure more data points to make decisions to reach their OKRs