Twin Anxieties of the Engineer/Manager Pendulum

I have written a lot about the pendulum swing between engineering and management, so I often hear from people who are angsting about the transition.

A quick recap of the relevant posts:

There are two anxieties I hear people express above all the rest.

The first one is something I hear over and over again, particularly from first-time managers as they contemplate the possibility of leaving management and returning to IC (individual contributor) work as an engineer:

“What if I never get another shot at people management?”
“Maybe this is the only chance I’ll ever get … and I’m about to give it up??”
“Am I going to regret this?”

“Will I ever get another shot at management?”

People decide to go back to engineering for lots of reasons. Maybe they’re burned out, or they work someplace with a poisonous management culture, or they’re having a kid and want to return to a role that feels more comfortable for a while. Or maybe they’ve been managing teams for a few years now, and have decided it’s time to go back to the well and refresh their technical skills in the interest of their long-term employability.

Regardless, these are not typically people who disliked being a manager. Rather they tend to be engineers who really enjoyed people management, and find it bittersweet to give up. Maybe they will miss the strategic elements and roadmap work, but they’re excited to clear their calendar and spend time in flow again, or they will miss having 1x1s but can’t wait to have time to mentor people. Whatever. They want to manage teams again someday, and worry they won’t get another chance.

Their anxiety is understandable! Lots of people feel like they waited a long time to be tapped for management, or like they were passed over again and again. Our cultural scripts about management definitely contribute to this sense of scarcity and diminution of agency (i.e. that management is a promotion, it is bestowed on you by your “superiors” as a reward for your performance, and it is pushy or improper to openly seek the role for yourself).

This anxiety is also, in my experience, ridiculously misplaced. ☺️

Once a manager, marked for life as a manager

You may have struggled to get your first opportunity to manage a team. But it’s a whole different story once you’ve done the job. Now you have the skills and the experience, and people can smell it on you.

I’m not joking. If you’re a good manager it’s actually nearly impossible to hide that you have the skills, because of the way it infuses your work and everything that you do as an IC. You get better at prioritization, more attuned to the needs of the business, and restless about work that doesn’t materially move the business forward. You get better at asking questions about why things need to be done and at communicating with stakeholders. You get better at motivating the people you work with, understanding their motivations and your own, and mediating conflicts or putting a damper on drama between peers. People come to you for advice and may seem to just do what you say, or go where you point.

Senior engineers with management experience are worth their weight in gold. They are valuable contributors and influential teammates. It’s a palpable shift! And every experienced manager in their vicinity will sense it.

So yes, you will be tapped for management again. And again and again and again. You are more likely to spend the rest of your career fending off management “opportunities” with a baseball bat than you are to wither away, pining for another shot.

There is a chronic shortage of good engineering managers, just like there is a chronic shortage of good, empathetic managers in every line of work. The challenge you will face from now on will not be about getting the chance to manage a team, but about being intentional and firm in carving out the time you need to recover and recharge your skills as an engineer.

“Am I too rusty to go back to engineering?”

The second anxiety is in some ways a mirror of the first:

“Can I still perform as an engineer?”
“Will anyone hire me for an engineering role?”
“Has it been too long, am I too rusty, will I be able to pull my weight?”

This is a more materially valid concern than the first one, in my opinion. Your engineering skills do wither and erode as time goes on. It will take longer and longer to refresh your skills the longer you go without using them. Management skills don’t decay in the same way that technical ones do, nor do they go out of date every few years as languages, frameworks and technologies tend to do.

If you aren’t interested in climbing the ladder and becoming a director or VP — or rather, if you aren’t actively, successfully climbing the ladder — you should have a strategy for keeping your hands-on skills sharp, because your ability to be a strong line manager is grounded in your own engineering skills.

Never, ever accept a managerial role until you are already solidly senior as an engineer. To me this means at least seven years or more writing and shipping code; definitely, absolutely no less than five. It may feel like a compliment when someone offers you the job of manager — hell, take the compliment 🙃 — but they are not doing you any favors when it comes to your career or your ability to be effective.

When you accept your first manager job, I think you should make a commitment to yourself to stick it out for two years. That’s how long it takes to rewire your instincts and synapses, to learn enough that you can tell whether you’re doing a good job or not.

After two or three years of management, it’s still pretty easy to go back to engineering. After five years, it gets progressively harder. But it can be done. And it should be worth it to your employer to invest in keeping you while you refresh your skills over the six months or whatever it may take. Insist on it, if you must. It’s better to refresh your skills while employed, on a system and codebase you’re familiar with, than to find yourself struggling to brush up enough to pass a coding interview.

Engineering fluency == job security

There is one more reason to refresh your engineering skills from time to time, one I don’t often see mentioned, and that is job security and optionality.

The higher you go up the ladder, the more money you will get paid…but the fewer jobs there be, and the fewer still that match your profile.

As a senior software engineer, there are fifteen bajillion job openings for you. Everyone wants to hire you. You can get a new job in a matter of days, no matter how picky you want to be about location, flexibility, technologies, product types, whatever. You’ve reached Peak Hire.

If you are looking for management roles, there will be an order of magnitude fewer opportunities (and more idiosyncratic hiring criteria), but still plenty for the most part. But for every step up the ladder you go, the opportunities drop by another order of magnitude, and the scrutiny becomes much more intense and particular. If you’re looking for VP roles, it may take months to find a place you want to work at, and then they might not choose you. ¯\_(ツ)_/¯

Maintaining your technical chops is a stellar way to hedge against uncertainties and maintain your optionality.

 

Twin Anxieties of the Engineer/Manager Pendulum

How can you tell if the company you’re interviewing with is rotten on the inside?

How can you tell the companies who are earnestly trying to improve apart from the ones who sound all polished and healthy from the outside, whilst rotting on the inside?

This seems to be on a lot of minds right now, what with the Great Resignation and all. There are no perfect companies, just like there are no perfect relationships; but there are many questions and techniques you can use to increase your confidence that a particular company is decent and self-aware, one whose quirks and foibles you are compatible with.

Interviews are designed to make you feel like you are under inspection, like the interviewer holds all the power. This is an illusion. Your labor is valuable — it is vital — and you should be scrutinizing them every bit as closely as they you. In fact, here is Tip #1:

  • If they allow you plenty of time to converse with your interviewers throughout the process, great. If they tack on a cursory “any questions for us?” while wrapping up, they don’t think it matters what you think of them. Pull the ripcord.

Collect and practice good interview questions for you to ask potential employers. Write them down — your mind is likely to go blank under stress, and you don’t want to let them off the hook. There is a LOT of signal to be gained by probing down below the surface answers.

Backchanneling

  1. Whisper networks and backchannels are incredibly important. It can be especially valuable to talk to someone who has recently left the company: why did they leave? Would they go there again?
  2. Alternately, do you know anyone who has worked for or with their leadership, even if not at that company?
  3. If you know any women or under-represented minorities (URM) who work there, buy them lunch and ask for the unvarnished truth. That’s where you usually turn up the real dirt. 🥂

Diversity, equity and inclusion

Just because a company has a diverse workforce doesn’t necessarily mean it is a healthy place to work. (But it’s fair to give some points up front, because that doesn’t usually happen by accident.)

  1. Do they have a diverse leadership team? A diverse board?
  2. Is their company diverse overall, or are minorities concentrated in a few (lower-paying, high-turnover) departments?
  3. You might not want to write off all the companies that don’t meet points one and two, if for no other reason than it dramatically shrinks your available option pool. If they don’t have a particularly diverse team, and this is something that matters to you, that’s your cue to dig deeper:
    • Are they bothered by their lack of diversity? What’s the plan? Do they just feel generically sad about it, or have they set specific goals to improve by specific dates? What investments are they making?
    • Who works on DEI stuff currently? (Answers like “HR and recruiting”, or “we have a woman who’s really good at it” are bad answers.)
    • Who is accountable for making sure those goals are hit? (The only right answer is “our execs”. Having a “chief diversity officer” is an anti-pattern in my book.)
    • If the team is all guys, for example, ask if they’ve ever had any women on the team in the past. Did she/they leave? Do they know why?
  4. This is a GREAT one: “As a white man, I’d ask what they’ve done to find qualified women and minorities for the role I’m interviewing for.” (via David Daly) 🔥🔥

Company stuff

  1. What are their values? Do they feel bloodless and ripped from the pages of HBR, or are they unique, lived-in, and give you a glimpse of what the people there care about? Are they mentioned over the course of your interview?
  2. Ask tough questions about the business and try to ascertain whether they are hitting their quarterly goals, how much funding they have in the bank, what the growth curve looks like, what users really think about their product, and what the biggest obstacles to success are.
    • Companies that are floundering are going to be really stressful places to work, and even if the leadership is decent, they may find themselves backed into making some really tough decisions.
    • You want to work at a company on a strong growth trajectory for lots of reasons, but a big one is your own growth potential. You will learn the most the fastest at places that are growing fast, and have way more openings for promotions and leadership roles than a slower-growing company.
  3. Are people willing to speak freely about things they’ve tried that have failed, and things that don’t work well currently? Being self-aware and comfortable with visible failure are two of the most important self-correcting mechanisms a company can cultivate.
  4. EVERYBODY thinks they value transparency, so I wouldn’t even bother asking. Instead, ask for specific examples of leadership being forthcoming with bad news to the team, and team members delivering hard feedback or bad news to upper leadership. Transparency shouldn’t be something they’re especially proud of, so much as it is taken for granted. It’s in the air that you breathe.

Planning and the unplanned

  1. Ask about how decisions get made. A chestnut is, “how does work end up on my plate?” — meaning is there a business strategy (owned by whom?), a technical strategy, a product strategy, quarterly KPIs, customer requests, manager delegation, JIRA tickets…? (The most important part may be how similar the answers you get are. 🙃)
  2. How often does work get pre-empted and why? It’s a good thing if product development has to get put on ice once in a while so the team can focus on reliability and maintenance work. It’s a bad thing if they’re expected to stuff reliability work in the cracks around their product development, or if they’re incapable of sticking to a plan.
  3. What does “crunch time” look like? Nearly every company has one from time to time (it might even be a bad sign if it never happens), but this is when you find out your leadership’s true colors.
    • Do they praise people or call them out to thank them for pulling all nighters and other extremist behaviors? 🚨BZZT🚨
    • Is it voluntary? Are you trusted to set your own pace, your own limits, or are you pressured to do more? Are people expected to participate to the extent that they are able, and not expected to justify how hard or how much (so long as they communicate their capacity, of course)?
    • How long did it last, and how often does it happen, and why? It should be rare (1-2x/year at most), involve the whole company, and move the business forward meaningfully
    • Did they follow through by making sure people took time off afterwards to recover? Not just give permission, but actually make sure the human beings had a chance to refresh themselves? Did leaders set a good example by taking a breather themselves?

Believe it or not, crunch time done correctly can be an enormously exciting, intense, bonding time for a group of people who love what they do, culminating in a surge of collective triumph and celebration, followed by recovery time. If it was done correctly, and you ask about it afterwards, people will 💡light up💡.

Team stuff

  1. Unfortunately, culture can vary widely from function to function, even from manager to manager. Make sure you get a real interview slot with your actual manager — not just a screener or wrap-up call — and as much of the team as possible, too.
  2. Ask your potential manager about the last person they had to let go. Why? What was the process? What was the impact on the team? How did the person feel afterwards?
  3. Who is on call? How often do people get paged outside of hours, and how frequently do they work an incident? (Do managers track this?) Are you expected to keep shipping product during on call weeks, or devote your time to making the system better?
  4. If you had to ship a single line of code to production using the deploy pipeline, how long would that take? Remember, the lower the deploy interval, the happier and more productive you are likely to be as an engineer there. Under 15 minutes is great. Under an hour is tolerable. More than that, proceed with great caution.

The interview itself

  1. Was your interview well-organized and conducted in a timely fashion? Were you given detailed information about what to expect, and were your interviewers well-prepared, and conversational? Were the questions fair, open-ended, and relevant to the job in question?
  2. If they asked you to perform any kind of take-home labor of more than an hour or so, did they compensate you for your time?
  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?
  4. Did you find the questions interesting and challenging? Do they have a clear idea of what success looks like for you in this role? Did you leave excited and buzzing with ideas about the work you could do together?
    • This is 👆 definitely more of a “how good is this job” question than “is this a shithole” question, but one of our honeycombers brought it up as an example of how a great interview can make you decide to leave a job , even one you’re perfectly happy with.
  5. The questions they ask you while interviewing you are the questions they ask everyone else. So…did they ask you about your views on diversity and team dynamics while interviewing you? Or is that not part of their filters, only their advertised persona?

Three more

  1. Do their employees seem to speak freely on twitter? If you are an agitator of sorts, are there others who agitate about similar issues — either with company support, or at least lack of censorship?
  2. How does the company respond to criticism and feedback? For that matter, how do they treat their competitors? Being competitive is fine, being mean is not.
  3. Get clear on your own expectations. What’s on your wishlist, and what’s make-or-break for you? If something is very important to you, consider telling the hiring manager up front. For example, “These are my expectations for how women are treated. How do you think your company matches up?” Their answers will speak volumes, and so will their comfort level with the question.

In closing

If you a join a new company, and two or three weeks in you’re just not feeling it, you’re wondering if you made a mistake — leave. You do not owe them a year of your life. Trust your instincts. Just leave it off your resume entirely and roll the dice again.

Employers are all too accustomed to feeling (and acting) like they hold all the power. They do not. Every tech company is a talent business, which rises and falls on the caliber of the people they can convince to stay. They aren’t doing you a favor by employing you; you are doing THEM a favor by lending them your creativity, labor, and a third of the hours in your day.

Do they deserve it? Will their success make the world a better place? If not, stop supporting them with your work and lend your muscle to a company that deserves it.

In the hottest job market of my lifetime, with millions of opportunities newly open to people who live literally anywhere, you owe it to yourself, your future self, and your family to take a good hard look at where you sit. 🍄 Are you happy? 🍄 Are you compensated well, is your time valued? 🍄 Are you still learning new things and improving your skills every day? 🍄 Is your company still on a growth trajectory? 🍄 Do you trust your leadership and your team, 🍄 do still you believe in the mission, and 🍄 do you think your labor contributes meaningfully to making the world a better place?

If not, consider joining the Great Resignation. I hear they have cookies.

Huge thanks to Amy Davis, Phillip Carter, Ian Smith, Sarah Voegeli, Kent Quirk, Liz Fong-Jones, Amanda Shapiro, Nick Rycar, Fred Hebert and David Daly, all of whom contributed to this post!

How can you tell if the company you’re interviewing with is rotten on the inside?

How “Engineering-Driven” Leads to “Engineering-Supremacy”

Honeycomb has a reputation for being a very engineering-driven company. No surprise there, since it was founded by two engineers and our mission involves building an engineering product for other engineers.

We are never going to stop being engineering-driven in the sense that we are building for engineers and we always want engineers to have a seat at the table when it comes to what we build, and how, and why. But I am increasingly uncomfortable with the term “engineering-driven” and the asymmetry it implies.

We are less and less engineering-driven nowadays, for entirely good reasons — we want this to be just as much of a design-driven company and a product-driven company, and I would never want sales or marketing to feel like anything other than equal partners in our journey towards revolutionizing the way the world builds and runs code in production.

It is true that most honeycomb employees were engineers for the first few years, and our culture felt very engineer-centric. Other orgs were maybe comprised of a person or two, or had engineers trying to play them on TV, or just felt highly experimental.

But if there is one thing Christine and I were crystal clear on from the beginning, it’s this:

✨WE ARE HERE TO BUILD A BUSINESS✨

Not just the shiniest, most hardcore tech, not just the happiest, most diverse teams. These things matter to us — they matter a lot! But succeeding at business is what gives us the power to change the world in all of these other ways we care about changing it.

If business is booming and people are thirsty for more of whatever it is you’re serving, you pretty much get a blank check for radical experiments in sociotechnical transformation, be that libertarian or communitarian or anything in between.

If you don’t have the business to back it up, you get fuck-all.

Not only do you not get shit, you risk being pointed out as a Cautionary Tale of “what happens if $(thing you deeply care about) comes true.” Sit on THAT for a hot second. 😕

So yes, we cared. Which is not to say we knew how to build a great business. We most certainly did not. But both of us had been through too many startups (Linden Lab, Aardvark, Parse, etc) where the tech was amazing, the people were amazing, the product was amazing … and the business side just did not keep up. Which always leads to the same thing: heartbreak and devastation.

✨IF you can’t make it profitable✨
✨your destiny will inevitably be✨
✨taken out of your hands✨
✨and given to someone else.✨

So Christine and I have been repeating these twin facts back and forth to each other for over six years now:

  1. Honeycomb must succeed as a revenue-generating, eventually profitable business.
  2. We are not business experts. Therefore we have to make Honeycomb a place that explicitly values business expertise, that places it on the same level as engineering expertise.

We have worked hard to get better at understanding the business side (her more than me 🙃) but ultimately, we cannot be the domain experts in marketing or sales (or customer success, support, etc).

What we could do is demonstrate respect for those functions, bake that respect into our culture, and hire and support amazing business talent to run them with us.

On being “engineering-driven”

Self-described “engineering-driven” companies tend to fall into one of two traps. Either they alienate the business side by pinching their nose and holding business development at arm’s length (“aaahhh, i’m just an engineer! I have no interest in or capacity for participating in developing our marketing voice or sales pitch decks, get off me!”), or they act like engineering is a sort of super-skillset that makes you capable of doing everybody else’s job better than they possibly could. As though those other disciplines and skill sets aren’t every bit as deep and creative and challenging in their own right as developing software can be.

For the first few years we really did use engineers for all of those functions. We were trying to figure out how to build and explain and sell something new, which meant working out these things on the ground every day with our users. Engineer to engineer. What resonated? What clicked? What worked?

So we hired just a few engineers who were interested in how the business worked, and who were willing to work like Swiss Army knives across the org. We didn’t yet have a workable plan in place, which is what you need in order to bring domain experts on board, point them in a direction, and trust them to do what they do best in executing that plan.

Like I said, we didn’t know what to do or how to do it. But at least we knew that. Which kept us humble. And translated into a hard, fast rule which we set early on in our hiring process:

We DO NOT hire engineers who talk shit about sales and marketing.

If I was interviewing an engineer and they made any alienating sort of comment whatsoever about their counterparts on the business side, it was an automatic no. Easy out. We had a zero tolerance policy for talking down down about other functions, or joking, even for being unwilling to perform other business functions.

In retrospect, I think this is one of the best decisions we ever made.

Hiring engineers who respected other functions

We leaned hard into hiring engineers who asked curious questions about our business strategy and execution. We pursued engineers who talked about wanting to spend time directly with users, who were intrigued by the idea of writing marketing copy to help explain concepts to engineers, and who were ready, willing and able to go along on sales calls.

Once we finally found product-market fit, about 2-3 years ago, we stopped using engineers to play other roles and started hiring actual professionals in product, design, marketing, sales, customer success, etc to build and staff out their organizations. That was when we first started building the business for the longer term; until we found PMF, our event horizon was never more than 1-3 months ahead of “right now”.

(I’ll never forget going out to coffee with one of our earlier VPs of marketing, shortly after she was hired, and having her ask, in bemusement: “Why are all these engineers just sitting around in the #marketing channel? I’ve never had so many people giving opinions on my work!” 🙃)

Those early Swiss Army knife engineers have since stepped back, gratefully, into roles more centered around engineering. But that early knee-jerk reaction of ours established an important company norm that pays dividends to this day.

Every function of the business is equally challenging, creative, and worthy of respect. None of us are here to peacock; our skill sets serve the primary business goals. We all do our jobs better when we know more about how each other’s functions work.

These days, it’s not just about making sure we hire engineers who treat business counterparts like equals. It’s more about finding ways to stimulate the flow of information cross-functionally, creating a hunger for this information.

Caring about the big picture is a ✨learnable skill✨

You can try to hire people who care about the overall business outcomes, not just their own corner of reality, and we do select for this to  some degree — for all roles, not just engineers.

But you can also foster this curiosity and teach people to seek it out. Curiosity begets curiosity, and every single person at Honeycomb is doing something interesting. We all want to succeed and win together, and there’s something infectious and exciting about connecting all the dots that lead to success and reflecting that story back to the rest of the company.

For example,

  1. Every time we close a deal, a post gets written up and dropped into the announcements slack by the sales team. Not just who did we close and how much money did we make, but the full story of that customer’s interaction with honeycomb. How did they hear of us? Whose blog posts, training sessions, or office hours did they engage with? Did someone on the telemetry pull a record-fast turnaround on an integration they needed to get going? What pains did we solve effectively for them as a tool, and where were the rough edges that we can improve on in the future?

    The story is often half a page long or more, and tags a dozen or more people throughout all parts of the company, showing how everyone’s hard work added up and materially contributed to the final result.
  2. We have orgs take turn presenting in all hands — where they’re at, what they’ve built, and the impact of their contributions, week after week. Whether that’s the design team talking about how they’ve rolled out our new design system and how it is going to help everyone in the company experiment more and move more quickly, or it’s the people team showing how they’ve improved our recruiting, interviewing, and hiring processes to make people feel more seen, welcomed, and appreciated throughout the process.

    We expect people to be curious about the rest of the company. We expect honeybees to be interested in, excited about and celebratory of each other’s hard work. And it’s easy to be excited when you see people showing off work that they were excited to do.
  3. We have a weekly Friday “demo day” where people come and show off something they’ve built this week, rapid-fire. Whether it’s connecting to a mysql shell in the terminal to show off our newly consistent permissioning scheme, or product marketing showing off new work on the website. Everybody’s work counts. Everybody wants to see it.
  4. We have a #love channel in slack where you can drop in and tag someone when you’re feeling thankful for how much they just made your day better. We also have a “Gratefuls” section during all hands, where people speak up and give verbal props to coworkers who have really made a difference in their lives at work.

We have always attracted engineers who care about the business, not just the technology and the culture. As a result, we have consistently recruited and retained business leaders who are well above our weight class — our investors still sometimes marvel at the caliber of the business talent we have been able to attract. It is way above the norm for developer tools companies like ours.

“Engineering-driven” can be a mask for “engineering-supremacy”

Because the sad truth is that so many companies who pride themselves on being “engineering-driven” are actually what I would call more “engineering-supremacist”. Ask any top-tier sales or marketing leader out there about their experiences in the tech industry and you’ll hear a painful, rage-inducing list of times they were talked down to by technical founders, had their counsel blown off or overridden, had their plans scrapped and their budgets cut, and every other sort of disrespectful act you can imagine.

(I am aware that the opposite also exists; that there are companies and cultures out there that valorize and glorify sales or marketing while treating engineers like code monkeys and button pushers, but it’s less common around here. In neither direction is this okay.)

This isn’t good for business, and it isn’t good for people.

It is still true that engineering is the most mature and developed organization at the company, because it has been around the longest. But our other orgs are starting to catch up and figure out what it means to “be honeycomby” for them, on their own terms. How do our core values apply to the sales team, the developer evangelists, the marketing folks, the product people? We are starting to see this play out in real time, and it’s fascinating. It is better than forcing all teams to be “engineering-driven”.

Business success is what makes all things possible

We are known for the caliber of our engineering today. But none of that matters a whit if you never hear about us, or can’t buy us in a way that makes sense for you and your team, or if you can’t use the product, or if we don’t keep building the right things, the things you need to modernize your engineering teams and move into the future together.

When looking towards that future, I still want us to be known for our great engineering. But I also want us to be a magnet for great designers who trust that they can come here and be respected, for great product people who know they can come here and do the best work of their life. That won’t happen if we see ourselves as being “driven” by one third of the triad.

Supremacy destroys balance. Always.

And none of this, none of this works unless we have a surging, thriving business to keep the wind in our sails.

~charity

How “Engineering-Driven” Leads to “Engineering-Supremacy”

Why I hate the phrase “breaking down silos”

We hear this phrase constantly: “I worked at breaking down silos.” “We need to break down silos.” “What did I do in my last role? I broke down silos.”

It sets my fucking teeth on edge.

What is a ‘silo’, anyway? What specifically wasn’t working well, and how did you solve it; or how was it solved, and what was your contribution to the solution? did you just follow orders, or did you personally diagnose the problem, or did some of your suggestions pan out?

Solutions to complex problems rarely work on the first go, so … what else did you try? How did you know it wasn’t working, how did you know when to abandon earlier ideas? It’s fiendishly hard to know whether you’ve given a solution enough time to bake, for people to adjust, so that you can even evaluate whether it works better or worse off than before.

Communication is not magic pixie dust

Breaking down silos is supposed to be about increasing communication, removing barriers and roadblocks to collaboration.

But you can’t just blindly throw “more communication” at your teams. Too much communication can be just as much of a problem and aSo they say we work in silos... 6 mos later...So they say we still work in  silos - Willy Wonka | Meme Generator burden as too little. It can distract, and confuse, and create little eddies of information that is incorrect or harmful.

The quantity of the communication isn’t the issue, so much as the quality. Who is talking to whom, and when, and why? How does information flow throughout your company? Who gets left out? Whose input is sought, and when, and why? How can any given individual figure out who to talk to about any given responsibility?

Every time you say "break down silos", I want to "break down your face." |  News EcardWhen someone says they are “breaking down silos”, whether in an interview, a panel, or casual conversation, it tells me jack shit about what they actually did.

cliches are a substitute for critical thinking

It’s just like when people say “it’s a culture problem”, or “fix your culture”, or “everything is about people”. These phrases tell me nothing except that the speaker has gone to a lot of conferences and wants to to sound cool.

If someone says “breaking down silos”, it immediately generates a zillion questions in my mind. I’m curious, because these problems are genuinely hard and people who solve them are incredibly rare.

Unfortunately, the people who use these phrases are almost never the ones who are out there in the muck and grind, struggling to solve real problems.

When asked, people who have done the hard labor of building better organizations with healthy communication flows, less inefficiency, and alignment around a single mission — people who have gotten all the people rowing in the same direction — tend to talk about the work.

People who haven’t, say they were “breaking down silos.”

If you just work in your silo That would be great - Yeah If You Could Just  | Meme Generator

Why I hate the phrase “breaking down silos”

Why every software engineering interview should include ops questions

I’ve fallen way behind on my blog posts — my goal was to write one per month, and I haven’t published anything since MAY. Egads. So here I am dipping into the drafts archives! This one was written in April of 2016, when I was noodling over my CraftConf 2016 talk on “DevOps for Developers (see slides).”

So I got to the part in my talk where I’m talking about how to interview and hire software engineers who aren’t going to burn the fucking house down, and realized I could spend a solid hour on that question alone. That’s why I decided to turn it into a blog post instead.

Stop telling ops people to code better, start telling SWEs to ops better

Our industry has gotten very good at pressing operations engineers to get better at writing code, writing tests, and software engineering in general these past few years. Which is great! But we have not been nearly so good at pushing software engineers to level up their systems skills. Which is unfortunate, because it is just as important.

Most systems suffer from the syndrome of running too much software. Tossing more software into the heap is as likely to cause more problems as often as it solves them.

We see this play out at companies stacked with good software engineers who have built horrifying spaghetti messes of their infrastructure, and then commence paging themselves to death.

The only way to unwind this is to reset expectations, and make it clear that

  1. you are still responsible for your code after it’s been deployed to production, and 
  2. operational excellence is everyone’s job.

Operations is the constellation of tools, practices, policies, habits, and docs around shipping value to users, and every single one of us needs to participate in order to do this swiftly and safely.

Every software engineering interviewing loop should have an ops component.

Nobody interviews candidates for SRE or ops nowadays without asking some coding questions. You don’t have to be the greatest programmer in the world, but you can’t be functionally illiterate. The reverse is less common: asking software engineers basic, stupid questions about the lifecycle of their code, instrumentation best practices, etc. 

It’s common practice at lots of companies now to have a software engineer in the loop for hiring SREs to evaluate their coding abilities. It should be just as common to have an ops engineer in the loop for a SWE hire, especially for any SWE who is being considered for a key senior position. Those are the people you most rely on to be mentors and role models for junior hires. All engineers should embrace the ethos of owning their code in production, and nobody should be promoted or hired into a senior role if they don’t.

And yes, that means all engineers!  Even your iOS/Android engineers and website developers should be interested in what happens to their code after they hit deploy.  They should care about things like instrumentation, and what kind of data they may need later to debug their problems, and how their features may impact other infrastructure components.

You need to balance out your software engineers with engineers who don’t react to every problem by writing more code. You need engineers who write code begrudgingly, as a last resort. You’ll find these priceless gems in ops and SRE.

ops questions for software engineers

The best questions are broad and start off easy, with plenty of reasonable answers and pathways to explore. Even beginners can give a reasonable answer, while experts can go on talking for hours.

For example: give them the specs for a new feature, and ask them to talk through the infrastructure choices and dependencies to support that feature. Do they ask about things like which languages, databases, and frameworks are already supported by the team? Do they understand what kind of monitoring and observability tools to use, do they ask about local instrumentation best practices?

Or design a full deployment pipeline together. Probe what they know about generating artifacts, versioning, rollbacks, branching vs master, canarying, rolling restarts, green/blue deploys, etc. How might they design a deploy tool? Talk through the tradeoffs.

Some other good starting points:

  • “Tell me about the last time you caused a production outage. What happened, how did you find out, how was it resolved, and what did you learn?”
  • “What are some of your favorite tools for visibility, instrumentation, and debugging?
  • “Latency seems to have doubled over the last 6 hours. Where do you start looking, how do you start debugging?”
  • And this chestnut: “What happens when you type ‘google.com’ into a web browser?” You would be fucking *astonished* how many senior software engineers don’t know a thing about DNS, HTTP, SSL/TLS, cookies, TCP/IP, routing, load balancers, web servers, proxies, and on and on.

Another question I really like is: “what’s your favorite API (or database, or language) and why?” followed up by “… and what are the worst things about it?” (True love doesn’t mean blind worship.)

Remember, you’re exploring someone’s experience and depth here, not giving them a pass-fail quiz. It’s okay if they don’t know it all. You’re also evaluating them on communication skills, which is severely underrated by most people but is actually as a key technical skill.

Signals to look for

You’re not looking for perfection. You are teasing out signals for things like, how will this person perform on a team where software engineers are expected to own their code? How much do they know about the world outside the code they write themselves? Are they curious, eager, and willing to learn, or fearful, incurious and begrudging?

Do they expect networks to be reliable? Do they expect databases to respond, retries to succeed? Are they offended by the idea of being on call? Are they overly clever or do they look to simplify? (God, I hate clever software engineers 🙃.)

It’s valuable to get a feel for an engineer’s operational chops, but let’s be clear, you’re doing this for one big reason: to set expectations. By making ops questions part of the interview, you’re establishing from the start that you run an org where operations is valued, where ownership is non-optional. This is not an ivory tower where software engineers can merrily git push and go home for the day and let other people handle the fallout

It can be toxic when you have an engineer who thinks all ops work is toil and operations engineering is lesser-than. It tends to result in operations work being done very poorly. This is your best chance to let those people self-select out.

You know what, I’m actually feeling uncharacteristically optimistic right now. I’m remembering how controversial some of this stuff was when I first wrote it, five years ago in 2016. Nowadays it just sounds obvious. Like table stakes.

Hell yeah. 🤘

Why every software engineering interview should include ops questions

Questionable Advice: “What Should I Say In My Exit Interview?”

I recently received this gem of a note::

Hi Charity, I really enjoy your writing and a lot of it has directly contributed to me finally deciding to leave a company with a toxic management culture. I’ll also be leaving many great IC friends that will have lost a strong voice.

My exit interview will be next week. Any advice on how honest I should be?

I’ve googled quite a bit but there are only generic “don’t burn bridges” comments. Would love to see something a little more authoritative 🙂

–Anonymous Reader

Ew, fuck that. That’s exactly the kind of quivering, self-serving, ass covering advice you’d get from HR. It’s exactly the kind of advice that good people use to perpetuate harm.

I wouldn’t worry about “too much honesty” or personal repercussions or whatnot. I would worry about just one thing: being effective. This is your last chance to do the people you care about a solid, and you don’t want to waste it.

So … ranting about every awful person, boring project and offensive party theme of your tenure: not effective. Ranting about people who were personally irritating but had very limited power: not effective. Talking only in vague, high level abstractions (“toxic culture”), or about things only engineers understand and are bugged by: not effective.

What is effective? Hm, let’s think on this..

  • Start off with your high level assertion (toxic culture) and methodically assemble a list of stories, incidents, and consequences that support your thesis. Structure-wise, this is a lot like writing a good essay
  • Tie your critiques to the higher ups who enabled or encouraged the bad behavior, not just the flunkies who carried it out.
  • Wherever possible, draw a straight line to material consequences — people quitting, customers leaving, your company’s reputation suffering
  • Keep it crisp. No more than three pages total. Pick your top 1-3 points and drive them home. No detours.
  • This one sucks, but … if someone was perceived as an underperformer or a problem employee, avoid using them as evidence in support of your argument. It won’t help you or them, it will be used as an excuse to discredit you.
  • Keep it mostly professional. I am not saying don’t show any anger or strong emotion; it can be a powerful tool; just be careful with it. Get a proofread from someone with upper management experience, ideally with no connection to your work. (Me, if necessary.)
  • Put it in WRITING!✨ Deliver your feedback in person, but hand over a written copy as well. Written words are harder to ignore or distort.
  • For extra oomph, give a copy to any execs, managers, or high level ICs you trust. Don’t just email it to them, though. Have a face to face conversation where you state your case, and hand them a written copy at the end.

The sad fact is that most exit feedback is dutifully entered in by a low ranking employee who makes a third your salary and has no reason whatsoever to rock the boat, after which it gets tossed in a folder or the trash and is never seen again.

If you want to use your voice on your way out the door, the challenge you face isn’t one of retribution, it’s inertia and apathy. HR doesn’t care about your feedback … but they care if they think their boss saw it and cares about it

And I think you should use your voice! You clearly have some clout, and what’s the point of having power if you won’t extend yourself now and then on behalf of those who don’t?

Good luck!!

charity

Questionable Advice: “What Should I Say In My Exit Interview?”

Know your “One Job”, continued

Holy macaroni batman, I was not expecting that post to ignite a shitstorm. It felt like a pretty straightforward observation: you were hired to do a job, you should do your best to do that job.

Interestingly, the response was almost universally positive for the first 8 hours or so. But then the tide began to turn as the 🔥hot takes🔥 began rolling in (oh god 🙈) and then began pingponging off each other, competing for and amplifying each other’s outrage. 😕You Had One Job | Know Your Meme

When something touches a nerve like this, it swiftly becomes less about your actual words and more of a public event, or maybe a Teachable Moment. (🤮) Everybody has to weigh in with their commentary, and while it’s not super fun to be on the receiving end, I have mostly learned to distinguish the general pile-on from the few engaging in bad faith. I just keep telling myself that public discourse is how we create shared consensus and shift the Overton window and industry norms. So that’s all fair game, it’s done in good faith and it’s the price of change. I can take a few days of shitty twitter mentions for the team, lol.

The one comment that did worm under my skin was a woman who said she believed my post would give an abusive former boss ammo to use against people like her in the future. And that, more than all the hatertomatoade, is why I wrote this epic followup.

Two responses i’d like to foreground

First, I’d like to link to something Terra said about the importance of ERGs for marginalized workers, especially during times of duress.

Thanks Terra, I stand corrected — I can totally see how that work counts as part of one’s core job, and managers should understand this and define it as such.

I still don’t think it means you promote someone purely on the basis of that work; I don’t see how you can promote someone up an engineering ladder until they can fulfill the technical FAIL Nation - ocd - Vintage FAILs of the Epic Variety - Cheezburgerrequirements of the next level. It could certainly mean expanding the core requirements of your role to include your ERG labor, though perhaps not replacing the technical work entirely (over the long term).

This goes both ways, fwiw. Nobody should be promoted without doing their fair share of the emotional labor and glue work it takes to keep the company going. A successful career in sociotechnical systems means leveling up your social repertoire as well as your technical skills. Your job descriptions and levels must reflect this, spelling out both the social and the technical requirements at each level.

🔥🔥🔥Tip of the Day🔥🔥🔥

If you want to know what your company REALLY cares about, take a management gig for a while and listen closely to the debates over whether or not to promote someone to the post-senior levels, and why or why not. You are LITERALLY witnessing as your organization decides, over and over, what it values the most, what it wants to reward, whose footsteps they want you to follow in, and where to spend its scarcest, most inelastic resource: staff and principal engineering titles. Fascinating shit.

Secondly, please go and read Shelby’s excellent thread, written from the perspective of someone who has been “Susan” for a number of reasons.

 

These situations are complicated, and managers should always, always try to listen and understand the subtleties of each unique situation before coming to some mutual understanding with their team member about what the core responsibilities of the job are. Jobs are living documents, and it doesn’t hurt to revisit them and clarify from time to time. <3

Objection: “Nobody has Just One Job”

Completely true. I was trying to be funny by referring to the “You had one job!” meme. I apologize. Yes, everybody has a basket of responsibilities. I DO think that a well-written job description and clarification on the priorities of the job is a good thing, and will go a long way towards helping you figure out how to spend your time and how to not get burned out.

Also: am I prone to hyperbole? Yes ma’am, sweeping statements are LITERALLY ALL I DO. (Sorry ☺️)

You Had One Job - The Rhetoric of MemesFTR, I don’t think your core responsibilities should be overwhelming, and there should be plenty of time in your normal 40 hour work week to devote to so-called electives and extracurriculars. I’ve said many times that I don’t believe anyone has more than four hours a day of real, focused, challenging engineering labor in them. So maybe 15-20 hours/week of moving the business forward in your areas of ownership?

Everyone should have cycles free for participating in the “squishy” parts of work. It’s an important part of taking a group of random individuals and connecting them with meaning and a sense of mission. That isn’t HR’s job, or the managers or execs’ jobs, that is everyone’s job, the more the better. Everyone should have flexibility, autonomy, and variety in their schedule, and should feel supported in using work hours to support their peers. Nothing I am saying contradicts any of that. But sometimes something’s gotta give, and usually your core responsbilities are not what you want to sacrifice.

Objection: “Interviewing isn’t optional”

Sure. But you weren’t hired to interview. It’s just part of the basket of secondary responsibilities that come along with being a member of the team. If you’re an engineer, you likely weren’t hired to write blog posts or mentor folks — unless you were! were you?? — which makes them similarly in the bucket marked “valuable, but secondary”. Honestly it could be on purpose though, it could just be words in another language. - Imgflip

We aren’t talking about “steady state”, we’re talking about what to do when you aren’t able to fulfill the core functions of your job. This should be a temporary state of emergency, not the status quo. When you’re overwhelmed, it’s totally normal to ask to be excused from the interviewing rotation for a quarter or so, or any of your other secondary responsibilities.

Objection: “How dare you not promote someone who is getting good peer reviews”

I said she was getting some compliments and rave reviews. If you’re getting compliments from HR, marketing, and other people sprinkled across the company, but you aren’t You Had One Job by clairvoyant - Meme Centerdelivering for your own team; if you’re holding back core initiatives for your closest peers, then you aren’t doing your work in the right order.

I’ve seen this happen when an engineer’s public persona becomes more important to them than their actual work. When they get hooked on the public adulation of giving talks and writing posts and going to conferences, meanwhile their output at work drops off a cliff. This isn’t fair to your coworkers. Maybe you don’t want to do this job anymore, maybe you want a job where your core responsibilities are writing and speaking. I don’t know. All I know is that if I’m the manager of that team, my responsibility and loyalty is to the well-functioning of that team, so we need to have a conversation and clarify what’s happening.

Again, all I am saying is that your commitments to your immediate team come first. Not following through affects way more than just you.

Objection: “You are hating on / devaluing glue work”

I really wish I had thought to link to Tanya Reilly’s invaluable material on glue work in my original post, but I didn’t connect those dots, sadly. Yes, it can be hard for engineering managers to recognize or reward glue work, and yes, glue work is an invaluable form of technical leadership. I don’t have a lot to say about this other than I completely agree, and it is not what I am talking about.

Objection: “All these extra-curriculars should count towards promotions”

Well, yes! Duh! I am all for promoting people not based on raw individual coding output, but on overall impact. People who perform a lot of glue work are invaluable to any high functioning team, and people who run internal ERGs, do lots of DEI work, etc — that SHOULD factor into promotions. In my original post I said that sadly, when someone isn’t performing the key parts of their job, you don’t get credit for these wonderful positives — they are not enough on their own (unless of course you have an understanding with your manager that your core responsibilities have changed), and can even be evidence of time mismanagement or an inability to prioritize.

you had one job Keep trying - Paranoia meme | Make a MemeI cannot honestly understand why this is controversial. If you were hired as a database engineer, and you spent the year doing mostly DEI work, how does it make sense to promote you to the next level as a database engineer? That’s not setting you up for success at the next level at ALL. If this was agreed upon by you and your manager, I can see giving you glowing reviews for the period of time spent on DEI work, as long as your dbeng responsibilities were gracefully handed off to someone else (and not just dropped), but not promoting you for it.

However, if you ARE competently performing your core responsibilities as a database engineer, and are performing them at the next level, then all your additional work for the company — on DEI, ERGs, mentoring, interviewing, etc — adds up to a MASSIVELY compelling body of work, and a powerful argument for promotion. It certainly ought to be enough to push you over the edge if you are on the bubble for the next level..

Objection: “You hate DEI work and demean those who do it”

It does not make me anti-DEI work to point out that you were hired to do a certain job, first and foremost. If you want your first-and-foremost job to be DEI work, that’s great! Go get that job! If you want your first-and-foremost job to be engineering, but then not do that job, I … guess I just fail to see how this is a logically defensible position.

As someone else put it: “Your One Job is the cake, the rest is the icing”.//TODO citation You can often negotiate a job that has a LOT of icing — but you should negotiate, no surprises. DEI work is absolutely valuable to companies, because having a diverse workforce is a competitive advantage and increasingly a hiring advantage. But that work isn’t typically budgeted under engineering, it comes from G&A

I can also understand why you might want to keep the (unfortunately higher) engineering salary and the (unfortunately higher) social status you have with an engineering role, even if engineering no longer feeds your soul the way doing diversity work does. I know people in this situation, and it’s tricky. 😕 There is no single right or wrong answer, just a question of whether you can find an employer who is willing to pay for that configuration. But I should think clarity and straightforwardness is more important than ever when your heart’s desire is unconventional.

Objection: “You’re letting managers off the hook. This is entirely a management failure.”

You might be right. This is often a consequence of negligent, unclear, or biased management. But not always. I’ve also seen it happen — close up — with engaged, empathetic, highly skilled You Only Had One Job on Twitter: "Whoever wrote this, probably never saw a sign like this when he/she was a kid #youonlyhadonejob #youonlyhad1job https://t.co/BGLHCWwtGo"managers who were good at setting structure and boundaries, deeply encouraging, gave tons of chances and great constant feedback, tried every which way to make it work … and the employee just wasn’t interested. They volunteered for every social committee and followed every butterfly that fluttered by. They just weren’t into the work.

YES, managers should be keeping close tabs on their reports and giving constant feedback. YES, it’s on the manager to make sure the role is clearly defined.

YES, managers should be clear with employees on what the promotion path is, and YES, no review should ever be a surprise.

YES, if people all over the org are heaping requests or responsibilities on the Susans of the world, it can be difficult to prioritize and it is not fair to expect them to juggle those requests, the manager should help to shelter them from it. Yes yes yes. We are all on the same page.You had one job! – inkbiotic

But I am writing this post, not to managers, but to engineers, people like me, who are confused about why they aren’t getting promoted and others are. I am writing this post because good managers are in scarce supply, and I don’t want your career to be on hold until you happen to get a good one. I am trying to provide a peek behind the curtain into something that frustrates managers and holds a lot of people back, so that you can take matters into your own hand and try to fix it. If your manager hasn’t been clear with you on what your core job is, they suck and I’m sorry.

Is any of this your fault? Maybe, maybe not. But it is something you have some control over. You can at least open the conversation and ask for some clarity.

You shouldn’t HAVE to do their job for them. But why let a shitty manager hurt your career any more than you must?.

Objection: “This is a gendered thing. ‘Steven’ would have been promoted for this, while ‘Susan’ gets scolded.”

110 You had one job.. ideas | you had one job, one job, jobA surprising number of people thought I was writing this as advice specifically to and for women, and got mad about that. Nope, sorry. It was not a gendered thing at all. I’ve seen this happen pretty much equally with men and women. I had planned on writing three or four anecdotes, using multiple fake names and genders, but the first one turned out long so I stopped.

Confession: I put zero thought into constructing a realistic or plausible list of activities “Susan” has at work. This came back to bite me. A LOT of people were doing a super close read of the situation (e.g. “She’s on three ERGs, so she must be a queer woman of color, which means she’s probably the most senior person at the company along all three dimensions of marginalization…”) — which, AUGH — this isn’t real, y’all —

This is Not A Real Situation✨.

— it was MADE UP! Totally! I just listed off the first several things that came to mind that people do at work that aren’t things they specifically got hired to do. That’s it.

I rather regret this. I should have put more time and thought into constructing a scenario Image tagged in you had one job,road stripes,timmy - Imgflipthat was less easy to nitpick. But I didn’t want anyone to see themselves in it, so I didn’t want it to be too recognizable or realistic. I just wanted a placeholder for “Person who does lots of great stuff at work”, and that’s how you got Susan.

TLDR — yep, Susan probably has a tougher go of this than Steven. I would argue that Steven generally wouldn’t be promoted either if he wasn’t adequately performing his core responsibilities, but who knows. This isn’t a real person or scenario. Women and nonbinary folks have it tougher than men. Your point? ¯\_(ツ)_/¯

Objection: “Why do you hate collaboration” and “This doesn’t apply to me because my job isn’t just writing code”

I never meant to imply that your “One Job” was only work you could do heads down on your own. Lots of people’s jobs involve a ton of force multiplying, mentorship, reviewing, writing The best you had one job memes :) Memedroidproposals… typical glue work. If you have a manager that thinks you are only doing your One Job when you are heads down writing code with your headphones on, that’s a Really Bad Manager.

The more senior your role is, the more your One Job involves less “write feature X” and more “use your judgment to help fine tune our sociotechnical systems”. This is natural and good.

It is also MORE of an argument for making sure you are in alignment with others in your org about what is the most important thing for your time and energy to be spent on, not less of one. Communication and persuasion are what upper levels are all about, right?

Objection: // Placeholder

I reserve the right to add to this list of objections after I go catch up on twitter, lol.

In conclusion

Finally, I want to call out a perceptive comment by @codefolio, where he said this:

Ouch. Truth.

This speaks to something I should probably be more explicit about, which is that my writing and my advice generally assumes you are operating in a high-trust environment. That’s the kind of environment I have been tremendously fortunate to operate in for most of my career — an environment where people are flawed but compassionate, skilled, and doing their best for each other, with comparatively low levels of assholery, sociopaths, and other bad actors. If your situation is very unlike mine, I can understand why my advice could seem blinkered, naive, and even harmful. Please use your own judgment.

I only write because I want the best for you — even those of you who very openly and vocally despise me (and yes, there are quite a few of you. Start a club or something). 🥰

All said and done, about 95% of the people who replied said that my post was helpful and clarifying for them, about 3% had very interesting critical takes that I got something valuable from, and only 2% were hurling rotten tomatoes and reading and interpreting my words in ways that felt wildly detached from reality. I try to remember that, when I get discouraged and feel like the whole world hates me and wants me to shut up. 🍅🍅🍅

I am not everyone’s cup of tea, and that’s alright. 💜 My advice is not relevant or helpful to anyone, and that’s okay too. Hopefully I have cleared up enough of the misunderstandings that anyone who is reading my words in good faith now has a clear picture of what I was trying to say. And hopefully it’s helpful to some of you.

PSA: I will be your rubber ducky advice buddy🐥❤️🐣

I have posted this on twitter a few times, but if you are struggling with a career conundrum, sociotechnical growing pains, or management issue, I am generally happy to hop on a phone call over the weekend and talk through it with you. I have benefited SO much from the time and energy of others in the tech industry, it’s nice to give back. (I like giving advice and I think VERY highly of my own opinions, so this also counts as fun for me 😂)

I 💜 talking to women and enbies and queers.🌈 (I love talking to guys too, but if my calendar starts filling up I will rate-limit y’all first to leave space at the front of the line.) If you are a white dude who hasn’t been following me on twitter for at least a year, this offer is not for you, sorry. If you’re a marginalized person in tech, otoh, I don’t care if you use that hellsite^W^Wtwitter or not. And if you hate my blog, you are not gonna like me any better live & unfiltered. 😬

🍃🌸🌼Sign up here🌼🌺🍃
(please read the instructions!)

Things I am generally well-equipped to discuss include startups, observability, databases, leveling and promotion issues, management, the pendulum, senior and staff levels, new manager issues, team dynamics, startup executive teams, and some complex workplace You Had One Job and You So Failed ~ 27 pics | Team Jimmy Joe | Building fails, Construction fails, Architecture failssituations.

Things I am not equipped to help with include how to improve diversity at your company, how to get women to want to work for you, or why only men are applying for your jobs online. I cannot be your personal DEI coach or guide to women in the workplace (there are great consultants out there doing the lord’s work, and you should give them all your money). I can’t find you a new job, help newbies find their first job (sorry 😕), give advice on raising venture money or tell you how to found a company (answer: never found a company, it’s the literal worst). In general I am not very well equipped to discuss early career issues, but if you’re an URM and you’re desperate i’ll give it a shot. I am not a therapist. And if you’re going to ask should you quit your job, I will save you a phone call: yes.

charity.

Know your “One Job”, continued

Know your “One Job” and do it first

Story time.

Susan was hired as a database engineer. Her primary projects, which are supposed to be upgrading/rolling out a major point release and running load tests against various config options and developing a schema management tool, keep slipping. But she is one of HR’s favorite people because she is always available to interview, even at short notice, and gives brilliant, in-depth feedback on candidates.

Susan also runs three employee resource groups, mentors other women in tech both internally and external to the company, and spends a lot of time recruiting candidates to come work here. She never turns down a request to speak at a meetup or conference, and frequently writes blog posts, too. She is extremely responsive on chat, and answers all the questions her coworkers have when they pop into the team slack. Susan has a high profile in the community and her peer reviews are always sprinkled lavishly with compliments and rave reviews from cross-functional coworkers across the company.

Lately, Susan has been getting increasingly exasperated about her level. She is a senior engineer, but the impact of her work is felt all across the company, and many of the things she does are described in higher level brackets. Why doesn’t her manager seem to recognize and acknowledge this?

Actually, Susan’s manager is absolutely right not to promote her. Susan isn’t adequately performing the functions of her job as a database engineer, which is the “One Job” she was hired to do, and which her teammates are all relying on her to do in a timely and high-quality manner.

When someone isn’t meeting the basic expectations for their core responsibilities, it doesn’t matter how many other wonderful things they are doing. In fact, those things can become strikes against them. Why is Susan available for every interview at the drop of a hat? Why is she agreeing to speak at so many meetups and conferences, if she can’t find the time to perform her core responsibilities? Why doesn’t she silence Slack so she can focus for a while? These things that should be wonderful positives are transformed instead into damning evidence of personal time mismanagement or an inability to prioritize.

When you are meeting expectations for your One Job — and you don’t necessarily have to be dazzling, just competent and predictable  — then picking up other work is a sign of initiative and investment. But when you aren’t, you get no credit.

This may sound obvious, but I have seen everyone from super junior to super senior fall into this trap — including myself, at times. When you get overwhelmed, all of your commitments can start to feel like they are of equal weight. But they are not. “You had One Job”, as the kids say, and it comes first.

Extracurriculars can feel like obligations, yet these are qualitatively different from the obligation you have to your core job. If you did only your core responsibilities and none of the extras, your job should not be in any danger. But if you don’t do the core parts, no matter how many extras you do, eventually your job probably will be in danger. Explain to your coworkers that you need to hit the pause button on electives; they’ll understand. They should respect your maturity and foresight.

If you’re feeling underwater, scrutinize what’s on your plate. Which are the parts you were hired to do? the parts that are no one else’s job but yours? Focus on those first. If you need more time, cut down or hit pause on the electives until you’re comfortably on top of things again.

Do you have too many core responsibilities? Those should never add up to 40+ hours of work every week. Everyone needs some flex and variety in their schedule.

If you are having a terrible time summoning the motivation to do the work you were hired to do, or if this is a recurring theme in your life, then maybe you are in the wrong role. Maybe you really want to find a role as a developer advocate instead of a software engineer. Maybe you just aren’t into the work anymore (if you’ve been there a while), or maybe you don’t know how to get started (if you’re new). Maybe it’s even as simple as mentioning it to your manager and reshuffling your responsibilities a bit. But don’t assume the problem will solve itself.

Take these feelings seriously. All of us need to buck up and plow through some work we don’t find engaging from time to time. But it shouldn’t be the norm. In the long run, you’ll be happier and more successful if you are truly engaged by the work you were hired to do, not just by the extracurriculars.

charity.

Know your “One Job” and do it first

How much is your fear of continuous deployment costing you?

Most people aren’t doing true CI/CD. Most teams wait far too long to get their code into prod after writing it. Most painful of all are the teams who have done all the hard parts — wired up continuous integration, achieved test coverage, etc — but still deploy by hand, thus depriving themselves of the payoff for their hard work.

Any time an engineer merges a diff back to main, this ought to trigger a full run of your CI/CD pipeline, culminating with an automatic deploy to production. This should happen once per mergeset, never batching multiple engineers’ diffs in a run, and it should be over and done with in 15 minutes or less with no human intervention.

It’s 2021, and everyone should know this by now.

✨✨15 minutes or bust✨✨

Okay, but what if you don’t? How costly can it be, really?

Let’s do some back of the envelope math. First you’ll need to answer a couple questions about your org and deploy pipeline.

  • How many engineers do you have? ____________
  • How long typically elapses between when someone writes code and that code is live in production? _____________

Let (n) be the number of engineers it takes to efficiently build and run your product, assuming each set of changes will autodeploy individually in <15 min.

  • If changes typically ship on the order of hours, you need 2(n).
  • If changes ship on the order of days, you need 2(2(n)).
  • If changes ship on the order of weeks, you need 2(2(2(n)))
  • If changes ship on the order of months, you need 2(2(2(2(n))))

Your 6 person team with a consistent autodeploy loop would take 24 people to do the same amount of work, if it took days to deploy their changes. Your 10 person team that ships in weeks would need 80 people.

At cost to the company of approx 200k per engineer, that’s $3.6 million in the first example and $14 million in the second example. That’s how much your neglect of internal tools and kneejerk fear of autodeploy might be costing you.

It’s not just about engineers. The more delay you add into the process of building and shipping code, the more pathologies multiply, and you find yourselves needing to spend more and more time addressing those pathologies instead of making forward progress for the business. Longer diffs. Manual deploy processes. Bunching up multiple engineers’ diffs in a single deploy, then spending the rest of the day trying to figure out which one was at fault for the error.

Soon you need an SRE team to handle your reliability issues, build engineering specialists to build internal tools for all these engineers, managers to manage the teams, product folks to own the roadmap and project managers to coordinate all this blocking and waiting on each other…

You could have just fixed your build process. You could have just committed to continuous delivery. You would be moving more swiftly and confidently as a small, killer team than you ever could at your lumbering size.

✨✨15 minutes or bust✨✨

In 2021, how will *you* achieve the dream of CI/CD, and liberate your engineers from the shackles of pointless toil?

P.S. if you want to know my methodology for coming up with this equation, it’s called “pulled out of my ass because it sounded about right, then checked with about a dozen other technical folks to see if it aligned with their experience.”

 

 

How much is your fear of continuous deployment costing you?

Questionable Advice: “How can I sniff out bad managers while interviewing for a job?”

A few weeks ago I got a question from Stephane Bjorne on twitter, about how to screen for bad managers and/or management culture.

This is a great question. I’ve talked a lot about my philosophy for interviews, which boils down to equalizing the power dynamics as much as possible to reflect the reality that the candidate should be interviewing the company just as much as the reverse. You are all highly compensated subject matter experts who can find jobs relatively easily; there’s no reason all the judgment and critique should flow in a single direction.

But HOW? What questions can you ask, to get a feel for whether you will join this team and belatedly discover that you’re expected to be a jira ticket monkey, or that the manager is passive aggressive and won’t advocate for you or take a stand on anything?

Glad you asked.

First of all, backchannel like mad if you can. If you can’t, do ask the same question of multiple people and compare their answers. Pay particular attention to the different answers given by junior vs senior members of the team, and give extra weight to the experiences of any underrepresented minorities

Questions to consider asking the manager:

  • “How did you become a manager? Do you enjoy it?” Trust me, you never want to work for someone who was pushed into management against their will and still seems openly bitter about it.
  • “What do you like about your job?” Red flags include, “I was tired of being out of the loop and left out of decision-making processes.” That could be you next.
  • Is management a promotion here, or a lateral move? Do people ever go back from managing to engineering? Is that considered a viable career path?”
  • “What kind of training do you offer new managers, and what are they evaluated on? What are YOU evaluated on?”
  • “Do you have a job ladder for individual contributors (ICs)? Can I see it? Do the IC levels track management levels all the way to the top, or top out at some point?”
  • “What does your review and promotion process look like?”
  • “Are your levels public or private? What is the distribution of engineers across levels, roughly?” Here you are looking for how high the IC track goes, and how many engineers exist at the upper bound. Distribution should be scant at the upper levels, roughly an order of magnitude less for each level after “senior engineer”. Do the written level descriptions seem reasonable and appealing to you? Do you see yourself in them, and feel like there is a path for growth?
  • Do you have any junior or intermediate engineers, and how many? If not, why the fuck not?” Ask.
  • “How often do you have 1x1s with each of your direct reports? How often are the skip levels?”

And then there is the ur-question, which every one of you should ask in every single interview you ever have:

What is the process by which someone ends up working on a particular project?” In other words, how does work get decided and allocated? Bad signs: they get flustered, don’t have a clear answer, you have no say, there is no product/design process, it’s all done via jira assignments.

Pay just as much attention to their body language and signals here as the answer they give you. Are they telling the truth, or describing their ideal world? Ask what happens when there are problems with the  normal process, or how often it gets circumvented, or how you know if your work aligns with company strategy.

Questions to ask an engineer:

  • “What do you talk about in your 1x1s with your manager?”
  • “How often does your manager have career conversations with you, asking how you want to develop over the next few years?” Ideally at least a couple times a year, but really any answer is fine other than a blank stare.
  • “Does your manager care about you? Has working here moved your career forward? How so?”
  • “Have you ever been surprised by feedback you received in a review from your manager?” You should never be surprised.

Most of all, can you get the manager to tell you “no” on a thing you clearly want during the interview? (Maybe a level, or WFH schedule, or travel, etc.) Or are they squirmy, evasive, or hedging, or make you promises that they’ll look into it later, etc? Anyone who will look you straight in the eye and say “no, and here’s why”, is someone you can probably trust to be straight with you down the line, in good times and bad.

Depending on your level and career goals, it’s a good idea to ask questions to ascertain if the right gap exists for you to fill to reach your goals. Don’t join a team where five other people have the same exact skill sets as you do and are already eyeing the same role you want. (I wrote more on levels here.)

We also got some great contributions from @GergelyOrosz and @JillWohlner:

  • “Ask about specific situations, any half decent manager can BS on hypothetical stuff.”
  • “Who was the last person you promoted? Why/how?”
  • “How do you handle when X complains to you about Y? Can you give an example?”
  • “What was the best team you managed and why?”
  • “What is the biggest challenge the team currently has and why? What are you doing about it? Biggest strength?”
  • “How many people have left the team since you’ve been here?”
  • “Who was the last person to leave your team? Why did they leave?” (These leaving questions are tough to ask but will give you a lot of signal. Especially seeing how the manager frames it — are they playing victim, or owning up to it?)

Anyone who won’t be honest about their real personal weaknesses and struggles, probably isn’t someone you want to report to.

Jill says that she wants to hear from ICs:

  • when their manager has gone to bat for them
  • when their manager gave them hard to hear feedback (if it’s never, it’s a flag — all positive feedback = little growth)
  • when their manager coached them through a tricky situation

and from Managers:

  • when they went to bat for someone on their team
  • a team member’s growth they feel really proud of
  • when they got negative feedback about someone on their team and how it was handled

Obviously, you won’t be able to ask all of these questions in an hourlong slot. So ask a few, and lean in whenever they seem avoidant or uncomfortable — that’s where the juicy stuff comes from. And personally, I wouldn’t consider working somewhere that sees management as a promotion rather than a peer/support role, but that may be a high bar to clear in some parts of the world.

Good luck. Joining a team with a good manager can be one of the best ways to accelerate your career and open the door to opportunities, in part because it ensures healthy team dynamics. Workplace friction, bullying, harassment, passive aggressiveness, etc can be truly terrible, and even in the milder cases it’s still a huge distraction from  your work and a big quality of life issue.

A manager’s One Job is to make sure that shit doesn’t happen. It’s really is worth trying to find a good one you can trust.

Questionable Advice: “How can I sniff out bad managers while interviewing for a job?”