just wrote a 3k word article on why this (really good, i mean really exceptionally awesome) serverless parody of Hamilton has a chorus that i hate a lot.
"i'm gonna reduce your ops..
yeah i'm gonna reduce your ops"
yo, **ops is not a synonym for toil**.
operational engineering is the constellation of all your organizational skills, habits, best practices, defaults, tools, and aspirations around delivering software to users swiftly, efficiently and humanely.
"less ops" isn't necessarily better ops, any more than fewer lines of code necessarily means better software.
in either case, you need ... as much engineering as it takes to do the job well, and not a whit more. why is this hard?
i have mad respect for the serverless folks. but they seem to persistently misunderstand the reason for their own success, which is weird and frustrating.
the value of serverless isn't found in "less ops". the value of serverless is unlocked by **clear and powerful abstractions** that let you delegate large portions of your infrastructure to be run and managed by other people who can do it better (and more cheaply) than you can
to be clear, there's just as much ops going on as before. possibly more.
just _not by you_.
this isn't a reason to shit on ops and call for #NoOps bullshit, it's a reason to reevaluate your lingering wobbles around outsourcing higher-level services and abstractions.
because yes, operations is a cost center. if your mission doesn't involve solving infrastructure category problems, operational costs are a thing to be managed for efficiency.
doing this well is extremely difficult and takes a lot of experience and expertise.
what's the difference between automatically shipping 10x/day, rarely getting paged, and swiftly restoring service when you do,
vs shipping 1x/week (by hand, consuming days of engineering-time), getting paged 20x/day, and always escalating to the same person in a panic?
(ops)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
It felt, to me, like those participating were stepping very cautiously around a few of the third rails Jaana just tripped over. (💜)
"Work-life balance"
"Working hard vs working smart"
"Meritocracy"
The intersection of company tech cultures and expectations and performance.
These are hard, complicated topics, and there are some very good reasons for speaking carefully. People can pick up a sentence and run in the wrong direction with it, and do a lot of damage.
I have abandoned god only knows how many drafts on this topic, for that reason.
The question is, how can you interview and screen for engineers who care about the business and want to help build it, engineers who respect sales, marketing and other functions as their peers and equals?
It's a great question!! I have ideas, but would love to hear from others.
I said "question", but there are actually two: 1) how to hire engineers who are motivated by solving business problems and 2) aren't engineering supremacists.
Pro tip: any time you see someone confidently opining on what all good CTOs know or do, it is ✨bullshit✨
There is no stock template for CTO, or default set of expectations or responsibilities. It stands alone among the C-levels in that good ones are all over the freaking map.
This may not hold true for publicly traded companies. But in my experience, a good CTO can be:
* over all of R&D
* over engineering, like a VP eng
* like a principal eng or architect
* team lead for special projects
* a great senior programmer
(continued... 👉)
A CTO can also be:
* a great communicator and popularizer
* on the road as a devrel
* a field CTO, whose authority opens doors to big customers
* a product visionary who sweats the details
* more of a cofounder than technical contributor, sharing "company-running" duties w/CEO
Yeah, this is a fair caveat. If you're already a decent senior engineer and manager, it's kind of possible to split your attention between managing a small team and writing code.
But you aren't going to improve at either skill set. Those cycles get devoured by context switching.
Tech lead managers ("TLMs") are a mistake we make over and over in this industry. I've written about this a bit, but the definitive post was written by @Lethain.
My coworker @suchwinston wrote a terrific piece on burnout before the break:
There's a reason why burnout and work/life balance are such evergreen topics, and it's not actually because the world is so terribly harsh and everyone is criminally overworked.honeycomb.io/blog/product-m…
Just to be clear: some places *are* awful, and some people *are* criminally overworked. But burnout and work/life balance are an issue for everyone, not just those people.
I think this is bc there is no real "solution". Each of us has to find and maintain our own equilibrium.
It takes a lot of hard work to become good at technology, and a lot more hard work to maintain your edge in a fast-changing industry.
I don't know of anyone for whom this is _easy_. None of this is remotely natural, from an evolutionary perspective. 🐒