I have lived outside the country I was born in for more than 17 years now.

When I lived in France, I eventually had a pretty good grasp of the language. I could give tech talks, write reports, talk to my coworkers, neighbours and friends — including casual banter and that sort of thing. I like to think that I actually fit in pretty well.

However, one evening I watched Qui veut gagner des millons? on TV, the French edition of Who wants to be a Millionaire. And I realized that I would not even be able to get through the initial round of quick-fire questions. Most of the time, I did not know the answer to the 500 euro question! The reason for that is that these questions rely on shared cultural understandings, such as that TV series everyone watched when they were a kid, popular books and snacks and the like. I grew up with different series. I have not watched many of the movies that “everyone” remembers from way back when, such as La cité de la peur or Le Père-Noël est une ordure. La classe Américaine was excellent though :)

Don’t assume cultural context when communicating

It is easy to take your own cultural context for granted. I see this all the time on the Internet, or at work. Yet, in a globalized world, this creates an exclusionary atmosphere, particularly together with a “What, you don’t know that? Come on!” reaction when this gets pointed out.

In my opinion, this is especially true for US culture. People keep showing me pictures of outrageously bad pop tarts, and I don’t know what a normal one is supposed to look like. People assume that I know who the cartoon character in their avatar is. And so on. Europeans generally don’t know these things, as they are not available in their country. I assume it’s the same for Asian people.

This goes in the other direction too, of course. There was a recent controversy on social media because an American influencer in Paris apparently discovered that French people put butter on their sandwiches. There was a lot of snark from other Europeans about how everyone knows this already and that this person was stupid, etc.

So, my tip for communicating (and writing docs or blog posts is certainly a form of communication too): Try to be mindful of your own cultural context that might not be shared by your readers or listeners. Don’t rely on it. And when you are called out for it, don’t double down and give a snarky answer. Be kind.

I recently made two LinkedIn posts about meetings. I thought it would make sense to reproduce them here for posterity.

Normalize ending meetings early.

If you have scheduled a 1-hour meeting but you are done with your agenda after 30 minutes, there is no need to scramble to think about more things to say. No one will judge you (hopefully) if you just end the meeting at that point and make a more productive use of the remaining time.

Unless you are interviewing a candidate, I guess.

Another post about meetings:

Larry Page, Google founder, famously wrote a memo on effective meetings. It contains the sentence:

“Attendance in meetings is not a badge of honor.”

This has resonated a lot with me. What it means is: when you realize your presence in a meeting is not needed, you find yourself disconnecting or even checking emails on your phone, then leave. Of course, if you know this before the meeting, then you can just decline the invitation. The hard part is getting out while you are sitting in it.

There are a few techniques to do this, such as simply saying sorry and leaving the room. It takes guts (and psychological safety!) to do that though. I know that some people who are on call have paged themselves to have an excuse to leave a meeting – that may or may not have been me at some point :)

Recently, I was thinking about one of my previous software development teams at work. Our program manager was a former Scrum master, so he taught us the basics of the Scrum method, which is one of the Agile development methodologies.

Now, the funny thing was that Scrum includes a number of rituals and techniques, and the book essentially states that you must do all of them or it won’t work; despite that, we used a subset and were somewhat successful with it. We also practiced continuous delivery by accident: because we didn’t use experiments or another way to gate new features, they became available to users as soon as they got merged, with the next daily release.

We decided to do two-week “sprints” (iterations). At the beginning of each iteration, there would be a sprint planning meeting where we decided on the tasks that should be done. Each task (= ticket) was assigned a size in story points, following the Fibonacci sequence, though without the use of cards or other nonsense. Someone just guessed a number, basically, and the others stated if they thought it was too low or too high.

At the end of the sprint, there was a retrospective meeting centered around three basic questions:

1. What went well?
2. What did not go well?
3. What do we want to do differently in the future?

If nothing else, these retrospectives are probably the best thing, and I will do them with any team no matter how they work. Some amount of introspection and thinking about your own performance and that of your teammates is definitely healthy.

Why do any of this?

It took me some time to understand the fundamental reason for following this model. That’s because the literature presents the wrong dichotomy.

In a project driven by software engineers, the natural state (if not following Agile principles) is not the Waterfall. It’s unstructured development.

What I mean by that is that the Software Engineers will work on whatever comes up, or seems important. Someone files a bug? It might just get fixed right away! There is a spontaneous hallway conversation about feature X? Let’s work on feature X then. This “development by Random Walk” seems convenient, but its results are not reliable. Worse, engineers tend to lose motivation over time, in my experience.

In our project, we had stakeholders (well, users) that wanted to see us chip away at the features they needed the most. In some cases, they were literally paying for it by providing headcount to my team. So the solution is to put the tasks with the highest priority firmly into the sprint. Then we assigned an initial task to each person, often by them picking up the thing that they want to work on most.

Micromanagement?

“But wait”, I hear you say, “isn’t this just micromanagement?” Why yes, it is. But crucially, you want to arrive at a point where the individual software engineer micromanages themselves.

The goal is really this:

• to get everyone to agree on a set of tasks that need to be done in a unit of time;
• to get everyone to state what they will be working on;
• and for everyone to actually work on what they said they would be working on.

That last point is crucial.

Non-Fungible Engineers

(Side note: I really wanted to use this heading.)

What did not work in our project was having extra, unassigned tasks for anyone to pick up that has spare cycles. Scrum assumes that every team member can do every task equally well; in practice, that’s just not true.

Every team member has a corner of the code that they are most familiar with. For instance, some folks may know JavaScript (and thus frontend development) better than others. Some folks may understand the monitoring and alerting configs and metrics better than others. Some folks are just plain uninterested in some aspects. Engineers are not fungible in general, in my experience.

Towards reliable delivery

Zooming out from the nitty-gritty of individual tasks: How do you motivate the team to reach a quarterly or yearly goal?

A failure mode that I see often is that a team with n engineers has n goals, one per person. At the end of the quarter, each goal is, say, 2/3 done. The team has worked hard, but nothing has launched. The stakeholders and the team members are frustrated.

What worked for us to get out of this hole was swarming: try to get as many people as possible to work on one set of tasks related to the same goal, finish it and launch. Celebrate the launch, congratulate folks, announce it far and wide. Maybe even give folks some swag, a cash bonus or something. The positive vibes increase everyone’s motivation, and the next thing might go even better!

If you overpromised for whatever reason, at the end of the quarter, you might have some things launched, one or two in flight, and some things not started at all. That’s totally fine. If stakeholders see progress somewhere, they are likely not very upset that the team didn’t get to the thing they wanted. It might just come a bit later.

In our case, we decided on two small features to work on all together. Each took about three weeks. They were the easiest things on our list, but the extra motivation from launching these made the team work much better and taught them how important it is to work together.