8 Things I Learned During 8 Years at Google

This year marks my 8th year working at Google. Throughout that time, I’ve been on three different teams and met a ton of smart people.

I simultaneously feel like I’ve learned a ton, yet, I have so much more to learn.

The lessons I’ve learned mostly apply at large tech companies, but many of the principles apply across the tech industry.

Anyways, enough with the intro. Let’s get into it.

1. Leadership is harder than it looks

When you’re fresh out of college, you assume that everyone else knows what they’re doing, including your manager.

Wrong.

My managers have always aimed to be good at their job. But, they’re also human. They’re caught between multiple projects and a large number of people with competing interests. They have limited energy and attention. They don’t have the same information as me or any of their other reports.

So, sometimes they make mistakes.

Furthermore, I’ve learned that you don’t have to be a manager to be a leader.

Imagine proposing an API change, convincing a senior engineer to approve the change, and getting a partner team to implement one of its dependencies. That’s leadership.

In that situation, you might have only spent 20% of your time writing code. Years ago, I would have been shocked if that happened to me. That brings me to my second lesson…

2. Your job is to solve problems, not to write code

During my first year in the software industry, I thought my job was right as much code as possible. I’m a software engineer, so that’s my job, right?

My job is to solve problems. If the problem can be solved with a smaller amount of code, that solution is probably better.

If the problem can be solved with a configuration file change, that’s even better.

If we can avoid doing any work at all, that’s the best solution.

I came to realize it’s worthwhile to do other tasks like meet with other teams, write documentation, and track project statuses in spreadsheets.

I went from “How do I solve this problem in Objective-C?”

To

“How do I solve this problem?”

To

“Do I need to solve this problem at all? And if so, can I do it in a generic way that requires as little effort as possible?”

I learned to tell my manager about the problems I was solving in our 1:1s. Sometimes it was a status report. Other times, I asked for his advice. This brings me to my next lesson…

3. 1:1s are useful (when done properly)

When I first started my job at Google, I thought that 1:1s were overhead where you have to talk to your manager. You provide some status updates, go through the motions, blah blah blah.

When done right, 1:1’s are actually a way to turbocharge your career development. I love using 1:1s to influence my manager and to understand how I can better serve the team.

I go into this in a lot more detail in How to Stop Having Sucky 1:1s. Check it out and tell me what you think.

In addition to one-on-ones being a waste of time, I also thought this other thing was equally useless…

Invited to another OKR sync? Boring…
Photo by Andrea Piacquadio on Pexels.com

4. OKRs are useful (when done properly)

OKRs are “Objectives and Key Results”. Basically, it’s a way of summarizing quarterly or annual planning. Here are some generic examples:

• Foo Service has improved availability by 0.5%.
• Foo Service has reduced latency by 10%.
• 40% of clients have migrated from Bar Service to Foo Service.

I used to think OKRs were a waste of time. This was because my first few teams at Google had no relation to our broader organizational OKRs. (Which was part of their downfall.) So my org’s OKRs had no relation to my day-to-day work.

But when done properly, OKRs are extremely useful. OKRs are used to focus the team on the most important pieces of work. If something’s not on the OKRs, it can probably be safely dropped (which also has the side effect of making someone mad. But that’s beside my point. See lesson #8 below.)

Of course, I don’t recommend sticking to a plan for the sake of sticking to a plan. OKRs are supposed to give you enough flexibility to achieve the goal without describing exactly “how”. For instance, if your OKR is “Foo Service has reduced latency by 10%” You might make a lot of small incremental improvements. Or, you might launch one big change that improves latency by 10%.

The other problem with OKRs is that sometimes your original OKRs no longer apply halfway through the quarter. For instance, you might start by reducing latency, and then get preempted by DMA. Now, latency is no longer an issue. Such is life.

Speaking of DMA and all its logging messiness, that reminds me of my next lesson…

5. Logging, metrics, alerting, and testing are way more important than I thought 

I used to think coding was the main part of software development. But there’s a lot of stuff around feature development that’s super important, too.

Logging and metrics are important because you need to know how users are using your feature. You need to know how your future is performing (e.g. availability, latency, SLOs, resource usage).

Alerting is important because you want to know when something breaks. It’s even better when you get to know exactly what change caused the breakage.

Finally, testing is important because it prevents bugs from happening in the first place. I wish more CS programs required students to take classes on writing good tests. Blanketing the codebase in unit tests is necessary but not sufficient.

This next lesson is completely unrelated to testing.

6. Dress for Success

The common Hollywood image of a software developer is a guy with a scraggly beard wearing a sweatshirt and gym shorts.

However…

Professionals have standards.

You’ve probably heard of the study where a group of doctors were divided into two smaller groups.

The first group wore white coats. They looked like professionals.

The second group were plain clothes.

Later, patients were asked to rate the competence of their doctors. The doctors who wore white coats received higher scores than the doctors who wore plain clothes.

This is a strange quirk of human psychology. People shouldn’t care how you look, but they do. You could be the next Alan Turing, but if you dress sloppy, people might not take you seriously, especially if you’re young or from an underrepresented group in computer science. 

So, I regularly wear clean slacks and a button up shirt during business hours. It doesn’t take longer than putting on a wrinkly t-shirt and basketball shorts. Maybe it doesn’t make a difference. But I look good, and it helps people see me as a professional. And when they see me as a professional, we act like professionals, and we treat each other like professionals.

And, if you work at Google long enough, you become a professional at this next thing: handling reorgs.

7. Reorgs can make or break your job (in the short term)

There are two types of reorgs.

The first type doesn’t affect you at all.

The second type obliterates your team.

You have no control over when or how reorgs happen. However, you can sometimes use them to your advantage.

I used to work on a product that leadership didn’t care about. For years, I struggled to convince partner teams to build features for us. No matter how hard I pushed, the rock didn’t move.

One day, we were unexpectedly reorged into another team. The team dealt with boatloads of uncertainty for months as we struggled to find our new identity and meaningful work. Several members quit or transferred to other teams (it was also COVID times, which was just weird in general).

But after the dust settled, I made the best of my situation. The new team had opportunities for leadership, learning, and growth. I was handed one task and turned it into a larger effort. Then I created a larger workstream to find and solve an entirely new class of problems. I liked my new project and eventually, I was promoted.

In a big tech company, I don’t think you should be personally attached to what you work on. Take pride in what you do, but don’t tie your self-worth to a particular project. Large organizations only give the appearance of stability, not real stability.

It’s such a strange paradox: despite being so secretly volatile, large organizations can also be incredibly bureaucratic and unmovable. Which brings me to my last lesson…

Trying to get another team to commit to a joint project is sometimes like talking to a brick wall.

8. Organizational challenges are (often) harder to solve than technical challenges

Technical challenges are easy. You can spend time writing code. You can throw more resources at a problem. Eventually, it gets solved.

With humans, things are a bit trickier. A very common scenario is this:

1. Imagine you use a tool called Foo.
2. Foo is owned by another team.
3. You have a small feature request for the Foo team. Other teams would benefit from this feature if it was implemented in a generic way.
4. You estimate it would take 3 months of work for you to build it. But, since the Foo team knows the system well, they could add it in just 3 weeks.
5. You ask the Foo team to add this feature. They decline because it’s not on their roadmap or OKRs.
6. You ask how you could get the feature on their roadmap or OKRs. They say they are only accepting feature requests from P0 client teams.
7. You are not on a P0 client team. You sigh and move on to another task or cobble together a hacky script that kinda sorta implements the feature in a very specific way.
8. No one else gets to benefit from your work.

Of course, challenges like this are just part of life at a big tech company.

---

I hope this article shed some more light on career development in tech. I’ll be reducing my frequency of publishing articles through the rest of this year.

In the meantime, make it happen.

Layoffs at Big Tech Co. (Humor)

You are an engineer at Big Tech Co. The company is continuing its annual tradition of layoffs.

“I’m really proud of all the work that you’ve done,” the CEO writes in an email. “The last few months have seen a series of amazing launches. We’re pulling in record profits. Also, we’ve made the very difficult decision to terminate some of our colleagues.”

Your coworker comes over to your desk.

“Did you see the email?” she asks.

You nod.

“How are you feeling?”

“I’m fine,” you say. She doesn’t believe you but she doesn’t say anything else.

You open your laptop and pretend to work.

Photo by Pixabay on Pexels.com

You are on an internal infrastructure team. You meet with another internal infrastructure team. You learn that their manager lost his job. You feel sad.

You consider starting to look for a new job. You think about interview questions and feel a deep sense of imposter syndrome.

“Do you think our team will be affected by the layoffs?” asks your younger coworker. You shrug and stare into the distance like Jay Gatsby staring at a lantern across the bay, except you’re staring at the MK just down the hall.

“We are a data-driven company,” says a PM. Data-informed, you think to yourself.

Saturday morning. You are at a public cafe. You overhear some people talking about the tech layoffs. “I don’t feel bad for them,” they say. “Most of those kids have never worked a day in their lives.”

You have a 1:1 with your manager. She asks if you have any questions about the layoffs. You pause for a moment. “No,” you say. You’re not sure what to ask.

Photo by fauxels on Pexels.com

“How are you doing?” asks Jimmy. An innocuous question. “I’m fine,” you say. He does not believe you. “Great,” he smiles sheepishly. “Perhaps you can review my design doc today?”

“You should feel lucky you have a job,” says your retired neighbor. He has not been on a job hunt since the Carter administration. You nod. “I am very lucky,” you reply.

A recruiter messages you on LinkedIn. You write a response, then delete it.

You meet with another internal infrastructure team. You ask about project Zebra, one of their P0 OKRs. They say it’s canceled. “Why?” you ask. “Not enough resources,” they reply. “I understand,” you say. You do not understand.

You open your IDE. You stare at the code. You open the email website. You stare at your emails. You switch back to the IDE.

“At least it’s not like covid times,” they say. You shake your head. “It’s not.”

You message your coworker to see if he wants to get lunch today. You see that he’s been laid off. You feel sad.

You hear rumors that the office in Bangalore is expanding while hiring is frozen in California. “I am not worried,” you say. Not much, anyway.

You see a snarky meme about the layoffs in a group chat. You laugh out loud but you’re secretly crying on the inside.

You have a team meeting with your skip-level manager. He asks if you have any questions about the layoffs. You pause for a moment. You shake your head. You’re not sure what to ask.

Photo by cottonbro studio on Pexels.com

Chad calls you from Costa Rica. “How are you doing, champ?” “I’m fine,” you say. “That’s the spirit,” Chad replies.

“A 0% percent raise is a good thing,” says your manager. You sigh. As soon as you leave the meeting, you crumple the comp letter and toss it in the recycling bin.

You see an email that says, “Sign up to host interns this summer!” Excited, you start filling out the application. The form says, “What months are you available to host interns?” The smile runs away from your face. You do not know if you’ll be employed this summer. You delete your application.

You review your resume. You haven’t updated it in four years. You make a halfhearted attempt to bring it up to date.

“Want to go to Mexico for spring break?” you ask your friend. “Sure,” he says. He pauses. “But shouldn’t you wait until you know you have a job?”

You have an org-wide town hall with your director. They ask if anyone has questions about the layoffs. You pause for a moment. You do not say anything. You’re not sure what to ask.

Photo by Luis Quintero on Pexels.com

You wonder if today will be your last day in the office.

“Was anyone on your team affected by the layoffs?” your colleague asks. You nod. She sighs. “I thought we were better than this.”

The IK4 migration is blocked again. “The engineer leading the IK4 migration for my team was laid off,” says the PgM. You nod. “I understand.”

You meet with your mentor. “How can I help?” she asks. You pause for a moment and look down at your shoes. “I don’t know.”

You open your laptop. You sigh.

You have lunch with Humayun and Jesse. You discover all of you got the same, standard rating in performance reviews. “Hmm,” you all say.

Friday evening. You’re at a party. You’re talking with someone and you’re having a good time. “What do you do?” they ask. “I work at Big Tech Co,” you respond. “Oh,” they say, and excuse themselves. You stand there, alone.

The CEO takes questions from the company as a whole. Someone asks, “Why?” The CEO responds but does not answer the question.

You log into your computer, once again. You scan your email and nothing says that you’ve been laid off. Yet.

Somehow, you are still an engineer at Big Tech Co.

4 Steps to Advance Your Career in Software Engineering in the 2020s

In the old days, your career path might have looked something like this:

1. Be born in the suburbs of a US city
2. Go to college (and pay for it with a summer job)
3. Use your dad’s network to get a high-paying white collar job
4. Maybe enjoy your job
5. Work there for 40 years
6. Retire

Today, careers are more like “Choose Your Own Adventure”. You have so many options, and you have the power to trace your path to a unique destination.

However, with great power comes great uncertainty. The path is unclear. Competition is fierce. And, different people want different things. How do you know what to do?

A lot of self-proclaimed gurus on social media like to shout the same platitudes over and over. “Work hard! Stay late! Take on more responsibility! #HustleGrindset”

While all those things are nice, they will not guarantee you the type of success you’re looking for. Following their advice will just burn you out. (And let’s be honest, a lot of those “hustlers” are just low-grade con artists that don’t know anything about software engineering.)

So, let me suggest four steps to advance your career in software engineering in the 2020s.

1. Know what you want
2. Create a plan
3. Move towards discomfort
4. Make it happen

1. Know what you want

So, the first step is to set a vision for your career. Think of this like a mini PRD for your ideal job. What do you value in your career? What do you want?

Here are some examples:

• Impact
• Achievement and success
• Work-life balance
• Learning and growth
• Social justice
• Money or TC
• Flexibility
• Location
• Company mission or product
• Vacation time
• Autonomy

None of these things are better or worse than the others. It’s all about what you individually value. In fact, you might value different things at different stages in your life. Ramit Sethi proposed this idea of career seasons:

In the season of growth, you are focused on advancing in your current track. For example, this is when a person strives towards promotion at their current job.

In the season of reinvention, you are switching jobs or industries. Think of an engineer who wants to become a product manager, or vice versa. Or think of an employee at a big tech company looking to work at a nonprofit.

In the season of lifestyle, you are pulling back from your career and focusing on other things in your life. For instance, if you just had a baby, you might want to take parental leave or work half-time for a year.

With that in mind, write down what you want in your ideal job (or even, just your next job).

Here are some simple, high level examples:

• I want to be an IC working on an iOS application while maintaining good work-life balance.
• I want to manage a large team and use my influence to drive change across an up and coming environmental nonprofit.
• I want to maximize total compensation while living in NYC.

Don’t feel pressure to write the perfect vision right now. The type of job you’re looking for can change over your life, just as the seasons change. A lot of engineers in Silicon Valley start out with no ideas except “Make a lot of money” and progress into the season of lifestyle as they get older.

Now that you have a clear vision, it’s time to find out how to get there.

2. Create a plan

The second step is to create a plan. Some people skip this step and dive straight into doing random things. They emerge from their frenzied cavern 3 weeks later, and they’re not any closer to their goal than when they started.

If you’re a top performer, you’re willing to take some time now to make things easier for your future self.

For instance, if you’re searching for a new job, you probably want to:

• Talk to people at different companies
• Study algorithms
• Practice doing whiteboard interviews
• Revise your resume
• Practice talking with recruiters
• Go to a career fair
• Send out job applications
• Practice negotiating your salary
• etc

If you’re aiming for a promotion, your company probably has a rubric. Or, your manager can tell you. Schedule some time to sit down with them in a 1:1, tell them in advance you want to talk about your career, and give both of you ample time to prepare. Together, you can create a plan that’ll give you the best chance of being promoted in an upcoming review cycle.

If you’re struggling to understand what to do next, set aside some time to write down what the problem is. Or, enlist the help of a mentor. Mentors are a valuable resource that can show you their path in the world of software engineering. One good conversation with a mentor can bring fascinating insights that you may never have thought of before.

But what if you’re still stuck at a decision point, or you are afraid to start? This brings us to our third step…

3. Move towards discomfort

Computers execute instructions without any emotion. A human being can understand what they need to do, and be emotionally opposed to doing it.

It’s perfectly normal to have part of yourself really want something, and have another part of yourself reluctant to do it.

Maybe you don’t know what to do.

Maybe the task at hand feels overwhelming. 

Maybe you’re afraid that you’ll try your best and fail, and you’ll have wasted so much time and people will think less of you.

To exit this loop, acknowledge the discomfort and move towards it. 

Top performers know it is necessary to experience some discomfort in order to grow. This applies to your career, fitness, allyship, relationships, and other areas.

Discomfort does not mean pain. Discomfort does not mean making thoughtless, risky decisions. Sometimes discomfort is just trying something new, even though you’re not sure if it’ll work out.

One phrase thrown around Google is “uncomfortably excited”. Such as “I am uncomfortably excited that our service is launching next month.” You can be both happy that something is happening, but also concerned about what might go wrong. This is perfectly healthy. In fact, being a little anxious about something is an indicator that you care about it.

You might also think “I’m not good enough to do this.” I would challenge that and ask “What makes you say that?” Oftentimes, there’s no “magic feather” that separates you from someone who already does the thing you want to do. If you really want something, and you’re willing to learn, why not give it a try?

Which brings us to the last step…

4. Make it happen

The phrase “Make it happen” encompasses a lot of ideas. It basically means “Put in the time and do the work.”

Take extreme ownership of your projects. Proactively remove blockers and do whatever it takes to make it happen.

If you can’t do it alone, find someone who can help. Whether it’s getting direction from your manager, asking teammates for assistance, or requesting features from an infrastructure team–bringing people together and persuading them to work towards a common goal is part of advancing in your career. You all succeed together.

After a long time studying or working on something, you might feel discouraged for lack of progress. If something is unexpectedly costly, it’s fair to re-evaluate the approach. Or, you may intentionally decide to shelve the project. That’s okay, as long as it’s an intentional decision. Sometimes, the best option is to stop working on the current project and work on something else.

“Make it happen” does NOT mean that you need to burn out. Working overtime can work in the short-term, but it never works in the long term. A slow but sustainable pace is better for your mental and physical health. In fact, it’s normal to take breaks. Use your vacation days and recharge.

If a particular company or position isn’t right for you, it’s okay to leave. A big part of your career is learning from your experiences. Sometimes what you thought you want is not what you actually want. I have more respect for someone who steps down from a role where they’re not happy, even when their transition involves losing status or money.

One of my old mentors at Google decided to stop being a manager and return to being an IC. He felt that being a manager was too stressful, and enjoyed being an IC more. It may have had negative effects in the short-term, but it was the right decision for him in the long term.

Another manager used to lead a team of 20 people. I could tell he was very happy with his job, but he intentionally gave up his position to move to a different country so he could live next to the beach and be closer to his family.

On the other side, I know another engineer who took a job at a new company in a foreign country. His new position had more opportunities for growth and better pay.

These are just examples of people who were not content with the status quo. They didn’t wait for their manager to do something about their jobs. They made a decision and went for it, even though it felt risky at the time.

At the end of the day, you’re responsible for your career. Not your company, and certainly not your manager. The world can be chaotic, but you’re not powerless. You have the ability to choose how to respond to difficult situations.

Now go out and make it happen.

5 Ways ICs Can Be Allies

You might have heard about DEI or allyship, and then not know what to do next. You want to help your teammates from underrepresented groups, but you’re not how. Or if you should.

Let me challenge that. ICs can be allies. ICs can advance DEI in your company, even without a big management push. You don’t have to do anything flashy or complicated.

Furthermore, being an ally is a continuous process. It’s not something that you can just learn in a day and be done forever. No one is asking for perfection. Good-hearted action with a few mistakes is better than waiting for perfection and never doing anything.

So, here are five ways that you can be an ally today, even if you think you’re “just a low-level IC”.

1. Compliment your coworkers when they do a good job

When someone does a good job, tell them. Give them a sincere, specific compliment based on something they did. And compliment them publicly.

This might sound like such a small thing, but it’s very powerful. People from under-represented groups (URGs) often get less credit for doing the same work as their peers.

Don’t feel pressured to give a compliment for the sake of giving a compliment. Cynical people will read this and think, “Fine, I’ll compliment Bob on his haircut,” or “Bob doesn’t deserve any admiration. He hasn’t done anything remarkable in weeks.”

That’s not the point. It’s more about attending a presentation, learning something, and then sincerely telling the presenter, “Hey Bob, I noticed you put a lot of effort into your presentation. The latency metrics you presented were very insightful.”

At a personal level, a genuine compliment brightens their day.

At a professional level, acknowledging a job well done helps to advance others’ careers. If Bob is excelling in his role, and everyone on the team agrees, the manager will see that as a positive signal. People that hog all the credit don’t succeed in the long run.

In addition to acknowledging others’ work, it is also important to be mindful of the tasks that are assigned to team members. Some duties are seen as less valuable, such as taking meeting notes. I call this “grunge work”.

Photo by Christina Morillo on Pexels.com

2. Establish a rotation for grunge work

Oftentimes, grunge work disproportionately falls to women. This can have a negative impact on their careers, as they may be seen as less valuable engineers than their male colleagues.

For example, one of the most common duties that women get handed is taking meeting notes. Having to multitask in meetings makes it harder for the note taker to contribute to the discussion. And unfortunately, taking notes won’t advance your career as much as improving your system’s API.

Instead of having the same person take notes in a recurring meeting, establish a rotation. Don’t allow excuses, either. If someone’s handwriting is “bad”, respond by saying, “No worries, this will be good practice.” Or if they don’t want to write by hand, they can type the meeting notes.

Pro tip: Being bad at something doesn’t mean you should never do it. In fact, sucking at something is the first step towards being sorta good at something.

This goes beyond taking notes. Other responsibilities often get shoved onto women’s shoulders, such as planning team events and scheduling meetings. You could roll the week’s team duties into other on-duty rotations, like bug triage or responding to client questions.

Hopefully your team does more than just grunge work. There are bugs to be fixed and features to be implemented, right?

3. Check that project work is equitably assigned

Most software engineers want to continue learning new skills and advance in their career. But if every bug gets assigned to the same person, the recipient doesn’t have time to work on new feature development.

When someone is stuck working on the same type of bugs week after week, they have no opportunities to learn something new. In fact, the team as a whole suffers because the team develops a silo and a single point of failure.

When bugs and projects are assigned, check to see that everyone has opportunities to develop new skills throughout the year. If you notice a colleague hasn’t been assigned a stretch project, talk to them. Ask them what they want to work on. You or them could take their requests to your manager.

The point of this is to keep the team happy and effective. You may not be the team’s manager, but you have a part to play in creating a culture of candid feedback and learning within your team. And another way to do that is to ask this next question.

4. Ask “How can I help you?”

One simple question is “How can I help you?”

Now the context around this question is not so simple. In order to receive genuine requests, the other person has to trust you. They have to believe that you’ll act on their response. And if they give you constructive criticism, you have to be able to nod and say, “Okay” even if you feel emotional in the moment. This is a very hard thing to do.

It’s funny: Everyone in tech wants feedback. but not everyone can handle negative feedback. Yet, negative feedback is so important for growth! Only giving compliments is doing your colleagues a disservice. It is possible to give negative feedback in a constructive, direct way that demonstrates good intentions. And if your colleagues cannot handle genuine constructive criticism, perhaps you’re in a toxic workplace and ought to leave.

Now, if you randomly go up to a colleague and ask “How can I help you?” They’re probably going to do one of two things:

• Give you a trivial request (“Uhh, can you review my CL?”)
• Make a joke (“Yeah can you grab a cappuccino from downstairs?”)

This question is best asked in a recurring 1:1. When a new engineer joins your team, it’s easy to schedule a calendar event like “Intro with Alice”. First, you meet weekly, then bi-weekly, and then just monthly or quarterly. And in each meeting, you ask “How can I help you?”

But what about your existing teammates? If you want, offer to set up informal meetings with each of your teammates once per quarter. As part of the agenda, ask “How can I help you?”

Some of your teammates will decline your invitations. Others will attend once, find you have little to talk about, and then decline future events. One or two teammates will find these meetings extremely useful. Those are the ones you want to keep meeting with.

And after each meeting, you get to work resolving their reasonable requests. This should take less than an hour per week. You should NOT do unnecessary work for other people. You should unblock them and connect them with useful information.

In addition to helping your current teammates, there is one more thing you can do.

This is just a stock photo. Who’s the mentor? Photo by Christina Morillo on Pexels.com

5. Mentor engineers from historically underrepresented groups

Mentorship is a valuable tool. Sometimes, people from historically underrepresented groups don’t have access to mentors.

Check if your company has an official mentorship program. See if you can mentor someone, and express interest in any DEI sub-programs.

The point is not to prioritize, say, Black women over other groups. But if a Black woman wants a mentor, one should be available just as easily as for a White man.

Local high schools and colleges might also have ways that you can talk to students. It could be as easy as a quick presentation slot at career day, as intensive as an after-school course during the fall semester, or even a part-time job at a university.

I have also found mentees through Reddit (I reached out) and LinkedIn (they reached out). One time, I even met a professor on the street and he ended up being a mentor for a short time.

Mentoring other people is not necessarily an allyship thing. In fact, these five things are just things that good teammates do.

---

There are lots of other ways to be an ally–everywhere from the interview process to planning offsites. I hope you can pick one thing from this list and put it into practice this week.

1. Compliment your coworkers when they do a good job
2. Establish a rotation for grunge work
3. Check that project work is equitably assigned
4. Ask “How can I help you?”
5. Mentor engineers from historically underrepresented groups

---

This article was inspired after reading Karen Catlin’s “5 Ally Actions” newsletter. You can find her at betterallies.com.

You won’t believe why I received this peer bonus

At Google, employees can give each other “peer bonuses” to recognize each other for doing outstanding work. All you have to do is open an internal website, type why the other person deserves recognition, and their manager will approve it. Then, Googlers reply to a big email chain congratulating the recipient on their award. Also, the recipient earns an extra $175¹. Pretty cool, huh?

It feels great to to receive a peer bonus. And, it feels great to acknowledge someone who went above and beyond. Usually, people give peer bonuses for fixing hard bugs, heroically resolving outages, or after completion of a big project. So, I was pleasantly surprised to open my inbox one day and find my strangest peer bonus yet.

The Story

About a year before I got this unusual peer bonus, a central infrastructure team reached out to me. My team uses their tools, and they wanted to make their tools better. They set up a monthly meeting with me with a very vague purpose and no agenda.

Here’s how these initial meetings went.

First, I would ask for something. Then, they would describe why it couldn’t be done, or mention that they have other things going on and won’t work on it. Meanwhile, some of the engineers on their side loved to show off their knowledge without actually solving any problems.

“If you don’t have time to do anything, why are you asking me for feature requests?” I thought to myself.

After yet another useless meeting, I decided to change things. I created an agenda with three items:

• Wins
• Updates
• Requests

In the Wins section, I put some positive things that happened in the last month thanks to the central infrastructure team’s tools. The meeting had devolved into too much complaining, So I thought we would start off on a positive note. And to be fair, the tools are useful–but when you ask “what could be improved?” people will concentrate on the tool’s shortcomings.

Next, I added an updates section. This is where we could provide updates on tasks from previous meetings. For example, if there was a project that was going to take 6 months, we could report progress, blockers, or ask questions about the project each month.

Finally, I designated a requests section. This is where we could provide feature requests to the central infrastructure team. What’s the motivation? Are there any alternatives available? Will a different feature make this problem obsolete soon? The best requests would get an official ticket.

With the feature requests tracked in tickets, I could then check on their state. If a future request was implemented, I could add that ticket to the Wins section for next time. We created a virtuous flywheel that kept spinning.

The Strangest Peer Bonus Yet

So that brings me back to the peer bonus. Months after implementing the new meeting agenda, the central infrastructure team found our meetings to be much more useful, especially compared to all the other clients they meet with.

So what was the peer bonus? It was “For being unfailingly positive and thanking people for the work that they’ve done” in our monthly meetings. It was certainly different than launching a feature or responding to an outage. I was quietly proud that I could change the way our teams worked together.

1. $175 USD in 2023. The value has gone up over time. ↩︎