Have you ever been in an engineering all-hands only to realize you were spacing out the last 20min of presentations?

That’s probably because the presenter wasn’t speaking to you or the audience. Just because we’re all engineers doesn’t mean every technical detail is relevant to every situation.

I believe there are three key ways to influence with your technical stories:

1. Crafting your narrative

2. Using data

3. Sharing your story publicly (and multiple times)

Subscribe now

Step 1: Crafting Your Narrative

I learned most of my storytelling traits actually from when I was a yoga teacher. In my training we were taught that we should have some sort of theme for each class and to feel closer to the students you should pick a personal story to speak about. The key being it’s the perfect balance between personal and relatable so that people feel connected to you.

I think that skill still translates to technical storytelling, how can you convey your message so that it’s the perfect balance between personal (relates directly to your project) and relatable (other engineers can use it for their projects)?

Understand your audience

Who are you talking to and what do they care about? Is it all of engineering? A mix of engineering and product? Whoever they are speak directly to them!

Let’s say for example you are doing a presentation about a new automated rollout system that you’ve created that you want other product engineers to adopt.

Quick exercise, think why would this be relevant to each of these groups:

• Product manager

• Infra engineer

• Product engineer

• Engineering manager

• CTO

• Your teammate

The answer depends on your company but more importantly the answer is different for each role. Remember the story is for your audience, share something that they can use right after your presentation is over.

Step 2: Using Data

As I’ve mentioned before in Why Nobody Cares About Your Idea data is one of the easiest ways to convey your point. You tell me which sounds better:

Our new automated rollout implementation reduces the chance of incidents

or

This new automated rollout tool only takes 30 minutes to integrate in your system. We’ve rolled it out across two pilot teams and each have reported a 80% reduction in deployment related incidents the previous quarter.

As you can tell the first one doesn’t really tell much of a story which makes it easy to not care about. But once you start putting the effort into data collection the numbers will speak for themselves.

Then I’d argue you have no compelling story to tell. How do you actually know what you’re doing is making a positive impact? Remember data can come in many ways and it’s okay to even manually look through things like support tickets to gather data.

Step 3: Share Your Story Publicly

Once you have all the important data collection and your audience(s) figured out, it’s time to share!

Go through your different audiences and figure out the best platforms, for example:

• All Hands

• Slack channel

• Team meeting

• Brown Bag

• Via PR comments

• etc

Most importantly, once is not enough. Think about yourself as an ambassador for this new idea. People need to hear something multiple times for it to stick.

Conclusion

Most of the time people don’t care about how you do something but instead care about why. Cater your stories to your audience and prove there’s a why and you’ll convince almost anyone.

Thanks for reading :)

Eden

Read more

I love doing behavioral interviews because I find them more telling than technical interviews, especially when it comes to more senior positions.

For each level, I’d always include this common question in my interviews: Tell me about a bug or outage you’ve caused.

Here I’ll break down what I expect from a Junior/Mid-level engineer, Senior engineer and Staff engineer.

Subscribe now

Regardless of level, I expect the engineer to answer this using blameless vocabulary. Bugs/outages are never caused by an individual! Humans will make mistakes so it’s up to a team to ensure human error is prevented by systems as much as possible.

Mid-level / Junior

TL;DR:

• Fix the bug / put out the fire

If at this level the engineer is already starting off with blameless vocabulary, we’re off to a pretty strong start. From there, I look for a few things:

• How did they react when finding out about the bug they caused?

  • ✅ Let’s the team know as soon as possible

  • ✅ Takes ownership and helps come to a solution

  • 🚫 Ignores it for someone else to find out

  • 🚫 Blames it on an another individual

• How did they prevent themselves from causing the bug again?

  • ✅ Updated documentation

  • ✅ Updated the code / script

  • 🚫 Just tried to remember to not do it again

Senior

TL;DR:

• Fix the bug / put out the fire

• Update system so that it wont happen again on the team

At the senior level you want the scope of impact to be across the team, so we want them to not only remediate the problem but make sure it wont happen again on this team.

• How did they react when finding out about the bug they caused?

  • ✅ Assemble the necessary people and fix the bug / stop the incident

  • 🚫 Do nothing

• How did they prevent the bug from happening again?

  • ✅ Update code to prevent human error (e.g. adding more tests)

  • ✅ Write up summary for the team so they know what happened

  • ✅ Update process for team for further prevention (e.g. requiring unit tests with each PR)

Staff

TL;DR:

• Fix the bug / put out the fire

• Update system so that it wont happen again on the team

• Educate wider organization on how to change their systems to prevent a similar incident

At the staff level scope now is beyond your team.

• How did they react when finding out about the bug they caused?

  • ✅ Assemble the necessary people and fix the bug / stop the incident

• How did they prevent the bug from happening again?

  • ✅ Update code to prevent human error (e.g. adding more tests)

  • ✅ Write up summary for the team so they know what happened

  • ✅ Update process for team for further prevention (e.g. requiring unit tests with each PR)

  • ✅ Do a knowledge share with a wider audience on how to catch these things for their codebase

  • ✅ Work with other staff+ engineers across different teams to create a process around the entire codebase to help with prevention (e.g. create new type of monitoring tool to alert when X is down)

Conclusion

At the end of the day the biggest difference between levels is often scope of impact. The further you move up the more you have to think about making changes that make things better for more engineers around you.

Thanks for reading :)

Eden

Subscribe now

Have you ever been in the middle of solving a problem and got a bit of déjà vu? You know that you fixed something similar a while ago but have no idea where that PR is.

You spend 30 minutes digging through Slack, Google Docs, GitHub and can’t find it anywhere. Guess you’ll have to solve it from scratch all over again. 🙂

This ain’t it! As a software engineer one of your biggest skills needs to be the ability to find relevant resources (ideally, quickly).

These are what I consider the top 3 ways to achieve this skill:

1. Creating a personal encyclopedia

2. Becoming very skilled at filtering (logs, messages, etc)

3. Having a good understanding of your company’s different products

1. Creating a Personal Encyclopedia

Of course it’s important to maintain documentation for your team, but your personal encyclopedia is different. Your personal notes are for you and will be useless to anyone else who finds them.

Here’s a recent example for myself. It’s been a while since I’ve done python or full stack development and I kept forgetting the commands to develop locally.

I added this page to my personal encyclopedia so if I search “local development” I can find these commands easily to copy and paste.

It doesn’t really matter where you keep your notes but it helps to have it somewhere central and searchable. There’s no point of taking these notes if you don’t have a way to find them.

At my previous job I kept all my notes in my Slack DM so that everything was searchable through the Slack UI (my personal notes as well as things across channels).

2. Get Skilled at Advanced Filtering

Getting away with just using quotes around words for exact matches isn’t quite enough. When searching through Slack, docs and especially logging you should be using the advanced search.

Some things to try:

• Narrowing the namespace for logs

• Searching within a time range

• Searching messages from a specific author (e.g. a tech lead you think could’ve mentioned something relevant)

• Filtering by specific customers you know have come across the same issue

• Searching in a specific channel instead of across slack

• etc

I’ve found my most success when I get as specific as possible with my searches.

3. Understand Your Company

The more you have an understanding of your company’s hierarchy, the easier it’ll be to know where to look. Start attending all hands meetings or just get to know tech leads from neighboring organizations. Once you know who is responsible for what, it’ll be easier to know where to look.

For example if you recently familiarized yourself with the search team, the next time you have an issue related to the search service you know which channels to go to or who to page.

Conclusion

There’s no right way to keep track of all this information, but there is a wrong way (trying to keep it all in your head).

Personally I really enjoyed reading Building a Second Brain and would recommend it to anyone who wants to take note taking seriously!

Thanks for reading :)

Eden

Subscribe now

A common theme I’ve noticed in my 1:1s is frustration.

• “Why don’t people trust my plan, I know what I’m talking about!”

• “Why won’t my manager let me lead this project, I know I can do it”

I’ve been there too, you know yourself better than anyone else so it’s easy for you to see why you’re able to do something. But the fact of the matter is, there’s no reason anyone should trust you by default.

I’ll give you 3 simple ways to gain that reputation:

• Execute

• Execute

• Execute some more

There’s no amount of product designs, proposals, or talk that will get you the respect you desire at your company.

Think of who you look up to the most on your team. Why do you look up to them? I’m going to guess it’s not about what they’ve said in your meetings but what they’ve done at the company.

Now, what does execution look like? Let’s talk about a few of my favorite strategies:

1. Fixing the annoying problem everyone ignores

2. Asking the hard questions

3. Consistently doing what you say you will do

Subscribe now

1. Fixing the annoying problem everyone ignores

What is starting to sound like a broken record in your stand ups?

I’ll give some examples of my past teams and potential solutions:

• I was paged last night but it was a no-op, the API is probably more sensitive than it should be

  • Figure out how to update thresholds for your team and do it

• I wasn’t able to get my task done, the customer experience team needed my help updating some configs that only can be updated by scripts right now

  • Create a UI that allows customer experience to do this directly

• I’m not sure what to pick up next so I just did some random things in the backlog

  • Create a process that makes it easy for any engineer to know what the next top priority there is to be done

Taking just a few hours a week to solve these problems is probably the easiest way to gain respect. Engineers love someone who just fixes things instead of talking about how we should fix them.

2. Asking the hard questions

Have you ever noticed a project going downhill but didn’t say anything? Maybe during lunch you complained with your friend about how incompetent a leader was, how bad a design was or even how the project was a waste of time all together.

Once the project fails, you find yourself telling your friend “I told you so, I knew the project was a hot mess!”

Well… why didn’t you say anything 😂

Ok, you might be thinking, “that’s above my pay grade, not my job to fix this disaster.” That may very well be true, and you could leave at that! But why not use it to your advantage?

Instead, when these meetings are happening ask the hard questions.

As usual, here are some examples of situations and hard questions you could ask:

• You notice the lead of the project says that it’ll take 2 weeks to do something that you know will take at least 3 months

  • “I noticed you said adding the CRUD APIs for the dashboard will take 2 weeks but last time we did something similar it took 2 months due to how long it took to get feedback from DevRel on a public API — how are we able to cut that down for this project?”

• During a planning meeting you notice the team going down a rabbit hole about adding a features not on the original product spec

  • “While I think adding feature X would be awesome, wouldn’t that push back our timeline? It wasn’t on the original product spec so just wanted to make sure that it’s worth potentially modifying our timeline”

It might be difficult to speak up at first, but these comments can save you and the team months of wasted efforts.

3. Consistently doing what you say you will do

One of my favorite quotes from Michael Seibel comes from What Makes The Top 10% of Founders Different:

Notice this doesn’t have anything to do with what you’re getting done or how you get it done — but more about just doing the damn thing. Here’s examples of anti-patterns.

• Saying in planning that you’ll be able to get something done but end up coming back 2 weeks later saying things came up and you weren’t able to finish

• Offering to set up a brown bag or code review club but never committing to making it consistent

• Promising to create an onboarding document for future new hires but not having anything ready by the time the new engineer starts.

Start to take your word seriously. Before saying yes to something ask yourself if it’s something you should be doing. If not, say no! If yes, get the damn thing done no matter what.

Subscribe now

Thanks for reading ❤️‍🔥

Eden

The funny thing about project estimates are… they’re kind of impossible to do accurately. There are so many things that can throw a project off like:

• Someone taking emergency medical leave

• An incident that slows down development of a dependency

• Someone leaving your team

• Change in management

• New requirements from an internal team

So, what is the right way to estimate a project? While there’s no one right way, I’m going to share my three key steps to project estimations.

Subscribe now

1. Time Box!

There’s diminishing returns when it comes to estimating a large project. I honestly believe spending a day on an estimate is just as good (if not better) as spending a few weeks.

Let’s make up a scenario. My manager comes to me and tells me a customer would like a new feature where they can search users by membership status and would like an estimate for how long that might take. I would take about an hour to think through these things:

• Is there a current searching mechanism for users (something we could leverage/reuse?)

  • Does this search mechanism already have filtering or would we need to add that?

  • If the mechanism exists, are there FE changes that need to be made or can it all be done on the BE side?

• Where is this membership data stored, is it already indexed?

• How do the customers want access this information? Is it during a data export, during their day to day, or maybe just through an API?

  • This helps me understand QPS/scale/and where it should be implemented

• Will we need to work with the search team on this? Or do they have tooling we could leverage?

I want to answer these big questions, most importantly I want to learn when are we going to need to create something new vs leverage something that already exists. With some basic research on Slack (and maybe even bringing up some questions on #team-search) I can get a general idea of the complexity.

From there I use past experience from myself and relevant experts to try and piece together a timeline.

2. Prototype

When I’m creating something that’s mostly net new I find prototyping the fastest way to learn how it’ll look. I spin up a dev branch and try to get a very basic functionality working end to end so I understand all the pieces that are going to be touched.

Reusing the previous example, I might hack together a prototype reusing an existing search API that’s really meant for messages instead of user types.

During your prototyping you’ll notice things that were more complicated than you thought (e.g. I might notice that the search API I planned on leveraging only refreshes user info every 24 hours which might not be fast enough for this new project).

3. Continuous Updates

Ok, so now you created a timeline and gave it to your manager. You picked an estimated launch date and it’s time to get to working.

WAIT!

The estimations aren’t over my friend. That was just an estimate! The chances that your project will be ready right on that day is slim to none. Your team could either finish it faster or things might come up that slow it down.

Now your job is to keep an eye out on when things change. You’ve made a few assumptions at this point, keep track of when things start to fall off course. For example:

• Scope creep, are people adding things to the project that weren’t a part of the initial estimates?

• Unexpected change in staff

• Difficulty getting help from dependent teams

When they happen, communicate to management! For example:

Hey boss, just wanted to call out that Anne just got called into jury duty so we don’t have a dedicated front end engineer for the next 2-3 weeks.

This will likely push back the pilot release, do you think we could get a backfill in the meantime or should we just plan to delay the release?

Your manager is there to help with these problems and it’s your job to keep them updated when things start to go off track.

Subscribe now

Hope this helps! What tricks do you use when estimating projects?

Thanks for reading ❤️‍🔥

Eden

In high school and college I was so used to quantity being over quality. It was more important to be “well-rounded” than extremely good at one skill.

Subscribe now

Take a look at your calendar for this week, what are you dedicating your time to? How much of it is directly impacting your team’s OKRs vs things outside your team’s goals?

Do you fall into the habit of saying “yes” to things just to be a team player?

While it might feel like you’re moving yourself in the right direction by getting more work done, you’ll notice at the end of the quarter you don’t have anything significant to show for. Too much of your work was split into multiple streams and now you don’t have a big achievement to list in your self review.

Action time:

Let’s take some inventory. What is something you can remove from your week (or month) right now? How can you say no to one of your current commitments outside your team goals?

If you want help wordsmithing your “no,” let me know!

Thanks for reading ❤️‍🔥

Eden

Subscribe now

P.S. Sorry for being behind on our newsletter! and I were heads down working on our application for Y Combinator. Wish us luck! 🧡

Read more

So… how do you ramp up quickly?

These are the 3 ways that I personally use to ramp up to a new codebase:

1. Starting with one focus area

2. Pair programming

3. Customizing your IDE

Now let’s get to it!

1. Starting with one focus area

If you’re starting on a new team or codebase, chances are there are 100 new things to learn about.

• Different products

• Automated testing

• APIs

• Databases

• etc

When you’re ramping up your first month just focus on one of these things. If your onboarding buddy hasn’t already set this up for you, ask them if you can spend the month working on bugs/tasks in just one focus area. Ideally something close to what the team is working on now.

It’s easy to feel the pressure of trying to master everything on the team so you don’t feel behind, but I find it way more productive to start mastering just one part of the team’s codebase.

2. Pair programming

The opinions on pair programming can be divisive, but personally I’ve found pair programming to skyrocket my success as an engineer. Usually I ask someone more experienced to code with me for around an hour while I work on a task that was assigned to me.

What I enjoy is that you have someone with you answering questions in real time instead of you having to stumble around finding outdated docs. There are likely nuanced things in the code that aren’t documented well and you save a lot of time learning these things directly from experts.

If you’re currently onboarding to a new codebase, try asking this to your mentor or someone on the team:

Hey! I just picked up TASK-1337 and was wondering if you could pair with me on it for an hour.

I don’t have any questions yet but it’d be really helpful for my onboarding if I could get feedback and ask questions in real time.

3. Customizing your IDE

I beg of you, DO NOT LEAVE THE DEFAULTS ON FOR YOUR IDE!!

There’s nothing more painful for me than watching an engineer fumble through their IDE trying to make changes, some examples:

• Struggling to go back and forth through the codebase

• Unable to search for functions quickly

• Consistently struggling with merge conflicts

from recently posted How I setup my terminal for max productivity which is a great read, I have a very similar terminal setup.

If you’re not sure where to start, I’d recommend finding a senior or staff engineer on your team and asking about their setup. You can copy theirs and modify yours as you continue to grow.

Do you have any tips on how to onboard to a new codebase? Let me know!

Thanks for reading,

Eden

Subscribe now

Read more

Having worked at startups and lean tech companies for over a decade, I have always reported directly to a C-level executive. My first corporate role was as an Executive Assistant so I learned very quickly how to communicate with “higher ups” who are chronically overbooked, wear a dozen different hats and somehow always short on time. Those skills have helped me in every role I’ve held since. 

Knowing how to communicate with the top level has allowed me to outperform my peers, comfortably navigate the office politics and progress my career quickly.

Here’s what I’ve learned:

Read more

As software engineers it’s easy to get into the habit of just “working through it.” After all, we’re paid well and we have way easier jobs than people like nurses and teachers, right?

Regardless of if this job is “cushy” or not you can become burnt out from your job. You deserve time to take care of your mental well being as much as anyone else.

Here are three common signs I’ve noticed*.

Subscribe now

1. Feeling detached from your work/team

Starting to feel detached from your team could look like a lot of things:

• Spacing out during your planning meetings / stand-ups

• Not providing as much input in decisions as you have before

• Not caring about what projects/tasks the team works on

• Feeling cynical about the team’s decisions

  • e.g. “Yeah that’s a horrible idea… but whatever it’s their funeral I’ll write up the task”

The biggest thing to note here is that you have gone from being excited/interested in how the team is affected to feeling almost completely uninterested.

2. Not finding your work valuable

It’s essential to feel your work is making a difference in your day to day. Whether you’re making things easier for your team or just using your skills to provide monetary value to the company.

Here are some signs that you might not be finding your work valuable:

• You’re doing the bare minimum to get tasks done

• Holding on to tasks for longer than normal

  • e.g. Something that used to take you a few days is now being rolled over to multiple sprints

• You simply don’t find the work important

• You don’t share any input and just do the tasks that are given to you

3. Changes in sleep/diet patterns

I’m sure you’ve heard this one 100x but, it’s true! Are you sleeping in way more often? Are you staying up late? How about your diet, are you eating less than normal? Do you realize you’re missing your morning meetings more often?

These are important things to think about. If you have a smart watch you can even wear it at night to start tracking your sleep. Keeping track of these patterns are great indicators for health.

If you work at a medium to large tech company, chances are you have a decent medical leave program that allows you to get paid while taking time off.

I highly recommend talking to your primary care provider (PCP) about your burn out signs. There could be things in your life affecting your mental health that legitimately require you to take time off from work.

Set up some time to chat with your physician and they’ll guide you through the process if they deem medical leave necessary.

Take care of yourself!

Eden

*Disclaimer: I am not a medical professional! This is my opinion on burn out signs and should not in any way be used to actually diagnose burn out, please talk to a real doctor.

Read more

You love being good at your job, but might not love doing it for 10+ hours/day. 😅

The journey to staff comes with sporadic and extremely specific problems that are hard to solve on your own. Without other like minded people to talk to, it’s easy to get trapped in analysis paralysis.

So… and I have decided to open up a community exclusive to our paid Get to Staff subscribers. ❤️‍🔥

We will be there to answer any questions and to help foster this community of like minded people. 🧠

If you’d like to support us we’re starting our membership at $8/mo or $80/year, which is exclusive to our early subscribers.

Thanks for reading and all the support you’ve given us so far! 🫶🏾

Eden

Taking inspiration from The First 90 Days by Michael D. Watkins, I believe it really comes down to these three things.

1. Learning

2. Execution

3. Growing Others

Subscribe now

1. Learning (Days 1-30)

Take whatever you learned from your previous company and throw it out the window. All your best practices, your testing strategies, your rollout strategies, your genius tooling, PR review methods. Say goodbye. I know, those are your babies, but for now let’s forget them.

It’s time to learn everything about your company. Think beyond just your immediate team, what does this company do?

• What are the informal networks of communication?

• What are the most important products of the business?

• Who are the customers?

• What is the company’s operating model?

• Who are your stakeholders outside of product/design/engineering?

This is a great time to meet with as many people as possible across the company and ask questions. Don’t come in with any answers quite yet.

Soon you’ll become the company expert on your team. Chances are the other engineers have no idea how the company works outside of their domain/expertise. The more you know about the business the more you can move the needle forward for your pillar.

2. Execute (Days 30-60)

Now that you have a good idea of the culture, met stakeholders and peers, and have assimilated as much as possible. It’s time to execute.

First, it’s time to let go of ego. Just because you’re coming in as a senior engineer doesn’t mean you must do senior level tasks right away (e.g. design docs, large projects).

Instead, secure early wins. Building momentum early is the easiest way to gain respect from your peers.

Think about it, have you ever had a new person join your team who just knocked out a ton of low hanging fruit or tickets? What did everyone say about them? I’m going to assume pretty positive things about how quickly they’ve become helpful.

So, do the easy tasks, the mundane tasks, whatever you think would help the team right now.

3. Growing Others (Days 60-90)

By now, you’ve probably gained quite a bit of trust from the team. Let’s leverage the respect you’ve garnered to grow and help others.

In my personal experience, I’ve found the best way to do this is through asking questions and leading by example.

Here are some examples:

• Ask questions in a non-confrontational way in PRs and design reviews

  • “I noticed you’re using `cache_fn()` to store the team_id, does that mean we’ve elected to not use the new CacheInstance::class that was introduced last week?”

• Creating in depth PR descriptions for your own PRs when you notice others have empty descriptions

• Creating reusable test infrastructure for your tests when you notice others aren’t adding unit tests to their code

• Fixing issues that other people have brought up in meetings/standup

  • E.g. In standup people were complaining about a noisy page/alert and you spend an hour fine tuning it to reduce pages

I hope this helps. Thanks for reading! ☀️

Eden

P.S. Calli and I have created a course: Acing Your Final Interview at a Top Tier Tech Company. Please share if you know anyone with an upcoming interview!

Read more

Hey, I saw a post where you did some load testing setup for someone else.

Can you hop on a quick with me to help me with mine? I’d appreciate it so much, it wont take more than 30min!

How can you say no? They asked so nicely and it’s important to build up those around you.

While it might be hard at first, saying no and not helping people right away is the best way to get people to respect your time. Once you respect your own time people will learn to respect yours.

Here are three ways I’ve managed to say no at work in a stern but respectful way:

Subscribe now

1. Redirect People to Public Channels

It’s time to get out of your DMs. If someone needs help, kindly ask them to bring up the question in a public channel.

I’d love to help but unfortunately I’m focused on a big task today. Do you mind bringing it up in #team-loadtest? There’s probably someone there who could help sooner than me.

There are a ton of benefits to this:

1. You get visibility if you end up answering the question in the public channel

2. A more junior engineer has the opportunity to answer the question in a public channel

3. The answer is available to any engineer who searches this question in the future

4. This fosters more cross collaborative communication

2. Pause Notifications on your Slack

Realtime notifications make everything feel urgent. For some, turning off notifications sounds like a recipe for disaster (what if my boss messages me something urgent? what if I miss an important escalation?).

In most cases, there already are ways for someone to contact you if it’s urgent. They could bypass the snoozed notification or page you via PagerDuty. Slack notifications are not designed to be used for urgent communication.

I keep my notifications turned off the whole workday, everyday (aside from the occasional incident). I check notifications on my time so that my most important work is done before checking for any updates.

With your notifications off, you will start to notice DMs like this:

[10:31am] quick question, do you know where the doc is to delete a dev table?

[10:38am] nvm, found it!

3. Declining “opportunities”

The hardest thing to say no to is a manager request, but that doesn’t mean it shouldn’t be done.

Often managers will throw everything at you and won’t stop until you say no. They’re often managing many engineers and don’t have the brain space to keep track to which opportunities are good for you or aren’t.

Hey, Eden! Our pillar is starting to host a new knowledge share session with some rotating hosts. I want you to work with the engineer hosting it to find some engineers to do some demos.

Before saying yes, let’s evaluate the situation.

1. Does taking on this work move your personal career goals forward?

2. Does taking on this work move your team’s goals forward?

3. Does taking on this work sound enjoyable?

If at least 2 of these are no, push back!

Hey, boss — the knowledge share sounds great and I’m looking forward to checking it out. I’d love to help but I know we have a deadline coming up for the project I’m leading and I’d hate for that to slip because I’m not able to focus on it.

Any chance you could find someone else who might be a better fit? If not I'm happy to take it on it just might hurt the timeline for Project X.

Your boss might say no by saying something like, ”you should be able to do both.” But it’s likely they’ll just agree with you and move on to finding someone else to do the work.

Conclusion

It’s time to get creative with your nos! The more experience you have, the more people will ask of you. This is when it’s especially important to learn how and when to say no.

Are you in a tricky situation that’s hard to say no to? Reply to this email! Let’s talk about it.

Thanks for reading :)

Eden

Subscribe now

1. More money

2. More time

Let me take a wild guess… you chose more time. I’m going to assume you’re a pretty pragmatic engineer who puts money into their 401k, has some investments, a decent chunk in savings, and lives below their means.

So, why are you pushing for more money during negotiations?

When I came to this epiphany I realized that I had enough money, what I didn’t have was enough time to explore other things I really wanted to do (starting my own business).

Here’s 3 steps on how to negotiate a 4-day workweek based on my experience:

1. Request a Trial Period

It’s easier for your manager to say yes to a trial period than to a permanent change. I would recommend asking for a 3 month (1 quarter) trial period starting at the beginning of your fiscal quarter. This will make it easier to quantify the work you are doing based off your team’s goals. If it is not possible to get a full quarter trial period, use your PTO to take Fridays off for a month for an unofficial trial period.

2. Quantify your Work

In order to get an easy yes from your management you need to prove that you can do just as much work in four days that most people your level can do in five. Although there is plenty of precedent of successfully administering a 4-day work week, having this data for you specifically can make the decision much easier.

Ways to Quantify Your Work:

I recommend starting your trial period at the beginning of the quarter because it is easiest to map out your work in terms of the team/individual goals.

Completion of an OKR/Project

If there was a project assigned to you at the quarter and you finished it at or exceeding expectations, that is a straight forward way to prove you can get your work done in 4 days/week.

Using GitHub Stats

If you are an engineer you can show that the number of Pull Requests that you have reviewed or merged is comparable either to yourself the previous quarters or to your peers.

Using JIRA/Ticket Stats

Similar to above, if your team tracks progress with tickets make sure you are tracking all the work you do to prove how much you are accomplishing during your trial period. Bonus points if you already are quantifying the tickets with points.

Peer Feedback

Your manager will likely ask your peers if your consistent Fridays off are negatively impacting them (especially if you are Senior+). Reach out to them when your trial period starts to ensure you are doing what you can Mon-Th to support them.

3. Present Case to Your Manager

Even if your manager knows you are deserving of a 4-day work week they will likely need to present this case to their management as well as HR. The more numbers you have for them the better.

Conclusion

This may look easier said than done but it is just as simple as asking! Having the right data in front of your manager can make it easy for them to say yes. And if you are looking for a new job you can even fit in these negotiation discussions before you even start.

Thanks for reading!

Eden

Read more

I used to finish a day of work thinking, “what did I even get done today…” often because of how many meetings I attended. I sat in half of them probably spacing out or doing work while someone else was talking.

Then I realized, can I just not go to this meeting?

Turns out the default for a lot of teams is to invite everyone who might be relevant to a meeting.

So before you accept an invite ask yourself, do I really need to be here?

Subscribe now

So thinking back to how we start our workday, we want to know the #1 task we need to get done for the day. If a meeting does not move that goal forward, we probably shouldn’t go (this of course excludes social events)!

If you’re not 100% sure you can skip the meeting, reach out to your manager and ask if that meeting is more important than making progress on your goal. Chances are, they’ll much prefer you working on your main goal and be happy to dismiss you from the meeting.

Working smarter and not harder is all about being extremely precious with your time, you’ll realize the more you respect your time the more others will respect your time as well.

This week’s action: Pick one meeting from your calendar this week that you don’t find useful to you and don’t go.

Let me know what meeting you removed and how your team/manager responded!

Thanks for reading,

Eden

P.S. My co-founder and I are working on ways to make sure people get what they want out of their careers, check out thecareernavi.com if you’d like to see our progress!

Subscribe now

Read more

When I was a strong senior engineer I could execute things no problem. Give me some ambiguous scope, a tight deadline, and a goal and I’d figure out how to make that happen.

I thought, great, this will get me to the next level, right? Nope.

My manager told me that to get to staff I need to help the whole team execute the way I was executing. It’s no longer enough to do great work, it was time for me to build up the entire team so anyone could execute things just like I did.

Subscribe now

1. Mentor senior+ level engineers

It’s not enough anymore to mentor people below your level, start helping people at your level or above (yes you can help staff engineers!).

There’s tons of ways you can make this happen:

• Ask if someone wants regular 1:1s just to have someone to talk through problems (e.g. a rubber duck buddy)

• Find staff engineers that are new to the company, reach out and see how you can support them

• Review pull requests (PRs) and design docs outside of your direct project

• Answer unanswered questions in channels that you are not responsible of

2. Document and implement processes

If you’re really good at something, chances are there’s a process you follow with each project, release, design, etc. Now let’s take it to the next level, how can you formalize this process? And even better, how do you get others to adopt this process?

This is where you need to learn to sell to other engineers. People don’t adopt new processes for no reason, it needs to be 10x better than what they’re already doing for them to adopt it. How can you prove that it is?

3. Take ownership of the success of ALL projects on your team

As a staff engineer if a project doesn’t go well on my team I don’t think “not my problem 🤷🏾‍♂️” anymore, because it is my problem!

As a leader you want to support other directly responsible individuals (DRIs) on your team and if you notice something going wrong, jump in!

Some ways you can support the success of all projects:

• Call out if you notice a project is consistently missing it’s weekly/sprint goals

• Jump in to help with a project if they’re falling behind (e.g. if there’s a few people unexpectedly out sick)

• Offer 1:1s to the DRIs

Conclusion

If you’re reading this, you’re probably a pretty high performing engineer and can get shit done. Let’s figure out how you can spread that across your team and pillar.

Want to chat about your game plan to lead through leaders? Reply to this email! I’d love to chat :)

Thanks for reading!

Eden

P.S. If you have been enjoying this newsletter, I’d love if you could share this with 3 of your friends!

Share Get to Staff 🪄

Read more

Often we’ll hold onto a team for a little longer than we’d like for the chance at a promotion. You might’ve been told you have a “promising chance” or something like that, but it’s hard to look into the future and see how your promotion packet will actually pan out.

Here are 3 common indicators I’ve noticed that a promotion your next cycle (assuming it’s in ~6 months) may not happen.

Subscribe now

1.You aren’t mentoring others at your current level

Do people at your level come to you for assistance/guidance? Do you create resources/runbooks that people ask for frequently?

If not, try to find ways to help your team (and beyond) at scale. Creating documentation, scripts, templates and things reusable by many is a great start.

2.You haven’t talked to your manager about promotion yet

You and your manager should be aligned on when you’re going up for promotion. If you don’t have a plan ~6 months out, start planning now!

Take advantage of recency bias and work with your manager to have some great staff+ projects lined up for you in the upcoming quarter.

3.You’re not already helping with the team roadmap

Even if you’re not yet in leadership meetings with your manager, you should be helping with the roadmap in some capacity. That could be things like:

• Compiling data for your EM to help them make informed decisions (e.g. incidents categorized by severity and component)

• Creating proposals to help pillar initiatives that include impact and scope details

Conclusion

Most managers mean well (and want you to get promoted!) but we can’t rely on just the hope that it’ll go well. Take advantage of your time before the next promotion and start your preparation now!

Have any questions about your promo packet? Respond to this email and we’ll talk!

Thanks for reading,

Eden

Subscribe now

Read more

Happy hump day, everyone! 🐪

I wanted to share I’m doing a limited sale (5 total spots) for a 60min coaching session at $99*.

Who’s this for?

• Junior to senior engineers looking to up level their career

• Someone who wants customized actionable steps on how to improve TODAY

What do you get?

• 1 complimentary 45min consultation

• 1 60min session (money back guarantee)

• 3 months paid membership to GetToStaff newsletter

You can get more info and read testimonials at gettostaff.com/coaching

Thanks for being awesome! Let me know if you have any questions :)

Buy Now!

*Limit 1 per person

I had senior level responsibilities (executing projects) but weirdly also staff level responsibilities.

Most companies require you are already showing staff level skills before your promotion gets approved, so how do you do both?

Subscribe now

What worked for me was directly asking my manager to split my responsibilities. Ask your manager if next quarter you can split your senior and staff level responsibilities 80/20. That means you can dedicate one day of the week for staff level work.

That could be things like:

• Collecting data about some hunches you have on the team

• Writing up small proposals on things you think the team should work on

• Reviewing team PRs or design docs in your pillar

Many people think that you’ll have to destroy your work life balance to get promoted, but it’s not the case! It’s likely your manager wants you to succeed and grow. Try asking for the space to do so and you’ll be pleasantly surprised!

Have a great week, squad ❤️‍🔥

Eden xx

P.S. I love hearing from you all. If you try any tips from this newsletter I’d love to hear all about it, reply to this email!

Subscribe now

Read more

I always blamed it on them.

If they just listened, we wouldn’t have as many incidents!

Why can’t they see this would make their life easier if they just adopted this new pattern?!

Why wont anyone review my proposal? It has all the details you could possibly ask for!

Boy, was I wrong.

Subscribe now

Audience, Audience, Audience

Who are you sharing your idea to? This matters.

For example, if you’re presenting to all backend engineers at your company, you probably don’t want to get into the weeds of how you fixed some problem. Instead think about what would apply directly to them.

Some examples of what they might care about:

• A safe rollout method that worked for you that they can try for their next rollout

• A bug you caused due to a common misunderstanding of a system that other engineers might also come across

• A new monitoring runbook you created that can apply to any webapp engineers creating new features

Data, Data, Data

What if you have a new idea you want to share with your direct team? Prove to them that it’s worth their time.

For example, if you have a proposal for reducing noisy logs, show them why noisy logs suck!

Some examples:

• Show the % of incidents caused due to missing an important alert

• Show the cost of noisy logs in AWS

• Show the times that an escalation was extended due to not being able to find an important log

• etc.

If you can show that your noisy logs are costing your team $10,000/mo — they might start to listen! Data is your friend and make sure to use it before sharing a proposal.

Conclusion

So if you’re like my previous self, you might be taking it a little to personally when people don’t listen to your idea 😬

Next time, find data to back up your ideas and cater it to the right audience. Soon you’ll notice people will start coming to you for proposals instead of the other way around!

Thanks for reading :)

Eden xx

Have you considered if the roles of a staff engineer are something you’d want to do in your day to day?

Here are 3 reasons that should make you rethink a promotion to staff.

Subscribe now

1. You Don’t Like People Management

While you wont have any direct reports, you’ll be spending time managing work with other people. Some examples:

• Helping resolve conflicts between engineers

• Improving morale after the team has gone through something tough

• Learning how to best delegate work based on someone’s strongest skillsets or their career goals

Because you work closer to individual contributors (ICs) they tend to trust you more than their engineering managers (EMs). Your EM will rely on you to help with things they may not notice as easily as you.

2. You Want to Code Most of Your Day

For engineers, writing pull requests (PRs) can be the most rewarding part of our day. You feel accomplished and can visibly see your impact in moving a project forward.

While you might’ve prided yourself on execution at the senior level, at staff it’s your turn to take a step back and let the other engineers shine.

Instead of coding, you’re now finding ways to elevate those around you to move projects forward successfully. Writing too much code at this level likely means you’re ignoring the more difficult work that needs tending to.

3. You’re Not Interested In Company Level Goals

At staff+ you may become less connected to your immediate team. You’ll be attending more strategy level meetings with leadership in your organization/pillar. You may even have to jump around different teams depending on what the organization needs the most at the time.

If you prefer to focus on solely your team’s goals, senior might be the best role for you.

There’s a reason why senior is the terminal level at most companies. It’s a completely different role than staff+ and it’d be unreasonable to require senior engineers to completely change their way of working.

So before you embark on this 2+ year journey to get to staff, ask yourself, is this the right role for you?

Thanks for reading!

Eden xx

Subscribe now