297 karma · joined November 10, 2013
Its not about bribing to get a specific favor. Its about getting on good terms. Having people like you is a good thing and it makes their job a bit better and can make their day a little brighter. win-win
It doesn't since file:/// is just a uri and not part of the http protocol
And, while it's always been a popularity contest at it's core, I can't help feeling some disappointment at seeing it descend into whatever nonsense it has become.
So really I guess I miss them as the high quality signal it used to be and it's on me to find new signals
It's a bit of a work in progress as the assembly needs adjusting and degunking in order to run. However, when hooked up to a generator, the motor spins right up
First problem would be how do they even transport, store, and guard it without being jumped, ripped off and robbed? Did they think millions of coins would fit in a few sacks?
Maybe a "No Country For Old Men" type situation? Sure they're rich as kings but there are more powerful beings that know about their wealth and they are coming.
I do think you lose out in an abstract system though. Delving for treasure in a dangerous dungeon was most the appeal of the early RPGs. It's not quite the same rush discovering a horde that then gets abstracted away
glad to see it getting slapped down.
If the goal is to build a managed k8s service, a team of talented people can build it without the need for OKRs.
Coming from an SRE backround I see a better OKR breakdown on the Engineering side as follows:
* Objective: A stable Managed service that the business can sell * Key Result: - A monthly availability of 99.99% * Key Result: - Monthly P90 API latency below 500ms * Key Result: - a new instance of the service serving customers in the new region by the end of the quarter.
(Yes, these are really just SLOs, they're a good fit for this)
I know the objective rolls up to the business goal of a revenue target. I know that if i'm meeting my own goal buy the metrics we can measure from the service. I know how to prioritize engineering work. If one target is being missed consistently, the fixes are going to be prioritized At review time, I can point to improvement work that fixed/improved the results an know the business thinks its important.
Give me some vague objective and unmeasurable of researching and understanding something? I'll BS my way through filling out the form and go back to improving the service
Also its unclear how the team KPIs tie into overall Objective (Key Results are missing here). The way its structured, every team could meet their KPIs and the company could still miss the objective. Eng can build a stable k8s, product could research all the things they want, support could understand everything, marketing could understand everything. If customers don't buy the product, the objective has been missed
I don't say this to pick on you but these examples are typical of what i've seen in practice when orgs roll this out. They end up not really groking the idea behind OKR, and slap the label on a process that is largely similar to what they had before but with a trendy new name. The net result isn't better business outcomes but instead a lot of toil, infighting about why OKRs were missed, gamed KPIs, vague and unhelpful "targets", and a distaste for the whole process.
Its likely persisted since than largely since removing the old model would be a difficult taks without potentially breaking a lot of customer's setup
I don't think there is a coherent definition of craft breweries that includes Anchor but not Yuengling