Work

How do you communicate effectively in an asynchronously setting?

This post is part 2 of a series:
Part 1: How to make remote work successful at your workplace?

Write everything down.

For an asynchronous setting, communication can’t happen live. Obvious — I know. However, we have such strong affinity towards live communication methods. Live chats tend to be “high resolution” in nature. We get immediate feedback. In-person (and video) brings more detailed signals from tone, expressions and body language.

Writing happens in low resolution. It tends to be one dimensional. Most of the time, not all recipients fully consume the written material. However, writing can be equally high impacting method of delivery in a distributed environment.

Some benefits of writing:

  • Allows for time to think and formulate more relevant messages (adjusting for tone, emotions etc)
  • Written discussions tend to be less circular
  • Better attribution of ideas and a means to sidestep strong voices
  • Searchable, making its impact long lasting — ideas are most impactful when someone is ready to hear it
  • Get time back by turning so many BS meetings into posts (example: “what shall we name this service?”)

Few tips from past learnings...

Placement & Format

Not all discussions should be had on Slack. It is important to think about where something should reside in. Use a variety of mediums. For example:

  • For guides / read-only pieces — Wikis and blogs do great
  • Discussions about specific work tasks — Trello cards
  • Big ideas that need shaping — documents, Miro boards
  • Sharing news, unstructured thoughts or rhetoric — team channels and emails

Something I often do with my teams is to write a “directional” post in a document and let them edit and comment over a week. Often, the draft sets up the direction and allow the team to tweak ideas and move towards something more widely bought into. One such example was “Our point of view on Agile practices”.

Another practice we had in team channels is to do more “social” chats around product ideas, debating about blog posts, sharing travel pix or building Spotify playlists together. We once had a 469-post thread for discussing Sausage & Egg vs Bacon & Egg McMuffins!

Also, more gifs and fun emojis.

Meetings

Try not to have them. Read more… Meetings are Toxic.

Some can’t be avoided. The issue in a distributed environment is that not all can be present. To combat that, most people record meetings. Thing is, not many recordings are ever viewed later on.

Public posts summarising discussion points, action items, decision points from meetings can go a long way in building trust and avoiding FOMO. It also means that there is a forum to discuss ideas missed out on or raising concerns that can undo decisions. Remember to allow time for people in other timezones to chime in.

Generally, asynchronous work places can offer more thinking and making time for all.

Leaders

As a leader, it is most critical that direction comes down in written format. Even in live setups, writing down direction does wonders. There is less ambiguity and messages lost in translation.

I write biweekly a posts to the team about what is happening in the background. They include things the company is worried about, concerns I’ve heard about, achievements etc. These keep people connected to what is happening.

More casual, candid style writing helps the team learn about the leader and their motivations. Robotic, corporate statements don’t inspire.

Open Slack debates also become a place to set up culture. Encourage people to disagree with you and when they do, praise them. Micro-moments where candid conversations happen can set the tone for how the team works. Written format is great for these as these moments last for much longer.

Concluding thoughts

Building a culture of written communication takes time and effort. Many can’t immediately see the impact of pushing for these. I’ve had many debates over why it is so much easier if we could just turn around and talk to someone instead of having to “type shit out”.

Yes, it takes more effort. At first, you may find yourself having monologues on Slack channels with many readers and no participants. People will contribute eventually. Active channels make for great meeting places to be social and get help from one another. It forms the basis for asynchronous work.

There is an asynchronous version of the team where they are more effective, collaborative and productive. It won’t matter where in the world they turn up to work from. Work can happen in true openness and inclusivity, where there will be so much learning and creativity.

It’s not a crock.

How to make remote work successful at your workplace?

You have to fully commit.

The whole world is going “remote”. But, it is hard to tell if imany places are finding success in a more distributed working model. It is a tough transition. Much of it is because most workplaces continue to operate with the same way they’ve always had. Somethings need to change.

First, we have to understand a small nuance. It matters whether your company is doing remote work within the same time zone or not. If your company has no location diversity, sign up for Zoom and Slack — you’re good to go.

For most places, remote is a chance to transition to more location diversity and offer flexible working conditions. Remote work can still happen “live” if everyone has a large amount of overlap. However, as more locations or flexible work hours come into play, “asynchronicity” start to be hugely important.

Asynchronous work is very different to how live work happens. Meetings don’t work anymore. Key players find themselves being needed all times of the day, which is super stressful. Answers aren’t always a call away. Traditional means for workshopping and collaboration just doesn’t work!

Leaders, especially, find asynchronous work really tough. It is a new level of trust (or lack of control). Most leaders have built their career on being charismatic talkers. They prod, steer, influence and inspire their people through words… live. Asynchronous work means these things are no longer straight forward to achieve.

Only way to transition to working remote + asynchronously is to get onboard fully and lead the change. If the commitment is lacklustre, what you will find is that remote work has low yield. It will create a class system within the organisation. Priority and decision making will reside in co-located regions (“HQ” vs “remote” workers). It will naturally lead to the conclusion that remote setups don’t work.

To make an asynchronous workplace work, start by identifying what needs to be live. Be very selective. Live activities tend to be operational aspects of maintaining a product and management tasks like 1:1s. Think deeply about how to set these up in a distributed format.

For activities that don't need live interactions, start to formulate some basics around these:

  • How do you communicate effectively in an asynchronously setting? (Read part 2)
  • How do people find each other to collaborate?
  • How do you move fast in a distributed environment when decision makers aren't in the same place?

Hope this gets you thinking 🤔. I'll follow up with my thoughts on the above questions soon.

Thoughts on “Scaling Technology”

I had the privilege to take part a panel discussion on “scaling technology” for go1’s offsite. It got me thinking…

Software products are (usually) written to meet product outcomes. Initially, these outcomes tend not to include deliverables like “used by millions” or “developed by 1000s”. As a product grows and matures, these concerns start to bubble to the top. Sustaining growth requires businesses to take on “scaling” activities. They help build a lasting product.

Scaling tends to be forced upon a team on 2 directions:

  1. As market adoption increases, there’s more inbound traffic and opportunities. Product team will start to pile on new features to improve conversion and stickiness. Organisation may acquire horizontal pieces of technology to integrate and grow the business. With such rapid growth, software applications starts to breakdown under its own weight.

  2. With more customers, comes more funding and interest from the wider organisation. That means more developers start to push code into the mix. Operations start to slow down as overheads, dependencies and complexity of collaboration increases.

Scaling systems will both help continued growth and reduce some of these issues. Often, that’s not enough to be successful. We also have to evolve people’s mindset to support the growth in business (i.e. scaling people).

Scaling systems

This is a large topic. There are lots of books about achieving scalable systems. Here, I’ll focus on some ideas I’ve seen teams miss out on.

Scaling systems is a lot about having a strong architectural direction, aligned to business strategy. Where do pieces of your system go and how do they fit in? “Highly cohesive, loosely coupled” pieces that support where the business is taking the product.

The architecture cannot be “too clever” and should be easy to reason with. Sometimes, we forget that we will have more people with diverse skill levels working in the system. With more people comes more misunderstandings and confusion. Simplicity does well here… as long as simplicity doesn’t adversely affect the competitive advantage a business has.

One mistake I’ve seen made over and over is that we tend to design for the problems we face today. Scaling requires imagination and creativity to identify and agree on a future vision. This has to be done with stakeholders from other disciplines. Tradeoffs and constraints applied for future has to be made together deliberately.

Think about a road vs a F1 car design. What changes and tradeoffs are made to achieve the outcome of going around a circuit significantly faster? F1 car only carries 1 person. It has to have extreme turn around time when swapping out modules like tires and pieces of the body. It’ll support lots of configurations and costs a fortune to maintain and improve one. Scaling is a lot about trying to figure out how you can turn your road car to a race car.

Architecture should be thought as an organic/fluid element of the product. There is little chance that a living product reflect any idealised architecture design. Some parts will lag behind while others will evolve rapidly. That’s the nature of large software applications. Systems are always in motion, much like the business itself.

Think about where “rubbish is collected”. Every system produces waste as more development occurs. Waste usually floats to the top of the stack because these parts tend to be more volatile. Can you isolate areas of high waste production so they can be renewed with low friction?

Example of this is edge services (or backend-for-frontend APIs). Most changes goes into the edge to drive changes in clients. Overtime, they are natural places for bloat. They need to be regularly refactored.

Lastly, any new architecture should have an incremental migration plan. Businesses continue to operate and make money. This means that rewrites are expensive and downright dangerous. Go incremental. If you are not convinced, read the big redesign in the sky.

Scaling people

Scaling people is much harder. Even when the technology is thoughtfully designed, it may not yield good results if people didn’t learn to think from a point of scale.

All teams and companies have an equilibrium: a “default” mode of operation. New systems and processes tend to devolve back to the state of legacy systems when nothing’s done to move existing equilibrium state. Many disregard this as an issue because it is the current playbook to company’s success. Problem is, to make more money, to have scale, you have to move your equilibrium.

Example... You may build a new CI/CD system that takes an application from monthly releases to 15min. It is hailed as a victory for how quickly issues can be resolved in production. However, team’s scrum process may dictate that sprints can’t change after they are set every 2 week. This leads to bugs sit in queue for 2 weeks before picked up anyway. Team may decide it is not valuable to release all the time since the testers are over worked with hourly releases. Couple of mishaps have led to some bad performance reviews. Slowly, things move back to monthly releases. Pipelines degrade because speed is no longer a priority. PR sizes go back up since no one’s trying to push atomic changes to production.

The “way of work” has a direction, even if no ones designed it to have one. The way people work is what yields the system we are trying to replace. So we have to pair the system change with a people direction change as well. These changes have to compliment each other so we get the most out these changes.

Continuing our CI/CD example... Team may move to a Kanban model (or swim lanes for issues). Testers have to be integrated to the process in a different way. A new support process with daily triaging and SLAs will push the team towards monitoring quality. Reporting on revenue from customer value delivered may motivate the team.

On the thinking front, individuals can end up in 2 places.

  • People who have seen high collaboration at smaller scale would long for glory days of the past and continually fight for it to return. They’d want to work with a trusted few and smash out features like they used to — “who cares about design systems and business domains?!”.
  • Others will create hard boundaries in their minds and never go past to make outcomes happen. A lot of “that’s not my job” proclamations and meetings about “ownership”.

Neither of these help to achieve scale and get shit done. Most leaders lean on continuing to maintain hard boundaries and tinkering with process. These tend to have low yield.

Changing mindsets and how people think is the ultimate challenge for an organisation. Everyone has to be given a path to mentally transition from where they are to where they need to be.

…I am a frontend developer who had full autonomy to prototype and release a new UI patterns to production. Now that we are larger, customers need to have a consistent set of patterns to work with. This will help them navigate the product better. It is still important to innovate so I should discuss the new pattern with a designer to understand wider concerns. I should pitch my prototype as an opportunity to gather data on customer behavior. It will help us decide if we should deploy this pattern across the product to have wider impact than my single concern…

Elevating people who reflect the mindset required to achieve scale can help. Allowing them to take up leadership positions and making decisions can guide the rest of the organisation to see new thinking in action. It shift the organisational equilibrium quickly.


There is a lot more to changing processes and mindsets at a company. I’ve spent the last 5 years pushing for a new identity of “Maker” within Expedia to aid its transition. I hope to be writing about it more in the future.

For now, I hope these thoughts will help you scale your company better.

How to drive your teams to care more about operational excellence?

When an operational outcomes needs to be achieved, we are after a predictable and repeatable process. This means that we can’t approach the execution of these outcomes like a creative task, allowing makers to self-organise. "OpEx" is an area where rigidity helps.

We can approach "Operational Excellence" on 2 fronts:

  1. Leverage an operating model where people must care for operational outcomes
  2. Help your team empathise with pains caused by operational failures

Here are a few ideas that’s worked in my team. (We are a group of ~60 makers.)

For operating model…

  • We assign leads for each area for each area of operational need. Their role is to understand current state, discover growing pains and bring opportunities to attention. Additionally, this creates buy-in and leadership opportunities in the team.
  • Alerts on production is a must. We always have someone on the pager to answer alerts. The paged person also has the ability to disengage anyone from their work to resolve production issues.
    • We keep “2AM playbooks” documented for quick help for anyone getting alerts on how to diagnose common issues and how to reach out to partner teams.
  • We talk about our operational stats once a week in a forum to provide wider visibility to the team and stakeholders. Being open about our failures and state of affairs help everyone get on the same page about investing in operational outcomes.
    • We present metrics for performance, availability, incidents, time to react and resolve, traffic levels, bug counts and SLAs.
  • We classify errors and incidents into buckets. For example, incidents and bugs that have significant $ impact should be critical (if customers can’t purchase from your store, it would be significant).
    • We break our errors to critical, major, standard
    • All logged errors carry a similar classification. Alert on % of categories of errors vs traffic and tune them based on severity.
    • We create SLAs for different categories of issues. When certain areas of application health is low, we set quarterly goals to lower them.
  • Automation helps keep incidents to a minimum. We invest in some of these efforts regularly. Our recent effort has been to put automation on accessibility issues!

On the cultural front, we do a few things too…

  • Most teams talk about how they value quality. For me, the talk has to be met with real investment to show the team “we mean business”. One of our recent changes is to allow directors the ability to vary investment into support by pausing/delaying other efforts. There is no need to get higher approval to invest in keeping the production environment low on errors.
  • We help the team understand business value of errors. Understanding revenue impact can change attitudes towards bugs. We try to also look back on previous quarter to quantify how much value was restored or added with our support and platform work to aid in this space.
  • Everyone makes a big deal out of operational wins. The PR campaigns to showing off wins in support and performance gains outweighs most other things in the team! Encouraging positive behaviour always helps.
  • In recent times, we’ve done a lot of work to make mundane things like support feel a lot more meaningful. Instead of focusing just closing out issues, we give engineers time to investigate root causes and fix system issues. Repeatedly resolving the same issues wears everyone down.

Ultimately, as a leader, we must ensure our team delivers on an operationally excellent environment for the business to thrive. However, one thing I try to watch out for is that we continue to have a team that is not afraid to make mistakes. Having some of the operational pieces set allow more fearless tinkering and innovation.

Do "basics" well

High performing teams are about interperson chemistry that is built on a foundation of the “basics”.

Take sports for example.

Learning to play a sport require you to learn the rules and develop basic skills to play. For soccer, it would be passing, tackling, lobbing and shooting.

When you join a team, there’s drills, runs and short set plays. These are repeated over and over during practice. During a full game, these disconnected pieces mix together to form fluid play. Play together with your team for long enough and magic starts to happen — team members anticipate each others moves to outplay opposition.

Drills, runs and set plays allow you to improve and build on the basic skills: passing, tackling, lobbing and shooting. They improve player fitness and execution during gameplay.

The act of continually working on the basics seem to lead to continued advancement. This is an interesting idea as it would be easy to assume the opposite — to advance further, one has to work on increasingly complex drills. I think it comes down to the fact that most complex things are built up from very basic elements. The more confident and efficient we are with basics, the more opportunity we have to put them together to do complex things.

Therefore, I believe, basics and chemistry form important attributes for any team.

Chemistry can be a complex thing to establish, with time, environment and the individuals themselves. It’s a whole other discussion.

It is easy to establish basics when talking about soccer. What are the basics outside the context of sports? I’ve been trying to figure out what forms the basics for a software engineering team. Is it design patterns or code reviews? Is it practicing readiness to production issues? Or perhaps, it is our ability to document and capture tasks in Trello? These seem to be the essential building blocks in a life of an engineer; solving problems by applying technical concepts into code, that outputs a product to deliver value.

Software is more than just code. At the heart of it, it is empathy and collaboration. It is a bunch of people, observing and acknowledging pain felt by themselves or others, deciding to take upon themselves to resolve that pain. Solutions doesn’t just come from one individual. It is the work of many, fusing their minds, disciplines and skills together to make something truly valuable. For me, the basics for a team are contained in these core values.

Basics has to be more around the idea of problem solving. That is all we do as a team, every day. Even our individual disciplines themselves are various ways dimensions of problem solving — research, design, engineering, analysis etc.

This idea became clearer when I recently read the book “The Culture Code” by Daniel Coyle. The book investigates the elements of highly successful groups. There is a great case study around Danny Meyer’s wildly successful restaurants. In a restaurant, how should one go about preparing staff for both conveying the right feel to customers and be able to react to new and complex issues that come up? It is impossible to cover all the bases and situations.

Danny uses the idea of “heuristics”. He captures the behaviours and his ideology in short, catchy phrases that are used in high frequency. Staff learn to apply these heuristics in every day complex situations, leading to very delightful customer experiences. Applying these heuristics seem to be the basics Danny get his staff to focus on.

These “heuristics” aren’t the same as rules. They are shortcuts for understanding and applying “guiding principles”. They convey a behaviour that is core to situations that arise in a restaurant environment. They allow staff to be thoughtful and creative, while being aligned towards providing customers with a unique, delightful experience.

Heuristics based in problem solving… these can be our basics.

Here are some ideas for heuristics I’ve been collecting with the help of others:

  • Just start.
  • Try and try again.
  • Optimise for fast recovery.
  • Act like it is your company.
  • Coaching over management.
  • Challenge assumptions.
  • Understanding the problem is half the solution.
  • Ask why.

“Just start” — we can apply this heuristic over and over in many occasions, whether people are stuck on a decision or unsure of estimates. It embraces the culture of a “maker” in having a bias for action.

Whenever someone asks me why we allowed a bug to go to production, I like to say: “Making mistakes is part of the job. We’d be better off if our system was optimised for fast recovery instead.”

We do workshops to help everyone understand how to write a good problem statement. Because “understanding the problem is half the solution.”

I believe that practicing these basics of problem solving can lead to powerful teams. They can provide the fundamentals that enable magic to take place.

Keep practising. Keep doing basics well.