A case study in early-stage startup execution

Awais Hussain on March 23, 2022

engineering

culture

Before joining Wave four years ago, I spoke to a former employee about his experience. He said something that has stayed in my memory ever since: “Wave is really good at execution, so by working at Wave, you’ll learn how to execute very well.”

Now that I’ve been here a while, I thought it would be good to write down what really good execution actually looks like in practice and the counterintuitive lessons I’ve learned along the way. This post summarizes the techniques Wave used to execute really well when we were pre-product-market-fit and had thousands to tens of thousands of users. Most of the lessons come from a time when the company had dozens of employees, many of whom lived together in a house in Dakar, Senegal.

The techniques and principles I’ve seen us practice are:

• Transparent by default
• Solve the problem in front of you
• Stack rank everything
• Avoid deadlines
• Update beliefs in response to new information
• Know when to accelerate
• Don’t do bullshit work
• Hold effective 1-on-1s
• Explain the reasoning, not just the outcome

Transparent by default

Unless there’s an explicit reason for a piece of information to be hidden (e.g. the in-progress deliberations for an upcoming re-org, or M&A activity), all documents are expected to be public. When possible, we avoid DMs in Slack, private groups, and email threads. Instead, we communicate in public Slack channels and widely shared docs, @-mentioning the relevant parties.

Wave takes transparency a lot further than most companies. For example, all salary data is available internally so people aren’t left wondering if they are being underpaid relative to their colleagues, or being penalized for failing to negotiate hard enough when they joined.

A major benefit of transparency is that it empowers people to get their work done without needing to ask permission from others. Time that would be spent asking others for access to crucial documents can instead be spent doing productive work. Questions that might otherwise require a synchronous meeting between two people can (at least to a first approximation) be answered by searching through old design docs or slack messages.

A secondary benefit is that transparency allows each individual employee to reconstruct the reasoning of others for themselves. For example, when Wave made a large change to Agent commissions last year, I was able to look through our detailed monthly financials and convince myself that it was the right decision.

Solve the problem in front of you

At previous companies, I witnessed many conversations where folks got tangled up debating the finer points of a loosely relevant idea instead of focusing on the problem that was directly in front of them. These included questions like: “should we use a microservices or a monolith?”, “should we use Jira, Asana, or Github for project management?”, or “what does [some industry thought leader] think about [some general business concern]?” - at Wave, we never asked these questions.

Instead, every week we sat down and articulated what our most important goal was, and then ranked the biggest problems sitting between us and that goal. We would then all work exclusively on solving those problems. Working backwards from our goal in this way meant that we avoided splitting our attention across a bunch of different problems as well as problems that weren’t immediately critical to our success.

For example, when we launched our payments product it became clear that by far the biggest problem for users was sporadic internet connectivity causing payments to fail (or to succeed, but appear to fail). We tried almost everything, from sending traffic over SMS and USSD (which were sometimes more reliable) to building out an offline payments flow so that users could pay for things even if their internet connection was spotty.

Unlike a lot of startups, Wave never really tried to get press in any of the traditional start-up publications. Even though a TechCrunch writeup or Forbes founder portrait is considered a rite of passage for many high-growth startups, Wave was never drawn to them. Publicity is anecdotally helpful with fundraising and recruiting, but our primary goal was always around building a great product for users - and our users were not spending their time reading TechCrunch articles.

Stack rank everything

Every early-stage start up faces the problem of having too much work, and not enough resources to do all of it. Wave solved this problem by always putting work into a single stack ranked to-do list, with the highest priority thing on the top. Once a list was in place, my job was simply to start at the top and work my way down. I love this process for several reasons:

1. We assume people are internally, rather than externally, motivated. A manager can never ask an engineer to “work harder” or “work faster”, they can only reorder their priority list.
2. If we have to stop working mid-way through a project, then we know we’ve made the best use of the time up until then. There is no keystone moment at the end where a project is not delivered until the final piece goes in - if the final piece was so important, an incremental version of it would have been at the top of the list!
3. We know we’re always working on the most important thing. We don’t need to second guess ourselves about whether our time would be better spent working on something else, because we already did that thinking in the ranking phase.
4. It recognizes the reality that what we work on is often a key component of our effectiveness. It helps us avoid the trap of doing things that seem to be productive (like going to conferences, or writing overly detailed design docs), but don’t actually make a difference.

We always rewrote the to-do list before we got to the end of it, and often had projects that would be stopped mid-way through because of new information coming in. But, that’s exactly how this process is supposed to work. The goal isn’t to finish every item on the todo list, but to learn quickly and allocate our limited time and energy as effectively as possible.

Avoid deadlines

In college, everything ran on deadlines. Every class laid out its deadlines in a syllabus at the beginning of the semester, and then mostly stuck to those commitments to matter what happened later in the year.

For someone who has worked in such an environment, it’s difficult to imagine how anyone could be productive in a place that actively rejects deadlines. Without the last-minute, pre-deadline frenzy, surely nothing would ever get done!

The correct model here is that a deadline is a pre-commitment of your future time. Ben would often tell me not to set myself deadlines (even for something as small telling a colleague I would have an answer for them by tomorrow) because by holding myself to that commitment, I would be shutting down the possibility that by tomorrow I would have a different, more important priority to be paying attention to. For startups, this nimbleness is important.

When larger companies use deadlines, they seem to be a tool for coordination. One team can plan its time better if it knows when the other teams will have their work slot into place. To solve this problem, we instead do two things: (1) structure teams so that they can mostly solve their own problems, thereby limiting communication overhead, and (2) always including a signal of urgency when making a request to another team. Being small also helps!

For example, when field teams send bug reports and feature requests to engineers, instead of asking “when do you need this by?”, we ask them “how many users is this affecting?” or “how is this problem affecting your ability to do your job?” The engineer can then use this information to decide what the highest priority things are to work on that day, and typically all the most important things do get done.

An ancillary benefit of not having deadlines is that we avoided the overhead of tracking deadlines, and the extra people-hours it would take to enforce them. Additionally, not having deadlines made it easier for people to live Wave’s values — one of our values is “live your fullest life now” — basically that people should have good work life balance. We trust that people are doing their best and they shouldn’t feel like they need to overwork to hit some arbitrary deadline.

Update beliefs in response to new information

The Wave founders are great at looking at new incoming data and updating their beliefs quickly. This tacit knowledge of how to operate was helpful for me to watch since I’d previously seen environments where people operated on assumptions long past the point where they were still good. At a fast growing startup, the environment would often rapidly change around us and being able to quickly react to new information was critical to Wave achieving product-market fit.

For example, when I joined Wave, the product that everyone was most excited about was USSD — a protocol that lets “dumb” phones send money by dialling a code like “*171#”. We were excited by this because in our previous market, Ethiopia, USSD had been the catalyst that had catapulted our product into widespread adoption, and we expected the same in Senegal.

However, after getting the necessary partnerships for USSD and building the technology, the founders went out into the field for three days and determined that USSD wasn’t going to be the killer product we needed.

Why? First, our USSD contract was with the second largest Telco, not the first (like in Ethiopia), and it was difficult to convince people to get a new sim card just so they could use our product. Second, a larger proportion of people had smart phones in Senegal than in Ethiopia, and smartphone adoption was going up. A few weeks of excitement was undone by 3 days of real world data and we deprioritized USSD in favour of other strategies.

I vividly remember everyone at the company thinking that USSD would be the next big thing. But when we got this new data and we realized that we were wrong, we immediately deprioritized it. In some other environments, there would be some overhang where people would feel embarrassed for having pushed something that didn’t work out and would try to claim it was actually successful, which would justify further work, but Wave has a value of being “embarrassingly honest”. Wave employees really buy into the “embarrassingly honest” value, so it’s considered normal to realize that we made a mistake and walk away from it instead of doubling down on the mistake.

Know when to accelerate

One of our first experiments with payments was allowing people to pay for informal taxis using a Wave QR card in a town called Mbour. The taxis were called “Klandos” (short for clandestine vehicles; clandestine because they’re unlicensed) and they drove fixed routes between hubs called “garages”.

We launched the project with 2,000 QR cards that had been made using a label printer and plastic cards bought from an office supply store. Onboarding a new Klando route on to Wave was no mean feat. It required convincing the president of each garage to try our product, teaching the ~50 drivers how the product works, and then doing distribution with every one of the ~500 individuals who use that Klando route as their daily transportation.

Initially, most people didn’t pay with Wave. However, even though the absolute number of users was low (in the low hundreds), the day over day growth rate of payers was high enough for us to take notice.

I remember the operations team coming back from a gruelling week having opened 2 new routes that week, the most they had ever done! They were informed by Wave’s CEO that next week they should aim to open 4 new routes, then 8 the following week, and 16 the week after that. (Note: The point here was not that they should work exponentially harder, but that their efforts should be geared towards improving the process by which they onboard new routes.)

At the same time, the founders decided that the initial traction was good enough that we should make this project our main focus, and so 80% of employees who had previously been based in Dakar relocated to Mbour so that we could be fully focused on making the new project a success. The nimbleness enabled by being a small start up is only useful if you take bold decisions to make use of it.

A major reason for Wave’s success to date is that the founders have been very good at figuring out where to apply resources on thin information where many people would think that it’s too early to “step on the gas”. Obviously, a common startup mistake is to put too much effort it something that doesn’t matter, so this one requires excellent judgement and isn’t something that should be blindly copied.

Don’t do bullshit work

I’m sometimes amazed by friends who think that the first step to starting a new project is to write a 20-page proposal, or that the first step to starting a business is to make a detailed business plan or slide deck. Many projects at big companies or research groups do need to start in exactly this way to get stakeholder buy-in, and we’ve been trained throughout school that writing essays is a key skill, regardless of whether those essays are read by anyone or not.

At Wave, we tried to avoid doing anything that wasn’t absolutely necessary. We wrote in bullet points rather than prose because bullet points were faster to write and could communicate information more densely. If a bug report wasn’t deemed serious, we would simply decide not to fix it (often the bug would make itself irrelevant in some future code refactoring or strategy change). We decided that if the core principles of a business were sound, the rest of the business plan wasn’t needed, so we didn’t do one.

A corollary of avoiding unnecessary work that I really appreciated when I joined was that if we were doing something and someone asked “why are we doing this?” and no one had an answer, we’d table it until someone could come up with a good reason. Having everyone on board with this cultural value made it easy to eliminate bullshit work.

As another example, for my first year at Wave I had only two scheduled meetings per-week: the company-wide all hands and my weekly 1:1 with my manager. Formal meetings weren’t an effective way to get work done so we simply didn’t do them. We believed focused, uninterrupted time was important, and so we acted on that value.

Hold effective 1-on-1s

The 1-on-1s at my previous company felt like formalities. My manager and I both knew we were supposed to do them, so every week we would struggle to reserve a meeting room and then sit for 30 minutes talking broadly about life, the universe and everything.

At Wave, before every 1-on-1 I’m expected to write down what is on my mind that week, so my manager can take a look before the meeting and process their ideas. My prep questions were things like, “what could have sped you up this week?”, “have you noticed any problems with our tools?”, and “what type of work would you most like to be doing?”. By answering these questions each week, I was forced to reflect on what would make me happiest and most effective at work.

An important part of effective 1:1s is that the problems which come up do actually get addressed. At my previous company, we would have retrospectives every two weeks, but mostly they consisted of repeating the same post-it notes every week, with nothing really changing as a result. At Wave, we’re encouraged to take ownership of our work, and at least make an attempt to fix anything that’s visibly broken. For instance, when the support team room in our tiny office was too noisy, we bought sound absorbent panels for the walls; when stand-ups stopped being useful, we got rid of them.

Another reason having good 1:1s was valuable was that it allowed for good information flow, which dovetails with what we’ve discussed on prioritization and working on the most important thing.

Explain the reasoning, not just the outcome

One of my early observations at Wave was that the leadership would almost always make an effort to explain the reasoning, and not just the outcomes of their decisions. This extended also to the codebase and wider documentation.

The relationship here is the same as that of derivation to rote memorization. If the reasoning has been properly communicated, then it can be torn down, manipulated and reconstructed entirely in the mind of the person being told the decision. If the underlying facts that form the reasoning have changed, then the outcome might no longer be relevant. Likewise, if a particular piece of code was written for a purpose that is no longer relevant, then it can be safely deleted.

For instance, it is quite normal at Wave to hear the question: “What makes you believe ‘X’?”, or for someone to begin a conversation by laying out their assumptions. In some environments, these questions can be perceived as insubordinate or hostile. However, the purpose here isn’t to challenge the person’s authority, but to be able to reliably reconstruct their reasoning.

A second benefit is that it signals trust in your colleagues and facilitates autonomy. If one person’s reasoning has been communicated well to another person, then the first person can disappear to go work on something else and the second person is able to fully own the project.

What’s changed over time

As we’ve grown, some of the things mentioned above have changed in response to the new constraints we face, though we have tried to preserve the best parts of our culture.

We now have enough engineers that we don’t orient all engineers around a single goal and we can now effectively tackle multiple different problems simultaneously. For example, we have dedicated infra engineers who don’t reorient their work around product changes, and we also have multiple product teams.

Since we no longer orient all engineers around one thing, we also split into having multiple to do lists - these are usually presented as “cycle letters” written by each team to lay out their goals for the upcoming 2 months. Because we value autonomy, teams choose their owns processes and task tracking tools.

As the company has grown, we’ve had two instances where we needed deadlines because they were externally imposed. For example, the Ugandan government gave us deadlines for on-prem deployment in Uganda to continue operating in Uganda, which required us to internally set sub-deadlines to make sure that we’d hit that goal. But, we still operate without deadlines except where we have external deadlines that cause us to need to create internal schedules to make sure we’ll deliver on time. The fact that deadlines are used so infrequently means that they are taken very seriously when they are required.

As we’ve grown, we’ve had to recruit a lot more, so we now spend some time on developer marketing by doing things like writing blog posts and maintaining a social media presence. We’re still a user focused company and still mostly focus on making great products for users, but our exponential user and revenue growth has made hiring bandwidth a limiting factor for critical feature development, so spending zero effort on marketing isn’t optimal.

Similarly, we spend more time in meetings. When the company only had a few engineers and engineers were focused on the same project, we could keep our work aligned without much time spent syncing. But now that we have multiple product teams, are getting close to having multiple infrastructure teams despite our best efforts to keep things simple, and have had growth in other areas as well, some people need to make sure that team goals are aligned.

But, despite being a much larger company now, we’re still focused on execution. We still try to make sure that we’re working on the right problems, remain embarrassingly honest, can move quickly, and can quickly pour effort into important goals when that’s the right thing to do.

If you like how Wave operates, we’re hiring at every level, from director (basically the highest management level we have since we’re not large enough to have VPs, etc.) on down.

At the moment, some particular critical hiring needs are head of data, data analyst, director of engineering for user-facing product, Postgres-oriented SRE, on-prem knowledgeable SRE, generalist SRE, iOS engineer and Android engineer. Of course, we’re also hiring for generalist software engineers as well as many other other positions. We’re fully remote and have people all over the world!