Howto

How do you communicate effectively in an asynchronously setting?

in , , , ,

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?

in , , ,

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”

in , , , , ,

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?

in , ,

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.

How to create a great pitch video for your idea

in , ,

Creating a professional video is expensive and extremely time consuming. When done right, a video can be very effective in getting users and spreading your idea to a large audience. For a small startup, videos might end up taking their entire marketing budget! I’ve been exploring ways to pitch an idea effectively while keeping time and cash investment to a minimum. Here’s how I got a great video done in 2 days and $35 for AlwaysHungry.

 

Researching for great videos

Epipheo is a great place to start. There is no doubt they make the best pitch videos! They are fun, clear and informative. I love their focus on relaying an idea instead of showing feature X and Y of a product. Of course, these videos also cost around $20,000 to make (I asked).

Take a look at their YouTube channel for some inspiration.

 

Storytelling tools

I looked for a tool that might help me tell a story specifically. I found Adobe Voice!

Adobe Voice is an awesome app that focuses on just telling a story. It only allows you to use icons, graphics and pictures coupled with music and a voice over. If you have a wonderful voice and happy with very simple graphics, this is your stop.


A little more Jazz

I wanted something a little better for AlwaysHungry. So what is similar to Adobe Ideas but has much better animations, and gives you more control over your content? Keynote! Keynote has slides, animations, graphics and all the other bells and whistles you need for a basic video. It also has a nifty feature that allows you to export your slide deck to a movie (mp4 file).

What about the icons? I immediately noticed that Adobe Voice used TheNounProject icons. It just so happens that AlwaysHungry icons are taken from TheNounProject too!

I wrote a script. You have to write a script. It helps you organise your thoughts and keep your narrative concise. You can start storyboarding your idea as you progress the script. Here's the final version of my script: Video Script.

... 
[Subway icon comes in] 
you constantly end up eating the same old thing, because you are too hungry to make a decision! 
[tone and emotion we want to convey is that it’s a downer]
...

I used simple icons, text and graphics to come up with a set of slides on Keynote. I focused on creating slides that supported the ideas conveyed on the script, sprinkling in animations where relevant. All of this turned out to be an exercise in creativity: trying to use the most basic elements to tell a story. I believe this kept me true to what I was trying to achieve.

Additionally I added some screen recordings from my iPhone to show off the app.


Searching for a voice

The right voice helps a video convey its message really well. VoiceBunny has a large number of voice actors who posses many unique attributes. They will deliver audio recordings within a day or two. My script came to about $100 all up for a VoiceBunny job.
#protip: email their support and ask for a discount :)

Another place you can find voice actors is Fiverr. Freelance community has a lot to offer on the Internet. We found @drewthedj who offered to do the voice over for just… $35! As you might have guessed, we went with Fiverr.


Getting it right first time

If you have a small budget, you want to get this audio recording right the first time around. Here’s what I did:

  • I imported the movie produced by Keynote to iMovie.

  • I started reading the script out loud while continuously playing the iMovie file over and over. 

  • Each time, I would shorten or extend the length of a section, based on how long I took to read out the script comfortably.

  • Following these steps, I ended up with about a minute long silent movie. I went on to edit the script and iMovie project further to get it down to about 50 seconds. I found that people generally leave around 50s mark for other YouTubes I've made. 

I sent the silent movie to @drewthedj. Drew was extremely professional, sent me back files with these formats: WAV, MP3, and Video with audio + background music!!! Whoa! If you need some royalty free music premiumbeat.com is great too.

I went back to iMovie and synced the audio file with my video timeline. Exported the video at full resolution and… DONE!

 

Concluding thoughts

The AlwaysHungry pitch video only took a weekend to make and it turned out to be better than a lot of expensively made videos out there! It is really a matter of channeling your creativity through some of the basic tools available to make something awesome. Focus on what matters: conveying the idea. Don't get distracted with showing off everything you have to offer. Simple things are easier to understand.

How to make an Android App (video tutorial)

in ,

I did a brownbag session at Wotif office about how to make an Android app. It covers a lot of the basics of making an app with Android Studio.

This is an introduction session for Android. It covers the following:

  • Introduction to core concepts like: android building blocks, activities, intents, back stacks, services etc.
  • Covers project structure using Android Studio.
  • We create a basic app that downloads cat pictures from Instagram API.
  • Work with a ListView to display data.
  • Code is available at: https://github.com/dmendis/android-intro-cat-viewer
  • Cover some core concepts with resource folders in Android 

Resources:

Email me or leave a comment if you'd like to see more videos like this (much shorter ones).

Making Safari Suggested Passwords Sync with Chrome

in

With the latest OS X Mavericks, Safari browser introduced a very convenient way of generating safe, random passwords when you sign up for a new account with any website. I've started using this feature extensively. It syncs across my iPhone + iPad beautifully as well. Only problem is Chrome...

Right now, I have a manual solution. Turned out to be a little easier than I thought:

  • If you open up the Keychain app on the Mac, You should see two items of interest: "login" and "iCloud". Chrome picks up passwords from Login.
  • Go to iCloud section, arrange by modified date.
  • Select all the recent signups and do a CMD + C (copy).
  • Navigate to login section and do a CMD + V (paste). It's prompt you for your Mac password, go ahead and enter that.
  • Chrome should now pick up the passwords automatically, sync across to all your Chrome browsers from now on.