/Charity Majors

The Future of Ops Is Platform Engineering tl;dr: "In the beginning, there were people who wrote and ran software. At some point, we spun away ops skills from dev skills into two different professions, but that turned out to be a ginormous mistake, so along came DevOps to reunify them. Nowadays, ops as an independent profession is in the process of fading out. Companies are spinning down their ops teams left and right. Engineers who formerly identified as sysadmins or operations have turned into DevOps engineers, and soon there will just be “software people” again. This is the way of things."

featured in #361


Every Achievement Has a Denominator tl;dr: "One of the classic failure modes of management is the empire-builder — the managers who measure their own status, rank or value by the number of teams and people “under” them." Charity argues the case for the opposite i.e. managing with a small denominator, or set of resources, and delivering outsized results. 

featured in #356


The Hierarchy Is Bullshit (And Bad For Business) tl;dr: "It took two decades, an IPO and a vicious case of burnout before she allowed herself to admit how much she hated her work, and how desperately she envied (guess who??) the software engineers she worked alongside. Turns out, all she ever really wanted to do was write code every day. And now, to her dismay, it felt too late. Why did it take Molly so long to realize what made her happy? I personally blame the fucking hierarchy."

featured in #354


Rituals For Engineering Teams tl;dr: "The thing that grabbed me here is that rituals create a sense of belonging. You show that you belong to the group by participating in the ritual... It seems especially relevant these days when so many of us are atomized and physically separated from our teammates. That ineffable sense of belonging can make all the difference between a job that you do and a role that feeds your soul." Charity provides examples from various teams.

featured in #343


Questionable Advice: Is There A Path Back From CTO To Engineer? tl;dr: "It is absolutely possible to return after a few years away. And yeah, you could come back as a principal or staff engineer. Someone will definitely hire you. However, I suggest otherwise. I suggest you come back as a senior engineer, writing software every day, for a good 6-9 months. Your grounding in the technical challenges and solution space will be much deeper and richer if you come back hands on than if you came in at a higher level..."

featured in #342


Advice For Engineering Managers Who Want To Climb The Ladder tl;dr: "We have been interviewing and hiring a pile of engineering directors at Honeycomb lately. In so doing, I’ve had some fascinating conversations with engineering managers who have been trying unsuccessfully to make the leap to director. Here is a roundup of some of the ideas and advice I shared with them."

featured in #325


Twin Anxieties Of The Engineer / Manager Pendulum tl;dr: Leaving management for an IC role creates anxiety that you may not be able to return to management later on. Charity doesn't think so. If you’re a good manager, you'll improve as an IC and will "spend the rest of your career fending off management opportunities." Moving back to IC also creates anxiety around performing again as an engineer. "After 2 or 3 years of management, it’s pretty easy to go back to engineering. After five years, it gets progressively harder. But it can be done."

featured in #303


How You Can Tell If The Company You're Interviewing With Is Rotten On The Inside? tl;dr: Charity presents strategies, such as backchanneling with contacts, effective D&I practices, and also maintains that how the interview is organized is telling: (1) Was the interview conducted in a timely fashion? Were you given detailed information about what to expect? (2) Were you compensated for your any take-home projects. (3) Did they get back to you swiftly at each step of the way to let you know where you stand and what comes next?

featured in #293


How "Engineering-Drive" Leads To "Engineering-Supremacy" tl;dr: Companies that describe themselves as engineering-driven tend to fall into 2 traps: (1) They alienate the business side showing little interest in other functions, such as sales or marketing. (2) Act like engineering is superior to other roles in the company. Charity hires engineers that show interest in the business, and believes that caring for the business is a "learnable skill" highlighting the tactics used at her company. 

featured in #284


Software Deploys And Cognitive Biases tl;dr: There are real reasons for not deploying on Fridays, and there are others often cited driven by biases, such as: (1) “It is more dangerous to deploy than not to deploy” - prevention bias. (2) “It’s always riskier to do something than to not do something” - omission bias. (3) “Deploys are scary, so we need to slow down and be careful” - slow motion bias, and more.

featured in #250