The medium is the asynchronous message

Hey, what’s up? If you’ve worked in any kind of tech organization since 2013 or so, you’ve probably been using some kind of chat application for work. It doesn’t matter which chat application you use, you’ve probably been in one of the following scenarios (as Alice or Bob or both):

In the first scenario, Alice sends a message to Bob. Bob is away from his desk and doesn’t see the message for a while. By the time Bob responds, Alice is also gone. Two messages have been sent but no useful information has been passed between Alice and Bob. Only the 3rd message, delayed by who knows how long, is actually useful.

In the second scenario poor Bob happens to be available when Alice sends him that first message. He responds promptly only to wait while Alice types her message (and deletes and rephrases etc.). Again, only the 3rd message was useful, but we get the added bonus of letting Bob stare at “Alice is typing…” for a couple of minutes.

#nohello

This common interaction has birthed the unfortunately named #nohello movement, which begs you to just ask the question and not just Hello (also called naked ping).

nohello.net explains it best, I suggest you head on over there if you're not already familiar with the concept.

I say #nohello is unfortunately named because the name implies that you shouldn’t start with any greeting, which feels impersonal and not particularly nice. However, even when #nohello advocates explain that you can and should start with a polite greeting, some people insist that getting down to business without waiting for the mutual exchange of hello first is impolite at best, or at worst an indication of the imminent collapse of human society.

It might be interesting to note that it's never the people on the receiving end of a greeting + context message who are complaining about the sender being impolite - it's always the senders. Just saying.

To be honest, I understand why people wouldn’t think of #nohello on their own, but for a few years now I’ve been wondering why people who are exposed to the concept keep sending naked pings while maintaining that is the superior approach. I think I’ve finally figured it out:

Chat is a hybrid communication medium with both a synchronous mode and an asynchronous mode. This duality is causing people to apply the wrong communication protocol.

100% synchronous mode

Let’s look at a 100% synchronous conversation – face to face or a phone call. A normal face to face interaction starts with a mutual greeting. At this point a “session” is established, it would be really weird to suddenly walk away. Now there might be a polite exchange where Alice might not necessarily be interested in what’s actually going on with Bob, but protocol demands it – that’s just how polite conversations go. Now Alice can get to the point and ask Bob for what she actually needs from him. Ending conversations is an art in itself, but once Alice and Bob have determined the conversation is over there will be an exchange of bye-byes and both parties will walk away feeling just fine.

100% asynchronous

Another commonly used form of communication is email (or real mail, with a stamp and envelope). This type of conversation is 100% asynchronous – so while some people might expect a relatively fast answer, they don’t expect it to be instantaneous. In this mode of communication there is no “session” established at any point, and the way the message is written reflects that: It starts with a greeting, moves on to the content, and ends with a signature, signing off on the entire message.

Responses may be a bit less formal, but they will follow the same general structure – greeting, content, signature, all in the same message. No one feels that this is impolite.

Async-sync hybrid

Now, let’s revisit what happens when we use chat at work. Alice wants to be nice, so she is applying the 100% synchronous protocol to her chat conversation with Bob, and is waiting for him to respond to her greeting before getting to the point.

As we can see in the image below – if Bob is away, the first part of the conversation is asynchronous. It doesn’t make sense to greet someone who isn’t there and then wait for an answer before proceeding.

By the time both Alice and Bob are around and available for a synchronous conversation – the “polite” part of the conversation has been entirely forgotten. Even if we didn’t care about wasting valuable time, the value of this kind of human interaction is questionable.

In the case where Bob happens to be around when Alice sends him that first hi and responds immediately, he still has to wait for Alice to finish typing whatever it is she actually wanted. Besides typing being much slower than speaking, it includes an inherent (asynchronous) delay – Alice won’t send the message until she’s done. So, while she’s applying the 100% synchronous conversation protocol – she’s actually leaving Bob to wait for many eternal seconds with nothing to do. Imagine if you called someone on the phone and then stayed silent for 30 seconds while you thought about what you wanted to say. Interrupting someone just to make them wait would be considered pretty rude.

Why #nohello works

What #nohello does is apply the asynchronous conversation protocol while the conversation is asynchronous. Note that it’s not as asynchronous (nor as formal) as email – we don’t usually end a chat message with a signature – that would suggest we’re not expecting to establish a session at all.

Once a session is established (both Alice and Bob happen to be around), the conversation can switch to synchronous mode, with its own special social rules. Short messages, lots of emoji, an informal tone. A nice example of this type of “rule” is the emoji reaction – it enables Bob to signal to Alice that he’s seen her message and acknowledge it without interrupting her by calling her attention back to the conversation (imagine calling someone to say goodbye).

Personal interactions outside work are different - you assume that someone asking how you're doing actually cares to hear your answer, even if they're contacting you via text message. In this case, how close you are is all the context you need. Though, if you pay attention to how you feel when someone you're not particularly close to suddenly texts you - you're probably wondering why they're contacting you and waiting impatiently while they're typing and wishing they'd #nohello you next time.
If you want to take #nohello to the next level with work-friends: When all you want is to say hello, be explicit about it. I will often message a work-friend to say good morning and include I don't need anything, just saying hi in the same message so they're not left with the burden of wondering if I'm waiting for them to respond before telling them what I want. 

I hope I have you convinced that #nohello is the polite (and efficient!) way to communicate via chat in the workplace, or at least gave you some tools to convince others of the same. Thanks, bye!

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