Modern Tech Leadership

Note: I take no credit for any of this innovation; I’m just documenting it. Also, I am not officially speaking for Grab, and have not had this material reviewed by anyone there. But as the elder Mr. Renton put it, “It does a man good to cut loose once in a while.”

In 2018, Grab leadership found ourselves in a predicament: Millennials aren’t reading email. It took us some time to figure this out, since email has been part of the fabric of tech communication for decades. The old guard didn’t think of it as “optional”. But when we dug in, engineers told us that email just isn’t a thing for them anymore.

To be fair, email is a lousy communication mechanism. It presents various difficulties, among them being its upside-down threading model, the bolted-on attachments mechanism, the lack of inline comments, the impoverished tools for managing lists and subscribers, and other legacy cruft from when it was invented in 1971. It’s impressive that email lasted over 40 years before starting to crumble.

In addition to its usability problems, email also suffers from social problems. In fact email just may be the world’s most finely-tuned machine for pissing people off. Longer emails come across as manifestos, and even short emails can be perceived as hostile escalation or creating “us/them” divides. So it’s good that it’s starting to die.

In addition to the email situation, Grab faces no shortage of other interesting leadership challenges. The company has grown at breakneck speed and we have R&D centers in multiple regions, including Southeast Asia (SEA), Beijing, Bangalore, the US and others. Most of Grab’s attention is focused on a small number of mobile apps (e.g., passenger, driver, merchant) which surface hundreds or arguably thousands of features. This crowded space increases the need for the company to move and operate in total lock-step alignment. Teams at Grab cannot afford to ignore each other or work in silos.

But we are distributed across the globe, and more importantly across time zones. Google has by and large punted on this problem, by putting unrelated projects in separate regions, minimizing the need for teams across regions to communicate with one another. This strategy works well if you can get away with it. Companies with large horizontal portfolios can, but Grab does not have that luxury: We must act as a single team, which we call OneGrab.

Nearly all the ground I’ll cover today was invented chiefly by Grab CTOs Theo Vassilakis and Mark Porter in response to these leadership challenges, though of course there have been many other contributors along the way. This article is a snapshot of where we are today. We continue to refine it almost weekly, but I felt it was worth describing our work to date, in the hope that it will benefit other companies with similar challenges.

We also hope that the companies who are developing the leadership technologies we use (primarily Facebook, Slack, Atlassian, and Google) will double down and begin to address the shortcomings in their otherwise awesome technologies. Because as good as they are, they all have a long way to go.

In this post I’ll be describing four interleaved mechanisms that we have adopted, which form the core of our leadership communications and processes. Notably absent from the list are travel & videoconferencing. These remain the two most important levers for achieving alignment and goodwill across orgs, especially orgs in different geographies. But Grab has not been particularly innovative here, and moreover, neither travel nor videoconferencing is especially well-suited to multitasking: You can only squeeze so many meetings and trips into any one person’s schedule. So travel and VC are necessary but insufficient.

I struggled a bit with the ordering of the sections below, because the different mechanisms complement one another and create a virtuous feedback loop. The important takeaway is that there is a gestalt: The approaches I describe are all equally important contributors to how Grab is able to act in unison, as if the company were much smaller.

Before I move on to the new way we lead at Grab, I will mention that I just finished a 10-course Harvard Business School Online program, to which Grab has generously seen fit to send their leaders. Their videoconferencing (classroom) technology is the best I’ve seen by a wide margin. It shows there is significant room for improvement in the standard experience provided by Zoom, BlueJeans and their ilk.

Slack & Workplace Chat

Grab has standardized on Facebook Workplace Chat for communications. WPC is not a great tool, and we have many, many feature requests. But it has that “just good enough” property that enables us to be productive while wishing for more.

Grab Engineering also makes extensive use of Slack. Most engineers find Slack superior to WPC, with its denser information display, better threading support (though still not great; reddit is King when it comes to getting threading right), and its fantastic automation facilities. Indeed, we use Slack to our detriment in some ways, because many of our legacy engineering processes were built around Slack’s automation, and this is not a good use of Slack in scenarios requiring metrics and auditability. For instance, you don’t want to do bug and issue tracking in Slack, but to some extent we do exactly that. Fortunately we have begun to migrate that stuff to Jira.

Used properly, Slack and WPC (and similar systems like Amazon Chime and Mattermost) are far better communication tools than email. They all have the seemingly magical ability to remove the us/them barrier. I’ve thought long and hard about why this might be, and to be honest I don’t have much to offer you. They just work.

I suppose one big advantage of Slack/WPC (just “WPC” from here out) over email is that the notifications are ephemeral. Email notifications stack up in your inbox, often simply alerting you that you have a message or task awaiting you somewhere else. Email has devolved into what is essentially a poor man’s feed for your other, better channels.

But even if you filter out mundane notifications, WPC is still better. It has an immediacy that mimics face-to-face conversation which doesn’t exist in email. I think that is probably the secret sauce. It encourages succinctness, multi-way dialog, and continuous feedback — for instance via emojis, which are the online equivalent of body language.

Since they all have that critical property of immediacy, today’s crop of chat apps are very similar. They seem to differ mostly in their ability to let you manage hundreds of simultaneous conversations seamlessly. I think whichever one gets this right will win. Slack has the edge today, but the state of the art keeps improving.

Grab has not done much in the way of leadership innovation with chat apps, with one notable exception: Escalations. Escalating is a somewhat touchy subject in any organization, but in Asia it is particularly sensitive. If you escalate incorrectly, it can be perceived as anything from a mild breach of social etiquette to an all-out attack on the individuals involved, or anywhere in between.

We found through trial and error that WPC can be used to escalate without incurring this perception, or at least it keeps it to manageable levels. If you are having trouble getting alignment with some other individual or team, especially at another site, the protocol we have settled on is simple and effective. Just create a named WPC group about the issue, add the stakeholders, and gently ping them with the context, often by way of links to other documents. If they do not respond (or you cannot achieve resolution) in a reasonable amount of time — typically 24–48 hours — then you add their manager(s) and re-ping. We don’t know exactly why, but this isn’t generally perceived as an escalation. In fact, often people feel that they are unable to achieve alignment without bringing in their management chain (for example, because of conflicting business objectives). WPC provides a straightforward mechanism for escalating without the perception of hostility.

We also use Facebook Workplace, but I think it has been less transformative for Grab’s leadership. It is a nice forum for posting links to articles, or various kinds of announcements, but if you aren’t a FB user (yes, we exist) then it can be a bit overwhelming. Most Grabbers probably look at it roughly daily, whereas we are active on WPC around the clock.

WPC and friends need a LOT of improvement. And actual FB WPC lags far behind Slack in terms of features. But they are all vastly superior to email for 90% of communications, because they aren’t inherently prone to pissing people off. And for the remaining 10% we have GSuites, which I will cover later in this post.

Grab Mental Model (GMM)

Theo came up with what may be the most innovative addition to our leadership portfolio with the introduction of what he termed Grab Mental Models (“GMMs”).

A GMM is a document which explains how we have decided to approach or think about a particular class of problem at Grab. GMMs are typically 3–10 pages, though there is no hard and fast rule. As of this writing, we have over 150 GMMs in various stages of ratification. A GMM should focus on a single topic, and should be split into multiple GMMs if it gets too long.

GMMs are versioned and make their way through a lifecycle whose states currently include IDEA, DISCUSS, REWORK, AGREED, ABANDONED. Every GMM has a single Person In Charge (PIC). The GMM header includes semi-structured metadata, including its current lifecycle state, the list of stakeholders who need to review and ratify it, whether the review period will auto-timeout and auto-agree, and other relevant information.

A GMM should be self-contained: Any employee should be able to sit down without prior context and be able to figure out what the GMM is about. This generally means that GMMs include plenty of links to supporting documentation, glossaries and the like.

We have standardized on Google Docs as the medium for GMMs, primarily because its inline commenting facilities are dramatically better than those of, say, Confluence (our wiki of choice). Ratifying a GMM may require many rounds of commentary and response from the organization, so comment management and history are paramount.

How do you decide whether a particular topic merits a GMM? Every new GMM incurs nontrivial overhead for the org, so you should be careful to make them only when you need them. Creating, refining and ratifying a GMM takes a lot of time from leadership, and each GMM also increases the amount of information that people need to be aware of and absorb.

Our 150+ GMMs cover many topic areas, including but not limited to:

• Financial processes (e.g. procurement, headcount budgeting and trading)
• Operations processes (e.g. postmortems, run books, incident response)
• Engineering processes (e.g. code reviews, testing, issue tracking)
• HR processes (e.g. interviewing, internal transfers, corporate culture)
• Partner engagement (e.g. data sharing, external APIs)
• Leadership processes (e.g. meetings, OKRs, escalation, information cascading)

GMMs provide many benefits, though those benefits were not all immediately understood by all Grabbers when we first introduced them. To help, we created a meta-GMM at go/gmm (see below), which explains the rationale, and outlines the core framework for creating new GMMs. We worked to evangelize GMMs within the company. In time they became the bedrock of our leadership approach, by bringing rigor and standardization to the way that we think about potentially contentious or confusing processes.

One key benefit of the GMM is transparency of decision-making. Employees tend to find it frustrating when they do not understand the decision process for a given domain. GMMs provide visibility into the underlying thinking.

Another benefit of GMMs is fast onboarding. You can point a new engineer or PM at a set of important GMMs, and in half a day they will understand how Grab does things, and how it might differ from the way other companies do them.

Yet another benefit is consistency: In many cases, it doesn’t much matter how you do something, as long as everyone does it the same way. Performance evaluation is a good example.

A GMM is generally not intended to be a how-to guide, although the GMM should include links to such documentation. GMMs may have lists of Do’s and Don’ts, but if the topic at hand is large enough to fill a book, then they should push most of the supplemental information into links. Most GMMs should not take longer than 10 minutes or so to read.

GMMs are generally prescriptive, although at Grab we divide them into binding and non-binding, the latter being recommendations rather than policies. For a binding GMM, teams must go through an exception process if they wish to deviate from it.

Internally we recommend that GMM authors include a 3-minute video introducing the topic, at the top of the GMM. This is for the benefit of busy millenials for whom those extra seven minutes of reading would prove unduly onerous.

In some ways, GMMs act a lot like laws. It’s OK not to read them or understand them, as long as you’re not violating them. And they provide a convenient way to show people when and how they are in violation (particularly when combined with go/ links, discussed last) so they can get into alignment.

GSuites

Theo brought discipline around G Suites (which we always mis-type as GSuites so I’m going to keep doing that) — mental models and best practices around our use of Google Docs, Google Sheets, Google Slides, and Google Drive. Mark Porter, in turn, has been the driving force behind refining those best practices, both company-wide, and also tailored to specific settings such as his weekly senior leadership meeting. Together, Mark and Theo have pushed GSuites perhaps a bit harder than Google intended, but the results have been spectacular, right up to the point where they shut down from overloading (usually during our quarterly leadership conferences).

I suspect it doesn’t matter how you’re disciplined in your use of GSuites, as long as you standardize that usage across your org. Some important considerations are:

• Structure — How the document should be structured, no matter who is writing it. For instance, for Google Sheets, which we refer to internally as GXLS, we always have a README tab with metadata about the spreadsheet. For GDocs, there is a specific header and a version table at the bottom.
• PIC — We insist on having a single owner for every document, so that ownership isn’t diluted.
• Versioning — Documents are often agreements, so you can’t change the document after teams have agreed to it. Versions are a solution to this problem. The team agrees to v1.0 and then you can rev it and seek further agreement.
• State — Some kinds of documents (e.g., GMMs, or team-meeting agenda docs) may have specific states they can be in. For agendas, state might include who is the note-taker for the following week, if you are doing it as a rotation.
• Type — Whether the document is binding or advisory, possibly with gradations such as “strongly advised”.

Our GMM for GSuites is currently about 12 pages, putting it a bit on the long side. It includes collaboration models and protocols for inserting, replying to and (importantly) resolving comments from others, handling action items, assigning sharing and editing modes, using naming conventions, and many other potentially mundane but important topics. By standardizing these things, our docs and sheets become more accessible and easier for many collaborators to manage simultaneously.

Probably the most important use of GDocs is to act as an alternative to email for those 10% of use cases I mentioned above for which chat apps are unsuitable. If you have a long topic with significant background information, and you are seeking alignment with others, then you should put it into a GDoc and ask for commentary. As a rule of thumb, if your email runs longer than about 2 paragraphs then you should strongly consider moving it to a GDoc. Your readers will be far more forgiving, even in the face of controversy, if they have an opportunity to comment inline.

GSuites (ironically) suffer from a search problem, so we have borrowed another Google technology to help solve it, next up.

go/ links

Google has an internal corporate tool called “go/ links” which enjoys immense popularity, but which, like many wonderful things at Google, is neither open-sourced nor provided as a service, paid or no.

So at Grab we just wrote our own. My buddy Nelson Araujo implemented v1 in a weekend, and it was an overnight success, with hundreds of go/ links emerging in presentations and other documents within a couple weeks. Nowadays they are ubiquitous.

The idea is simple: You can create a named alias for any other URL, which you can then access by typing “go/my-custom-alias” into your browser. This is more or less the same as tinyurl’s custom alias facility, except that by having it in-house you can implement all sorts of policies and layers specific to your company.

For instance, you can decide the process by which someone can “take over” someone else’s alias and point it somewhere else. At Google you must beg the original owner to release the link, which can get tricky if they’ve left Google; whereas at Grab we settled on trust-first and allow links to be edited by anyone, with audit logging in place.

One great thing about go/ links, IMO — although not everyone necessarily agrees with me — is that you can have multiple aliases for the same target, so you don’t need to remember whether the link is go/myproject, go/my-project or go/my_project. But you can also solve this problem with better autocompletion, suggestions, and search, and maybe a few naming conventions. The great thing about go/ links is that you can customize everything for your organization’s needs.

go/ links lose much of their effectiveness if you have to type in a fully-qualified domain name such as “go.grab.com/whatever”. There are various solutions to this problem. You can use DNS, or route your traffic through a proxy, or create a Chrome browser extension that calls the service to rewrite your URL. The extension is the quick-and-dirty way to get it into your org with minimal fuss, and you can iterate with your IT folks to make it better, e.g. for mobile iOS users who don’t have access to Chrome extensions because Apple is a bunch of meanies.

Regardless of which mechanism you use, it’s safe to say that go/ links are severely limited unless you can literally type “go/myalias” into your URL bar, so pick a solution and run with it. Then you’ll want to add in searching, metadata (e.g. link descriptions for the search results), history, and other features as needed. We have a big backlog of feature requests, since they are very popular.

Once you have go/ links in your org, you’ll find yourself wondering how you ever lived without them. Amusingly, for ex-Googlers at Grab, among all Google’s amazing internal technologies we missed go/ links the most.

Yes, it’s ironic that I complained that Google didn’t open-source it and yet we haven’t done so either, at least not yet. Grab is taking go/ links much further than Google did (at least as of the time I left Google in early 2018), and we have months of feature work queued up. Maybe someday. Or maybe you can do it first, and become internet-famous!

Other stuff

We use Atlassian’s Confluence for the majority of our internal documentation. Confluence is a solid wiki, famous for being perhaps the last tech stack that still incorporates the powerful 1996 AltaVista search engine (“4 gigabytes of RAM can’t be wrong”). I would not say Grab has innovated with our use of the wiki, but we do dump information into it like needles in a haystack the size of a small football stadium. And despite Confluence’s inability to find anything ever using the search box, it does feature some lovely editing capabilities (inline images and comments in particular) which make it sort of less bad than a lot of other wiki options.

I’m not sure I would go so far as to recommend Confluence. We go back and forth internally about whether we should use Confluence or GSuites for various things (including GMMs). Organizationally, Confluence has the advantage of enforced document hierarchy, whereas GSuites has only the incredibly annoying Google Drive mechanism for organization, which combines the power of S3 buckets with the usability of S3 buckets. Neither solution is a clear winner.

In addition to Confluence, we use a bunch of other tools and systems, e.g. Jira, Concur, JumpCloud, Oracle ePR. I think they all contribute, but with diminishing returns on our actual leadership processes. I suppose we have to include Datadog, since we stare at dashboards all the time. But most of our leadership is conducted through a narrow set of channels: WPC/Slack, GSuites, GMMs, videoconferencing, and old-fashioned travel & f2f meetings. Email has been relegated mostly to serving as a feed for notifications and occasional newsletters.

Putting it all together

I’ve given you enough context that I can now conclude with a bit of discussion around that gestalt I mentioned earlier.

Once you’ve established these four mechanisms, you’ve basically solved the global 24x7 multi-time-zone leadership problem, at least better than I have seen it solved in the past. Even though group chat apps are asynchronous, the conversations have an immediacy and intimacy that resembles synchronous comms like in-person chat and videoconferencing. Conversations can continue regardless of where the stakeholders are physically located, even on a plane. Email is also asynchronous, to be sure — but it’s not conversational.

The upside to all this is that if you are a committed, dedicated leader, you can stay connected to the company’s relevant leadership discussions more or less around the clock. I usually work from Seattle, but I rarely feel disconnected from the folks in SE Asia, Beijing and Bangalore. You absolutely must travel at least a few times a year in order to build and sustain relationships with your peers in other geographies — you cannot skimp here or you will fail to build alignment. But between those trips, WPC keeps you as close as if you were just down the hall.

The downside is that it’s difficult to disconnect. It becomes addictive to stay as deep in the operations of the company as you can physically sustain. All these tools I’ve talked about today work basically just as well on mobile as they do on a laptop, so the work never stops. I personally tend to wake up a few times a night and check my notifications. But as long as I’m having fun and bringing value to Grab, I’m OK with that.

You have to be exceptionally careful with the people in your org, though, to ensure that they can properly disconnect and have downtime, or they will burn out in a hurry. And when you yourself need to disconnect, fortunately it’s as easy as turning off notifications for a handful of tools and then not looking at your work apps. I finally figured this out while standing in line at Tokyo Disneyland while having a work conversation. By turning off notifications I was able to disconnect from Grab for the first time in months with relatively little fuss.

Sprouting new GMMs at Grab has become almost as commonplace as sprouting postmortems, or RFCs, which are our equivalent of design docs. From a certain lens, GMMs, RFCS and postmortems all aim to solve similar problems: Creating great processes and systems (whether physical systems or leadership processes) through continuous improvement and codification of policies, mental models, and best practices. All three encourage open dialog and discussion, and enable us to act as OneGrab.

This new way of leading still delivers surprises, as we learn more about its social implications. At one point my leaders and I were discussing whether we should introduce video editing to our 3-minute intros, to polish them up and make them more entertaining. We also debated whether it was desirable to publish to Facebook Workplace regularly and try to attract internal followers. With some dismay I realized that modern leadership may be turning into PewDiePie. But is that really a bad thing? The point of leadership is to get people to follow you, and YouTubers know how to do that better than almost anyone these days.

An organization’s velocity tends to be gated on how fast information can flow, and how fast teams can achieve alignment when they encounter friction. At Grab, the information flow is fast and furious. How well does it flow in your org? If you’re still using email as your primary communication mechanism, then you’re probably not at optimal velocity.

I hope this was helpful. We’ve considered publishing a subset of our GMMs as a modern tech leadership manual, or at least as a starting point. Would that be useful? Let me know.