Morning!

\○/

Aloha 🌴 and a HNY 😄

Morning!

Anyone here (personally, or at their company) use OKRs?

I did they were pretty meh

I think it depends on your company / age and stage

At the place where I work, they are bringing them in I believe.

Why did you find them meh?

I think theres always a pull/push between fulfilling OKRS and doing your job

thats the tldr really

I found metrics to be both useful and unhelpful, its useful because it helps you focus on a greater goal for the company, but if they are the wrong metrics then its not as helpful.

@wesley.hall did u do OKR's i cant remember

morning

We use them. FWIW I think OKRs are great as a focussing tool. Kind of like a north star. When you start using them more as a cross-team communication tool they start to become painful.

Interesting

Do you set personal OKRs?

as far as i remember isnt it like, personal, team, department, overall company? that sorta level?

We have a 6-month OKR for the product/technology group and 3-month OKRs for each team in the group. The commercial side of the company prefer to do their own thing.

@guy The exact arrangement we use right now has evolved over the last few years. The great thing about it is you can tweak it until you find something that works, and then continue to tweak it as the organisation changes.

sounds good!

A lot of the examples of OKRs on t'interwebs are from a marketing/sales perspective, i.e., generate XXX revenue, onboard XXX clients

What might make a good KR for programming/projects perspective?

Code 50 sexps

Make 5 commits

I'm kidding, ignore me. 😊

🙂

I think I would do that in 1 hour, not 1 quarter 🙂

Well just looking at those two examples you gave, how can an engineering team help revenue generation or onboard more clients? Maybe the objective could be to increase product differentiation by building a new feature. A key result might be X% increase in AOV or Y clients using this feature

I was thinking more low level, like "decrease latency by 10%" or "write 50 more unit tests"

I guess I need to think more on this

To what end though?

Well, the objective would be "Improve client perception of the application" with a few KR's being "Decrease latency by 10%" etc...

Ah I see

and "Improve the quality of the application" with KR being "Write 50 more unit tests" et.c.

Here's the thing about "key results": a good key result isn't something you did, but something that happened because of what you did

So you might instead consider looking at NPS scores, support tickets or some other KPI

will nested sexps count, or only top-level ?

interesting insight tom!

E.g. Objective: Improve the client user experience by improving latency. Key result 1: X% improvement in NPS. Key result 2: Y% fewer "app is slow" support tickets

If you're interested, I recommend this book: https://www.amazon.co.uk/Radical-Focus-Achieving-Important-Objectives-ebook/dp/B01BFKJA0Y

thank you

If you like acronyms for goal/objective setting, here are my favorites: Objectives must be SMART: https://en.wikipedia.org/wiki/SMART_criteria For each objective, GROW: https://en.wikipedia.org/wiki/GROW_model

arrrgh

🙂

Morning

what are people's views on this:

{:foo (a-function-call with-parameters)}

vs

(when [result (a-function-call with-parameters)]
       {:foo result})

i.e., inline the function call when constructing a map, or bind the value before constructing the map?

it's not that important if result is nil, i.e., if :foo contains nil or not, it's more the style of approach, inline or separate?

i tend to prefer the former @dharrigan, since to my mind it requires less mental effort to comprehend... but it's all about comprehension, so if doing it all in one step starts to become overwhelming i would split it up

I also like the straightforwardness of the first, a quick glance is enough to know what you get, though you need to decide what's best: nil or {:foo nil} when the fn returns nil, only the last is "truthy"

I think I prefer the former too

I think if I was to inline everything, it could become a bit messy and hard to read

Is there any benefit to the latter one?

you mean to the when form?

use it when you need nil instead of a map with a nil value, other than that, and associated truthiness/falsiness, not sure there is much to it

Yeah, I think it's mostly style. In this instance, I would perfer the function to return nil, if the map can't be constructed without a nil.

so, when yes, but generally, I think I'll do the same using lets, etc..