This, among others of Aaron's tweets around this one is something other engineers should pay attention to. OKRs, sprints, quarterly goals are very common and they involve pretty large tradeoffs when running a team in this way. A big tradeoff is… 1/
that you cannot accomplish anything that can't be described in this way (i.e. satisfies an OKR or can be thought of as completable in a quarter). Many engineers DO need structure like this to get things done, but not all do, leading to another tradeoff… 2/
which is that engineers capable of delivering value that doesn't fit in these structures end up being miserable, because they are required to only deliver the sorts of value that can be managed by these structures. hus, if the way you manage your work is highly structured… 3/
it means that a certain class of developers will be miserable working for you at best, or just not work for you at all. And THIS means that you essentially cannot accomplish a certain type of valuable work because you've put homogeneity above value… 4/
In a sense saying that it's more important that a process be followed than identifying and solving the right problems in the right way. And when the right problems have solutions that don't all have the same "shape", you get an impedence mismatch and your team… 5/
then is only capable of certain types of work and can only employ certain types of people. I don't know Aaron but I see myself in his tweet and can list out MANY valuable accomplishments I have made that would not have been possible if I had to deal with e.g. OKRs 6/
I'm also trying not to judge the use of sprints/OKRs/quarterly planning because as I said, some engineers cannot get things done without that structure and that is OK, and that it's not "wrong" to want to prioritize predictability over value. That said… 7/
I will never do my best work having to deal with OKRs, rigid planning, sprints, demo time, or any of these other rituals and this was not immediately obvious to me until I was subjected to it. And so I will personally not put up with any of it for as long as I can, which… 8/
I absolutely understand the privilege in that statement. But what it means for me now is that I know a thing about myself that I can use when finding jobs so that I can find the place that fits for me. It took 20 years for me to figure that out, though. Given that… 9/
Engineering leaders would do well to be more honest with themselves about the tradeoffs they are making by requiring process or fitting work into a it. Be honest that all processes prevent certain classes of work from happening & certain types of engineers from participating 10/
Being able to differentiate between "this engineer needs help breaking down projects" from "this engineer does a type of work that isn't suited to the process we have". When you are this honest, the next step actually requires some real fucking leadership 11/
Which is to say either "I understand you will be miserable working here" OR (for good leaders only), creating a way for that person to be happy working here by challenging the need for homogeneity. Can you fight for your person to stop trading off value for process? 12/
It's hard enough to differentiate "junior, needs experience" from "provides value that I am unable to extract", and it's SUPER hard to then push up the chain to create an environment where those few valuable engineers can stay and be happy and be productive 13/
because management and leadership isn't only about ensuring conformance to a process. If that's all your manager does, there is a problem somewhere. My experience tells me that the problem is weak managers who aren't told what their job is or given the means to learn to do it 14/
But the "managed" are the ones that suffer, especially those that can deliver great value but not if asked to conform to a specific process. Good managers manage the individual, whatever that means (but it should not require looking at JIRA). I realize I'm NOW getting judgy 15/
So I want to say that in most cases "weak managers" aren't evil, they are just asked to do a job they can't (yet) do and given no help or guidance in learning the job. Follow it up the chain and that might be all you find: people trying to do a job they can't yet do 16/
As I've mentioned, incompetence isn't bad on its own—we are all incompetent at something and thats' part of learning. But it doesn't mean that we have to put up with incompetence either. OK, I'm super off course with this rant, but try to sum it up… 17/
Quarterly roadmaps/OKRs/sprints aren't defacto stupid or bad, but they also aren't defacto correct. They aren't the only way to get value out of software engineers and AS software engineers, there is no shame in knowing that you cannot be effective under OKRs…18/
And that no one is less of engineer if they can't work under them. There is no such thing as a "good engineer", anyway. But if an org cannot get value out of Aaron, that is on them.
(This rant brought to you by the GoLang compiler being slower than Rails system tests) 19/19
(This rant brought to you by the GoLang compiler being slower than Rails system tests) 19/19
