Category Archives: work

When and how to say no at work

I used to get asked for help multiple times per week every week at my old job. Stuff like reviewing blog posts, giving talks, writing internal memos, attending recruiting events, calling candidates (especially women), even mentoring new employees whom I’d never met. I was overwhelmed.

For a long time, I kept saying yes to everything because I wanted to look like a team player. But there were three major issues with my unwillingness to say no:

  1. I didn’t have enough time to focus on my own personal/career growth.
  2. Even if I managed to say no, it often took me over an hour to make my decision and figure out how to respond productively and nicely (because women have to be nice).
  3. I was taking up opportunities for growth and reputation-building that other folks would have loved to take on.

In this blog post, I’m going to talk about how I started holding myself accountable for saying no via my “no” tracker, the list of questions I asked myself in order to clarify my feelings more quickly, and how I kept conversations productive after saying no.

Continue reading

Leading through writing in software engineering

I published an article for LeadDev in May 2021 and you can find it here. Here’s a preview:

With writing on the internet, there’s a natural feedback loop: if your article is low quality, you’ll struggle to get readership and engagement, and you’ll self-correct for the next article to increase those metrics. Inside a workplace and at increasing levels of seniority, that feedback loop disappears. Your colleagues and direct reports are obligated to read your emails, so it becomes easy to mistake their readership as a sign of a good job. In reality, your colleagues may never tell you something as blunt as ‘I had to read your proposal three times to understand the point’ or ‘Oh, those notes? I just marked it as read.’

Your writing directly impacts the health of your team and the execution of your product. Confusion about the vision for the team and its mission, as well as the big picture of where you want to go, are all symptoms of unclear communication. As such, we should approach the writing we send to our colleagues in the same way that we approach building products: by putting the user (the reader) first and designing a great reading experience.

Head over to LeadDev to read the rest!

“Working with me” / README template for individual contributors

I keep a living document for my coworkers that covers the basics about me. I started the document at a time when I realized that I’d be going through several manager transitions in a short period of time and I wanted some control over how I was going to come across and what I’d say to each of my managers. Now I maintain the document because it turned out my teammates liked reading it too.

In terms of overall principles, here’s what I think makes a good README for an individual contributor (someone who is not managing people):

  • Keep it brief. This isn’t your Myspace profile. With this type of document, I think it’s hard to toe the line between demonstrating self-awareness and… self-absorbed preening.
  • Values and philosophies are best discussed verbally and discovered over time. Treat the document as a conversation starter, not as a series of essays.
  • There’s a difference between what people can learn from working with you over time and what you can state in a document like this. Even if you say things like, “I have no ego, feel free to call me out whenever”, no one will believe that until they get to know you. There’s no shortcut for getting people to trust you faster, so I try to stick to topics that I feel need to be covered up-front without the need for that kind of trust. (This is difficult with topics like “how to give me feedback”, but it’s a best effort kind of thing.)

In the rest of this blog post, you’ll find an edited version of my document in case you want to start your own.

Continue reading