Whatcha gonna do with a toxic colleague

This post is part of my mentoring conversation series which includes relatively short posts on topics that have come from a mentoring session. Often, these conversations produce insights which could benefit a wider audience.
Any identifying information is removed and I always inform participants before posting anything we talked about.

In today’s mentoring session we discuss what to do about a toxic colleague. That person that makes you feel small and stupid, maybe taking credit for your work and ideas, or “stealing” all the interesting and promotable tasks you were supposed to be doing, maybe just rude and unpleasant in general.

Hopefully you’ll never encounter one of these, but if we’re being realistic – you probably will. Unfortunately, they may exist even in the best of workplace cultures because their behavior is easy to hide. Often, their misconduct will be directed at those lower on the organizational food chain, and therefore the powers that be may be blissfully unaware. If no one tells them – how will they know?

Image by Vlad Vasnetsov from Pixabay
Continue reading

The floor is lava: a realistic approach to work-life balance

This post is part of my mentoring conversation series which includes relatively short posts on topics that have come from a mentoring session. Often, these conversations produce insights which could benefit a wider audience.
Any identifying information is removed and I always inform participants before posting anything we talked about.

In today’s mentoring session I addressed some concerns around starting a family while maintaining a tech career. While this post will focus on the specific challenges of pregnancy and raising children, some of the insights may be relevant to any kind of attempt to balance a career with other responsibilities and interests outside of work.

tl;dr: Balance is for people who don’t have a life or don’t have work. For anyone (everyone?) else – the most you can hope for is not to neglect either one too much.

The conversation started with the a concern specifically about how to manage the final months of pregnancy: Should she agree to reduce the scope of her tasks and responsibility? Should she start her maternity leave early? Does this internal debate mean she’s weak, and a man wouldn’t even consider reducing his workload just because he was pregnant?

Photo by Anrita1705 on pixabay
Continue reading

Silly Baboons, Stubborn Elephants II: Navigating Culture Differences Across R&D groups

In September 2019 I published Silly Baboons, Stubborn Elephants: A Product Engineer’s Guide to Working with Platform Engineers. Since then I’ve expanded my thinking on culture gaps inside engineering organizations and how they affect our ability to collaborate across different groups with different motivations and incentives into a talk, presented at Reversim 2021 conference (right before Omicron hit and everything shut down again for COVID).

The talk is in Hebrew, so I’ve included the slides and my speaker notes (with bonus content I didn’t have time for!) translated into English after the video.

Continue reading

This email should have been a document

Everyone knows about the terribly boring and ineffective meeting that should have been an email, but… Should it really have been an email? I’m not so sure. I think email in the workplace was fine when that was all we had, but that form of communication has outlived its usefulness and should mostly be replaced by other mediums. There, I said it.

Photo by Maksim Goncharenok from Pexels

Emails are traditionally used for 3 main purposes:

Continue reading

Tips for starting a new job

This post is part of my mentoring conversation series which includes relatively short posts on topics that have come from a mentoring session. Often, these conversations produce insights which could benefit a wider audience.
Any identifying information is removed and I always inform participants before posting anything we talked about.
Photo by Matt Hudson on Unsplash

In today’s mentoring session we’re helping someone who’s about to start a new job and is worried about onboarding. There is an infinite amount of content on how to start a new job and how to onboard well, so I’m going to focus on 3 tips:

Continue reading

Defensive estimations and time management

This post is part of my mentoring conversation series which includes relatively short posts on topics that have come from a mentoring session. Often, these conversations produce insights which could benefit a wider audience.
Any identifying information is removed and I always inform participants before posting anything we talked about.

In today’s mentoring session we’re dealing with a manager who doesn’t trust task estimations and asks to reduce them, resulting in stress and overtime. Add to that a feeling that you’re not keeping up with the tasks you’ve committed to completing… This is, of course, not the healthiest environment, but unfortunately, still quite common.

Photo by Tima Miroshnichenko from Pexels
Continue reading

Rubber duck debugging – out. Talking to a person – in.

If you’re part of the software industry you may have heard of rubber duck debugging. The idea is when you’re trying to debug an issue, you’ll explain it to an inanimate object and the answer will present itself. This sounds cute, especially if you visualize yourself speaking to a rubber duck, or teddy bear, or cat. But trust the software industry to find the dark side of any cute idea.

Photo by Quang Nguyen Vinh from Pexels

Many software engineers, particularly when they’re just getting started (but not only!) find it hard to strike the right balance between asking questions and figuring things out on their own.

First, they’re afraid of looking “dumb”. Second, many engineers convey (whether on purpose or inadvertently) that their time is too precious to answer “unimportant” questions. Third, often effective communication is neither engineer’s strong suit, and things may break down in that area.

Continue reading

How to write an effective design document

So, you’ve come up with a beautiful, elegant, solid software design. But to move forward you have to get it approved. And to get it approved, you have to communicate it to others. Because, unfortunately, having the idea in your mind is not enough to get it built as you envisioned it. Getting your design across effectively is not a simple task, and many software engineers are not skilled at it. But as most skills, your skill at writing design documents can be improved, I hope this post helps you on your way.

As we write a design document we should keep two main concerns in mind:

Purpose

In my opinion these are the three objectives of a good design document:

  • Get buy-in for the high-level architecture from relevant stakeholders (engineering managers, technical leaders, engineers from other relevant groups).
  • Provide a blueprint for implementation.
  • Provide documentation (for historical reference, onboarding etc.)

But most importantly: A design document may include a summary of requirements, if appropriate – but it should not read as a wishlist. Someone reading a design document should get a clear idea of what you are planning to do.

Image by Pexels on Pixabay

Audience

Who will be reading the design document:

  • People who need to approve/provide feedback on the design.
  • People who need to do the work outlined in the document.
  • The author (you’re not going to remember why you did any of this in a couple of months).

In addition to their role, readers may have varying context on the design:

  • Internal readers who already know the background whose memory just needs to be refreshed.
  • External readers or newcomers who have no or close to no context and need a high level overview of what this document will cover.

When we write a design doc we need to keep the purpose and the different audiences in mind so we can write the right thing in the right place at the right level of detail.

Now that we know why we’re writing a design document and for who, let’s get into what it should include:

Continue reading

Follow the technical road (in high heels)

Photo by Svetlana Boyko on Unsplash

Over the recent years we’ve seen an explosion in content about and for women in the workplace, and women in tech specifically. Broadly speaking, there are two types of approaches to this subject:

Play the game: Represented by the esteemed and critiqued book Lean In by Sheryl Sandberg, this type of content focuses on getting women to succeed within the existing framework, hopefully getting them into positions of power where they will be able to help others.

Smash the patriarchy: Represented by the 2020 book The Fix by Michelle King, this type of content focuses on highlighting all the ways the system is broken and has to change for women to succeed.

Smash the patriarchy is often opposed to play the game advice because they feel it’s literally playing into the hands of the existing power structures. While this is true in some ways, I personally think waiting for the revolution to come is not the best course of actions for all individuals, we should probably try to do both, in appropriate contexts.

There is a 3rd genre, represented by books like Brotopia by Emily Chang. This type of content can be summarized as “everything sucks, you’re not imagining it, it’s not your fault”. I’ve stopped reading this kind of book because I already know I’m not imagining it and it’s not my fault (though not everything sucks, at least not all the time), so I feel it doesn’t help me grow, it’s just depressing. This content is important to understand, but not for me, not right now.

Most of the content written about women in the workplace targets women on the management track. I think women trying to make their way up in technical roles face a unique challenge which is not being addressed yet. In this post I will try to share my perspective on some of the obstacles in our way and how to overcome them.

Continue reading

Going places: How to manage your career

After my last post on how I got my career back on track I was flooded with (at least 3) requests to share my advice on what I did to “level up” my work so other people could get ahead the same way.

The easy answer here would be “I can’t say”. Each person, each manager, each organization, each situation is unique and who am I anyway to be giving advice on things I’m still figuring out myself. That said, my “obvious” might be someone else’s “mind blown”, so here goes.

Photo by Nathan Jennings on Unsplash
Continue reading