From Braille to Global Teams

TTL 12

Distributed work, a family tradition since 1982.

👋 Good Morfternight, this is Paolo Belcastro, with the twelfth issue of TTL: Tools & Thoughts for Leaders, your weekly leadership fix.

These days, everyone’s talking about distributed teams—and yes, that includes me.

I’ve written and spoken about it a lot, but more importantly, I’ve lived it.

My parents were remote workers back in the 80s (crazy, right?), and I built my own distributed team in 1998, much before the trend took off.

In this episode of TTL, you’ll find two things:

• Practical tips and tricks for managing distributed teams—because it’s helpful.
• The story of how I stumbled into the world of remote work—because it’s fun.

Ready to dive in?

A Family Tradition Since 1982

Some people learn from their parents how to carve wood or read poetry—I learned how to work remotely.

My parents were doing it way back in 1982, long before the internet, Zoom calls, or digital nomads.

They weren’t working from laptops in cozy cafés: they hand poked holes into cardboard.

Why?

My piano teacher, who also happened to be my father’s best friend, was blind. To stay in touch, my father learned Braille so he could write him letters. Music is also transcribed in Braille, of course, but

For two people (my mother soon joined), it would take an entire month just to produce a full piece of Braille sheet music.

They used a Braille typewriter with six buttons, each representing one of the six dots in a Braille character, plus a space bar. Every time you pressed a combination of those buttons, it would imprint the raised dots onto the cardboard. But that was just the beginning. That plastic sheet would then be layered onto a heated plastic sheet and eventually transferred to steel to create a mold for printing. Until then, though, the cardboard copy was unique, and extremely fragile.

Each month, my father would carry these carefully crafted sheets from our home in Genova, Italy to the SBS¹ in Zürich, Switzerland. Although the skill set was rare (scarcely any people in each country at the time could see, knew music, knew Braille, and had the ability to transcribe one into the other) due to Switzerland’s strict residency rules at the time, we couldn’t live there.

In 1984, we moved to the east of France, to be closer to the Swiss border where one of their colleagues would meet him. The final destination was still Zürich, but this was making each trip much shorter.

Fast-forward a few years, technology caught up, and with the advent of computers, my parents could now convert text into Braille on a computer, saving their work on floppy-disks, eliminating the need for long trips as those could be safely mailed.

As for me, from 1998, while building websites from Paris, I started outsourcing development to Asia, and design to South-America.

Shortly after, I began renting servers in US-based datacenters.

It wasn’t just a cost-cutting measure; it was about freedom. I realized I didn’t need to be tied to Paris at all. I could work remotely and still keep things moving. The world was already shrinking, but I was determined to work without boundaries.

In 2004, I moved to Switzerland, in a wink of destiny…

Distributed work isn’t just about necessity; it’s a philosophy of life that finds its roots in the idea that problems are much easier to solve by decoupling all the illusory dependencies that otherwise hinder us.

Some call it “going back to first principles”, and it should —and will— be an entire other issue of this newsletter, as the subject is truly important.

Now let’s get into the specifics.

A Streetcar Named Distributed Work

First things first, let’s clarify: today we’re talking about distributed, asynchronous work.

If the concept is new to you, or you’re curious about how it can benefit your team, dive into the newsletter where I break it all down.

The history of distributed asynchronous work dates back to the early days of computer networks and email in the 1970s and 80s, when remote teams started collaborating without being in the same place or working at the same time. By the 1990s, with the rise of the internet, and later cloud-based tools in the 2000s, this approach became far more common.

The pivotal point, in my opinion, can be tracked —like many other recent changes in our society— to 2007 and the introduction of the iPhone.

Think about it. Before that, and for the few decades where computer networks existed, our default status was to be offline. Eventually, one would sit in front of a computer, which could either be already connected, or required to dial in through a phone line, but the moment you left that desk, you were offline, once again.

Any experience of accessing the internet via traditional mobile phone was so unfriendly that Blackberry became a hit. Can you imagine a world where Blackberry is the best option to collaborate remotely?

I don’t need to imagine it, I was there.

From 2007 we flipped the paradigm on its head, now every one of us in online at all times, and going “off the grid” requires cautious preparation, even for a mere weekend.

It’s a streetcar, I was saying, that I don’t think will stop anytime soon—and its impact on work culture will be profound.

There are three ways to adopt distributed teams.

Lucky for you, there’s one wrong, and two right ways, and today I am going to tell you which one is which.

The Wrong Way:
One Time Zone to Rule Them All

Imagine this: your team is spread out across the globe, but everyone works within one time zone. Sounds convenient, right? Wrong.

While it works for short-term projects or teams that need tight collaboration, this approach often ignores the whole point of having a distributed team. If you’re forcing everyone to conform to a single time zone, you’re missing out on the flexibility and productivity gains that come with asynchronous work.

Why It is a Problem

• Either you’re pushing people to work at odd hours for no reason.
• Or you’re limiting your hiring pool by geography.

In the first case, burnout becomes a bigger risk because no one can stay on mismatched schedules forever, in the second, you are losing the opportunity to tap into a worldwide talent pool.

Fundamentally, you are trying to mimic a classic office with people all over the place. That is bound to fail miserably, as a regular office setup is a reaction to an ensemble of constraints, not an aspirational setup.

I loved how Seth Godin put that once (I am paraphrasing): Imagine if work had started distributed from the very beginning. Imagine a world where people can work from home, or from wherever else they wish. Now imagine if in that world, someone came up saying “Hey, people, I have this great idea! Let’s build giants skyscrapers, all in the same place, then let’s force everyone to come work from there so that they have to move within a reasonable distance from these buildings”…

See his point?

How dumb would that idea sound, if it wasn’t just what we are used to?

The Right Ways:
Time Zones as an Advantage

Now, onto the two good ways to structure your distributed, asynchronous team:

1. The Global Advantage

This is the dream scenario: you’ve got teams across the world, and you’re taking advantage of time zone overlaps. With just an hour or two of overlap each day between teams located in different areas, you can keep your work moving around the clock, with 24/7 customer support and faster project handovers.

This setup requires teams to be well-organized and communicate clearly.

When your team hands off a project in New York at the end of their day, it gets picked up in Berlin, and when Berlin’s finishing, someone in Tokyo takes it over. That’s a 24-hour work cycle with almost no downtime.

It’s the dream: progress 24/7 and improved documentation.

(If you’re still wondering why that’d be useful, you’ve probably missed out on this post about writing culture.)

Why it works:

• Faster turnaround on projects.
• Improved documentation.
• 24h support without stressful schedules.

2. Vertically Distributed Teams

Once your team grows, you gain new options. You now have enough people in each area that you can consider building synchronous teams.

Synchronous teams are still distributed, but each team is across a time band covering only from a couple to about four hours.

Think of it as vertical team distribution.

Here you don’t focus on projects moving forward 24h a day, but on enhanced collaboration coming from synchronous communication.

Why it works:

• It maintains the benefits of global talent, as time zones cover many countries, and you can still have teams all around the world.
• Creates smoother collaboration within each project team.

Not just time-zones,
but also time-preferences.

It’s not just about geographic location, but preferences

When we discuss distributed work across time zones, it’s not just a matter of where someone is based geographically, but also personal preferences and daily rhythms.

Let’s say you have a team member in EET and another in EST. In theory, with seven hours of difference, you can’t make it work. There’s no overlap.

But people have different rhythms, the person in Eastern Europe might be a night owl, while the one in the USA could be an early bird. I have lived through this exact situation in one of my teams, where these two people worked at the same time every day, despite seven hours of difference.

The idea is to balance both the practical time zone differences and the human element—understanding how people naturally work best.

This flexibility is one of the greatest benefits of distributed, asynchronous work—but it also requires a deep level of trust and communication within teams to make sure everyone’s pulling in the same direction, even if they’re working at different times.

---

That’s it for today.

If someone forwarded this to you, you can subscribe to get your copy next week. If you enjoyed reading this, please share it.

Here on TTL, we dig into practical leadership tips and effective strategies, with a particular focus on tech leadership and managing distributed teams (that’s what I do every day, add me on LinkedIn).

Whether you’re steering a tech startup or leading a remote team, these insights are designed to help you navigate the complexities of modern leadership.

Final word

I have been witnessing distributed work for more than 40 years, and have practiced it myself for the last 30. During all these years, I had a few short periods where I was going to an office every day, and I can easily say that, as much as I enjoyed the company, between the lack of flexibility, and the countless hours wasted commuting, I will never, ever, go back.

---

I also publish on paolo.blog and monochrome.blog

Cheers,

---

1. The SBS, or Schweizerische Bibliothek für Blinde, Seh- und Lesebehinderte (Swiss Library for the Blind, Visually Impaired, and Print Disabled), is a specialized library located in Zürich, Switzerland. It aims to provide barrier-free access to information, culture, and education for blind individuals, visually impaired, or have other print disabilities. ↩︎