I am so incredibly happy to share that @lizthegrey is now our Field CTO.
We try to handle promotions as confirmation of a job already being well done, and that is definitely the case here. Liz is an excellent developer advocate, but never "just" that.
@lizthegrey Over the time she has been here (nearly 4 years!!) she's been an SRE, devrel, solutions architect, and product marketing all rolled up into one, with the occasional dollop of product engineer, product designer, and sales engineer to boot.
@lizthegrey She has also unfailingly been an advocate both for the success of the business and for the people who work here.
We put an elected employee on our board earlier this year -- that idea came from a conversation Liz and I had her very first week here.
@lizthegrey On a personal level, I can always rely on her to tell me when something I say or do isn't landing well. I value this unutterably.
And whenever I bring the same type of concerns to her, she takes it seriously and deeply to heart.
They say you should never work with your heroes, or you'll inevitably be disappointed. We all have feet of clay. ☺️
But working with Liz has been a joy, a surprise, a challenge, a constant inspiration to do better and be better. She is the exception that proves the rule, IMO.
And just to end on a petty/ridiculous note ... there were a couple times this year that Liz wasn't allowed to be on stage for some event because "only VPs and C-levels" were allowed.
I thought I might need to address this; it's come up more than once (whole 🧵 is good).
The fact that this comes up every time I mention trailing promotions tells me there are lots of people out there who feel they are being taken advantage of by promo policies vs hiring policy.
*Because* platform engineering is such a minimalist discipline, because it focuses so narrowly on
✨run less code✨&&
✨write less code✨
and enabling/empowering other engineers, the code that it DOES write has to be better. And extremely customized to your environment.
Any asshole can squirt out a ton of code to do a thing. But then you're saddled with that thing for all eternity, to run and own and debug and wake up and feed at 2 am.
A platform team's job is to do the opposite of all that,
Like I said in the piece, I think a lot of startups are founded by kids, and the only way they know how to try and get better results is to work longer, harder hours.
In my life, I definitely worked the longest hours the times when I had the least clue what I was doing.
When it comes to being an early employee, though, the trait I would stress (and hire for) is less about working stupid hours, and more about being willing and able to own results.
Owning results means you may have to work hard or long sometimes, and you may not get to pick when.
I wish I had read this before writing my piece on platform engineering, or I would have taken greater pains to ensure my piece sounded nothing like it. 😑
"devops is dead! long live platform engineering!" sets my fucking teeth on edge.
i don't fucking care if you don't "want to do ops" or not. because "ops" doesn't mean "shitwork", you shithead, it's the constellation of practices, skills, instincts, and expertise it takes to build quality systems and deliver value to users.
Devaluing this expertise and pretending you can do without it is the best way to ensure you do a shit job of it, and can't hire or retain anybody with the skills you need for operational excellence.
I don't mind giving my time away to mentor people. I mind my donated time being the product that a VC-backed company is marketing and selling for profit.
When @platohq first reached out to me, I thought "this is cool, I'll pitch in. Pay it forward a bit." I expect that's why so many other CTOs, VPs and founders all made time in their packed schedules.
I assumed it was free, or maybe a nominal/sliding scale fee for attendees.
@platohq In their communication with me, Plato came across like a nonprofit -- it was all about the joy of giving back, etc.
I can't say they actively lied to me, but I haven't yet met a Plato mentor who was aware of their business model going in and okay with it.
The first type of code is your crown jewels. It's the code in your github repository, the stuff your users interact with. It's your job to instrument it, actively maintain it, and understand it intimately.
It changes and deploys constantly, on the order of days if not hours.
The second type of code is the code you rely on to run the code you write yourselves, everything from device drivers up to language libraries. Millions and millions of lines indeed.
We call it "infrastructure", and it changes slowly, on the order of months or years.