Charity Majors Profile picture
cofounder/CTO @honeycombio, co-author of Observability Engineering and Database Reliability Engineering. I test in production and so do you. 🐝🏳️‍🌈🦄
45 subscribers
Sep 21 15 tweets 4 min read
I've written a few threads in recent memory on skip levels, and tbqh, some of these responses I've gotten have thrown me for quite a loop.

"You should talk to people who don't report to you directly" -- I did not think this would be a controversial statement!

Whuf 🙈 Replies came from all over the place:

* what's a skip level?

* why would I *want* to talk to my boss's boss? Sounds boring, what would even we talk about?

* why *should* I talk to my reports' reports? I don't want to confuse them, and anyway there are just too many of them
Sep 2 30 tweets 6 min read
I woke up this am, scanned Twitter from bed, and spent an hour debating whether I could stomach the energy to respond to the latest breathless fatwa from Paul Graham.

I fell asleep again before deciding; just as well, because @clairevo said it all more nicely than I would have. (Is that all I have to say? No, dammit, I guess it is not.)

This is so everything about PG in a nutshell, and why I find him so heartbreakingly frustrating.

The guy is brilliant, and a genius communicator. He's seen more and done more than I ever will, times a thousand.
Aug 30 5 tweets 2 min read
I would soften this a bit. Managers are *not* the only ones who can transform the culture of an org, but their buy-in and support are fundamental.

Good managers are channelers. They use their power to filter, amplify and leverage voices around the org to shape company culture. Important context: that post was quote tweeting this one.

Because I have also seen designers come in saying lovely things about transformation and user centricity, and end up wasting unthinkable quantities of organizational energy and time.

Aug 28 8 tweets 2 min read
Another way of looking at this is: if the real product of any software engineering team is shared understanding,

if the speed of sense-making is a core limiting factor on the speed of delivery,

then strong, futureproof engineering teams are 🌸continuous learning machines🌸 (by "futureproof" I mean "true 5y from now whether AI is writing 0% or 100% our lines of code)

And you know what's a great continuous e2e test of your team's prowess at learning and sensemaking?

1, regularly injecting fresh junior talent
2, composing teams of a range of levels
Aug 21 24 tweets 5 min read
The advance of LLMs and other AI tools is a rare opportunity to radically upend the way we talk and think about software development, and change our industry for the better.

The way we have traditionally talked about software centers on writing code, solving technical problems. LLMs challenge this -- in a way that can feel scary and disorienting. If the robots are coming for our life's work, what crumbs will be left for you and me?

But I would argue that this has always been a misrepresentation of the work, one which confuses the trees for the forest.
Aug 19 17 tweets 4 min read
A couple days back I went on a whole rant about lazy billionaires punching down and blaming wfh/"work life balance" for Google's long slide of loss dominance.

I actually want to take this up from the other side, and defend some of the much hated, much-maligned RTO initiatives. I'm purposely not quote tweeting anyone or any company. This is not about any one example, it's a synthesis of conversations I have had with techies and seen on Twitter.

There seems to be a sweeping consensus amongst engineers that RTO is unjust, unwarranted and cruel. Period.
Aug 17 14 tweets 4 min read
I don't usually weigh in on remote work vs colocated office work, but I caught that quote from Eric Schmidt this week and I'm still mad about it. 👇

Of all the things to blame Google's missed swings and eroding dominance on, you pick *this* thing? Working from home? REALLY.
Image What about oh, I don't know:

* a calcified, risk averse culture
* an addiction to fat, monopolistic margins on advertising revenues -- the fossil fuels of internet monetization
* a system that rewarded dilettante engineering over value creation or maintenance (HI READER)
Aug 12 25 tweets 5 min read
I wrote a post about the emerging generational gulf in observability tools.

O11y 1.0: many pillars, many tools, lots (but not all) are metrics backed. APM, RUM, tracing, logs, etc

O11y 2.0: wide, structured canonical log events are your source of truth

charity.wtf/2024/08/07/is-… It's never been simpler to understand the generational divide -- no laundry list of features to memorize and reason about -- and never been easier to understand why it matters so much.

Either your time and attention are scattered across many irreconcilable data sources, or not.
Aug 6 5 tweets 2 min read
🌼Skip levels
🌸Are an
🌻Organizational
🌷Necessity

If you don't have a 1x1 with your boss's boss, and/or each of your direct reports' reports, at least 2-4 times a year...why not?

Skip levels are e2e health checks for your management chain. This is basic org hygiene, people. "People leave managers, not companies", or so they say.

It shocks me how many people I talk to who don't have a regular 1x1 with their skip level.

This is not a relationship you want to start trying to build from scratch when something might already be deeply wrong. 😕
Jul 12 5 tweets 2 min read
Fwiw, I have seen MANY tech leads say the best manager they ever had was nontechnical. The manager relied utterly, unquestioningly on their TL's judgment.

I believe this is an enjoyable experience for the TL. 🙃

I'm not sure I believe it builds the best teams, orgs or products. Not necessarily saying this is the case here, esp since it sounds like the manager in question was fairly technical, just not adept with writing code.

But it's a pattern that stands out for its frequency.
Jun 25 5 tweets 2 min read
Well, I for one am not past this bullshit by now. ☺️ EMs who do some hands on engineering are better EMs.

Forbidding EMs from touching code at all is almost as silly and counterproductive as telling EMs that writing and shipping code is a core function of their role. I say "almost" because if I had to choose one or the other, I would choose the clarity of "EMs responsible for team outcomes, SWEs responsible for technical outcomes" over the muddle of holding EMs responsible for everything and splitting their focus between people and code.
Jun 10 15 tweets 4 min read
I have a new piece up. It's a bit of a rant, even for me, so buckle in.

A lot of "thought leaders" have been making their mortgages lately off of bits on how AI is going to replace software engineers, particularly entry-level engineers.

stackoverflow.blog/2024/06/10/gen…
This is a dumb idea. It bespeaks a wealth of misunderstanding about what it means to be an engineer and write code, and what is valuable and hard about software systems.

But even really dumb, damaging ideas can weasel into people's heads if you repeat them blindly enough times.
Apr 28 26 tweets 5 min read
In 2023 we saw several rounds of quality conversation around engineering productivity, thanks to McKinsey, @GergelyOrosz and @KentBeck and others.

It moved the industry forwards. 🙌 But it also felt fairly inside baseball to me. Deeply technical, lots of metrics. 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.
Apr 22 12 tweets 3 min read
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.

They are not *unrelated*, but they are different things.charity.wtf/2022/01/20/how…
Apr 11 12 tweets 3 min read
Say you want to modernize your org and introduce progressive deploys, feature flags, switch o11y vendors, etc. You could:

* roll each change out, one at a time
* change all at once, Big Bang style, migrating one service at a time

Has the Big Bang style EVER worked? For anyone? I can think of lots of examples of engineering orgs who *tried* the Big Bang style, but got wedged halfway through, or 20% of the way through.

I can think of lots of examples of orgs who are successfully bringing up *new* services on a new stack.
Mar 22 7 tweets 2 min read
Ooooohhh boy, this is a terrific question. I have written two closely related pieces,

* for engineers interviewing at a new company, on how to sniff out bad management culture:

* how to tell if the co is rotten on the inside: charity.wtf/2021/02/19/que…
charity.wtf/2022/01/29/how…
But both of those were written from the perspective of the engineer/interviewee, not the interviewer. The dynamic is different, for sure. 🤔

I would probably start by asking them why they became a manager, why they enjoy the job (if they do). (Softballs)
Feb 14 12 tweets 3 min read
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... 👉)
Jan 22 7 tweets 2 min read
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.



Instead of being the best of both worlds, TLMs are poorly equipped to do either.lethain.com/tech-lead-mana…
Jan 8 12 tweets 3 min read
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.
Dec 29, 2023 6 tweets 2 min read
This is an astute point. For all the ink that has been spilled about what observability is or is not, or how generation 2.0 differs from 1.0, it's actually quite simple.

"Observability" was coined to denote the emergence of ✨high cardinality✨ support in telemetry and tooling. Cardinality, for those new to my feed 🤣 refers to the number of unique items in a set. Gender drop-down with three options? Low cardinality. Gender field you can write to? Much, much higher cardinality.

Metrics can't do high cardinality data. A metric can only be a number.
Dec 22, 2023 32 tweets 6 min read
About two months ago I wrote this thread about how we lost the battle to define ✨observability✨ -- to give it a real, specific, falsifiable technical definition, distinct from monitoring or telemetry.

I complained, I argued, I grieved...and now I'm over it. SO over it. 🙄 In fact, I've come all the way around: I AGREE.

It is less useful for observability to stand for a specific set of technical capabilities and outcomes (explorability, high cardinality etc).

It is more useful, and less confusing, to define observability as a property of systems.