In part one of this series, I provided a pragmatic approach to starting your bug bounty program, addressing the pitfalls you might experience, and offering suggestions on how to maximise the number of useful reports.

Part two covered budgets, payments, and how to deal with beg bounties.

The final instalment will focus on how to engage bug bounty hunters to improve the quality of reported bugs.

Opening the door to bug bounty hunters with better findings

As you issue rewards for valuable bug bounty reports, you’ll start to see the same bug bounty reporters coming back with increasingly interesting findings. The quality of their reports will improve. Their proof of concept scripts will get a bit easier to understand (you’re learning how to work with them too!), and they’ll start to offer up early warning reports while they confirm the scope and impact.

Once you find someone who recognises that their efforts will be rewarded, they dig deeper, become more familiar with the product and services, and can start chaining things together in ways that increase the value of their findings.

Over time, you’ll develop a small group of people constantly poking at your product, and sending you reports that you have more trust in. You spend less time validating and more time improving the security of your product.

Remember, this doesn’t come for free! As the security team at a company, you need to invest time in relationship management and encourage their activity. When someone submits multiple interesting findings, I usually reach out to them personally and learn more about them. This involves scheduling a call over Zoom, asking about their background, what motivated them to get involved in APPSEC/penetration testing, how they learn etc.

I also ask them about our product — they’ve tried breaking it, where do they think we are strongest and weakest? Finally, I let them know that we really value their reports and prioritise them (which we do!).

Building these relationships makes our security team more effective. Whenever we release a new product, or publish a new API endpoint, I know there are a handful of credible people that will scan and try to break it. And if they do, they submit a report which will be higher quality than most others we receive, and we will prioritise investigation and remediation. We also provide them direction too — if they’re credible, we point them at areas of our product that we think might be higher risk.

By far, the best part of relationship building is the people — completely changing how I see bug bounty hunters…

Enter, Siddharth.

Siddharth is a college student from India, currently studying computer systems engineering. During COVID, he found himself unable to go to university, and had a lot of time at home. He found APPSEC/penetration testing interesting, and started teaching himself.

In 2021, Siddharth submitted a couple of bug reports to our bug bounty program. His reports were better written than most, and the bugs combined different APIs in ways that we hadn’t thought about. After we reviewed and rewarded these reports, I hopped on a Zoom call with him, chatted about his background and what his goals were, and asked how we could help him find more bugs and earn more bounties. I pointed him towards some services that we had recently published, and he started producing non-vulnerability reports too — reports showing what he tried and what didn’t work.

It quickly became clear that we were getting a lot of benefit from the attention, so we brought Siddharth onboard to pen-test our products for a fixed number of hours per week.

Instead of rewarding bounties per finding, we pay him a fixed rate, and we get more value — we don’t just get bug reports, but also routine reports about where there doesn’t seem to be any bugs. We also connected him with other members of our engineering team so that he can explain how he found each bug directly, and he can ask them questions about how our services work to find more complex and valuable bugs.

While chatting with Siddharth, I asked him what he was planning to do after he graduates from university. His response was that he plans to move overseas to complete his masters degree in penetration testing and application security — and his bug bounty rewards are going directly to his university fees.

It’s easy for us to reduce bug bounty reports down to an email address and a bug. But we need to remember that there’s a human on the other side. Effort needs to be reciprocated, and if someone takes the time to improve the security of your product and/or company, it’s worth taking time to get to know them.

In security, we lament that we’re all deeply under-resourced. Spending time to engage with credible people — whether an interview, at a recruiting event, or someone submitting a bug report to your bug bounty program — is a low-cost, and high-value way to help reduce the pressure. Even if they’re not a great fit for your team, or you don’t have headcount to hire them, we’re still able to collectively increase the number and quality of security people in the world by simply engaging.

Overall, getting to know the bug bounty hunters who are putting in effort pays far more than just security gains. Building relationships has brought bug bounty reporters closer to our teams, ultimately building more value.

It’s a great way to find and grow talent, wherever they are in the world, and get even more value out of your bug bounty program.

Conclusion

To wrap up this three part series on setting up your bug bounty program:

• Bug bounty programs aren’t as simple as you might like, but when done right they’re high impact and relatively low cost
• Make sure you set clear bug bounty terms (internally and externally) from day one
• Set internal guidelines for how much you’re willing to pay for bugs of a given severity. It’s better to have these before you get the reports
• Don’t waste time on beg bounties — automated response emails are your friend, and time is likely your most scarce resource
• Build relationships with the bug bounty hunters who are making an effort. Symbiotic relationships will have the best and most impactful results.

A pragmatic guide to building your bug bounty program was originally published in Airwallex Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is part two in a series which provides a pragmatic approach to starting your bug bounty program, targeted particularly at startups. In this post, we cover budgets, payments, and how to deal with beg bounties.

If you haven’t already, check out part one here, where we cover the tactical parts of setting up your bug bounty program.

So, how much should you pay?

One of the most difficult questions to answer when building a bug bounty program, is how much to pay for successful bug bounty reports. Obviously this changes as you scale, but as a general rule of thumb we try to balance the impact of the bug against the resources we have to reward findings.

A safe amount you could consider is something like:

• P1: Severe impact, such as account takeover — USD$10k
• P2: Major impact, such as account corruption or privilege escalation — USD$3–5k
• P3: Medium impact, such as minor data leak within an account or local account DoS — USD$500–2k
• P4: Minor impact, such as a known design issue which you are now able to fix, or exposed vulnerable low-criticality services your scanners missed — USD$100–500

You can scale these up and down as much as you’d like — for some organisations, a P1 may have a greater impact and your security team may have the resources and motivation to issue bigger rewards.

An alternative option I’ve seen is to ship people t-shirts and other company swag — however, I’ve found this isn’t as well received.

Sticking to a monetary reward is much cleaner and more appreciated by bug bounty reporters — once you take into consideration t-shirt design, printing costs and the time required, monetary rewards can often end up more cost effective.

Setting a budget

For a small or medium sized start up (< 1000 people), I would budget about USD$30–40k per year if you’re doing it yourself, or more if you’re using a bug bounty vendor. I would expect to have 0.1–0.25 people working on it throughout the year.

This is entirely subjective, so it can be helpful to view your program as fluid. With our bug bounty program, we can either ramp up (based on the measured impact from historical reports) or down (when we hit budgeted limits).

Getting stakeholder buy-in is key, so start by explaining the program and its benefits to your finance team.

Comparing the cost of running periodic penetration tests is a good way to approach this discussion — the output is different, but it makes progress against the same goal. As with everything in security, you’re comparing the risk of not discovering these findings, against the potential business cost to if they’re exploited by an adversary.

Once you get your program up and running, metrics become key to establishing your budget and reward amounts. Comparing the findings from your bug bounty program and penetration tests can help give you relative data on how much you should be spending compared to the benefit you receive.

Beg bounties

A term coined by Sophos and expanded in Troy Hunt’s Beg Bounty article, a beg bounty is someone submitting a low-effort, low-value report and “begging” for a reward.

While running your bug bounty program, you’re likely to receive a lot of beg bounties — these will typically involve some combination of the following:

• A person asking if you’ll pay a reward for security vulnerabilities they find (without telling you what you’ve found)
• A person emailing senior leaders and generic email addresses saying they’ve found a severe vulnerability in an attempt to cause panic
• Very low priority (non-)issues, such as scan reports of DMARC or SPF records
• Unvalidated and/or theoretical vulnerabilities
• Immediate ask for payment

With bug bounty programs rising in popularity over the past few years, so too has the amount of low-effort, bogus bug bounty reports (submitted to companies in the hopes of a reward).

I’ve also noticed these are getting increasingly automated.

Generally someone will find your company’s website, (optionally) search to see if there’s a bug bounty program, throw your domains and URL into SSL Labs or dmarcian, and send an email saying something like:

I have found a serious vulnerability in your website that will allow me to email anyone as your CEO. According to [OWASP | BugCrowd | similar framework] this is a [P1–4 | critical | severe] vulnerability that needs fixing. Please provide a bounty for this report.

Beg bounties can be an unfortunate time sink. At Airwallex, we’ve minimised this impact by setting up email auto-replies which link to our bug bounty program’s terms; explicitly stating which issues will not be rewarded and that we can’t always respond to low priority findings.

If you’re looking for a canned response to send out automatically, you can try modifying the below:

Hi there,

Thanks for submitting a report to our bug bounty program. Please ensure that you have read our <bug bounty terms>[https://linktoyourterms.here] as part of this submission.

We receive a high volume of reports and unfortunately cannot respond to all reports. Please note that we will not provide responses to any reports which:

- Do not follow our bug bounty terms

- Has an unvalidated vulnerability (except where validating the impact would cause harm to [your organisation])

- Consists of low-value findings commonly found using a scanning tool (e.g. SPF records, DMARC records, TLS/HTTPS algorithms and ciphers)

- Consists of vulnerabilities which rely on brute force or social engineering

If your report does not fall into these categories, please make sure you’ve provided details about the vulnerability you’ve found, including a full description of the vulnerability, the impact, and a proof-of-concept script.

Thanks!

- [Your organisation] Security Team

I’ve seen well-intentioned suggestions to help grow people who submit low value findings — pointing them at educational resources and helping them find better bugs. Although I like the effort in building the security community globally, your time is your most valuable resource and you need to remain aggressively focused on where you can have the most impact.

Instead, I’ve found building relationships with the bug bounty hunters — who submit valuable and interesting reports — is far more valuable. I’ve covered this in more detail in part three (coming soon).

This is the second entry in a three-part series on starting a bug bounty program. Continue reading Part 3: The value in building relationships with bug bounty reporters, where we cover how your relationships with bug bounty reporters can amplify the quality and consistency of reports.

Part 2: A pragmatic guide to building your bug bounty program was originally published in Airwallex Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Getting set up, and maintaining your program

A bug bounty program is a great way to improve the security of your product with relatively little investment. This involves allowing the security community to try to exploit your product in a sanctioned way, effectively crowdsourcing part of your application security and penetration testing. In return, you offer a reward for significant findings, motivating 1000s of security researchers across the world to find and disclose vulnerabilities.

As with anything you open up to the world (particularly if it offers rewards), you’ll end up with some good spirited people who will help make your product materially more secure, and some who want to exploit your program.

Having run our bug bounty program for two years, I’ve found that the key to success is having the right checks and balances in place to reduce noise and beg bounties, encouraging higher impact reports, and ultimately making it an efficient use of your limited time.

In this series of blog posts, I’ve provided a pragmatic approach to starting your bug bounty program, targeted particularly at startups. I’ve addressed the pitfalls you might experience, and offered suggestions on how to maximise the number of useful reports. This series covers:

• A guide on how to get your bug bounty program live
• How to operate and maintain your bug bounty program
• Deciding how much you should pay
• How to deal with beg bounties (not a typo!)
• Opening the door to higher quality bug bounty hunters

This post will focus on getting your bug bounty program up and running, and the important aspects of operating and maintaining it.

How to get your bug bounty program up and running

When you get your bug bounty program set up for the first time, you will want to make sure you do the following:

• Make sure bug bounty hunters are targeting a demo environment, or have strict controls in place to prevent them impacting real users. If you’re unable to use a demo environment, set up explicit targets in your production environment and ensure that you document what is and isn’t in scope
• Let your engineering team know that you’re setting this up (and that, no, they’re not eligible for rewards — no writing bugs for a bonus!). This is a good way to build security culture and prepare them for fixing any findings. It’s also a good idea to align on SLAs for security fixes if you haven’t already
• Talk with your legal team about what you’re doing. They can help build out the terms and services for your bug bounty program, and will be able to ensure you’re operating in a compliant way — particularly navigating between malicious and beneficial exploit attempts and ensuring you’re meeting your company’s compliance requirements. You will want to partner with them on building the terms for the program to help set the scope, and the explicit findings that are in and out of scope — feel free to build on top of ours
• Make sure your finance team knows about the program and what this might mean for them. They may need to make international payments to some bug bounty recipients and you will want to establish a budget with them. If you’re wondering how much to budget for — check out the “How much you should pay” section in Part 2. Additionally, in your bug bounty terms, you should remind recipients they are responsible for all taxes
• When paying out a bug bounty you’ll likely need to perform some AML checks on the person you are paying. This helps to ensure you’re not breaking any money transfer/payment laws or sanctions. HR, legal, and finance teams may have ideas on how to do this efficiently. You’ll also need to collect their bank details — finance teams usually prefer bank transfer over Paypal or similar.
• Set up a security.txt page. Google’s is a good example: https://www.google.com/.well-known/security.txt. You should host this at yourdomain.com/security.txt or similar
• Create a mailbox to receive reports, e.g. bugbounty@yourcompany.com. We also recommend setting up an automated reply with SLAs for responses and reminding people of the terms and conditions. In particular, adding a list of out-of-scope findings to your auto-reply will address beg bounties and low-value findings without manual input
• Build a page on your website to provide terms and instructions on how to participate in your bug bounty. We put ours in our security centre
• Ensure you have the resources to handle the findings and reports. Initially, you should expect to dedicate about 20–30% of 1 person’s time on the bug bounty program. This will involve figuring out which emails to respond to, working with your engineering team to coordinate fixes, responding to the bug bounty hunter to validate and remediate issues, and sorting out payment afterwards. As your bug bounty program matures, you’ll spend less time on this — we noticed we were much more efficient after about three to four weeks
• Make sure the most visible employees in your company (usually the CEO/founders) know about this program so they can help redirect queries accordingly. Despite documenting the correct path for vulnerability disclosure, we still see reports to a range of people at Airwallex
• Set up somewhere to track security vulnerabilities internally — we use Jira. Make sure you can use this ticket as the source of truth for all vulnerabilities found and ensure it’s easy to add the relevant software engineers. We have our bug bounty mailbox auto-forward emails to a second email address which creates Jira issues. This lets us have a purely internal ticket per report that we receive, and we’re able to track the status internally. Alternatively, you could communicate with bug bounty reporters directly through tools like Jira or Zendesk
• Track your bug bounty reports to avoid duplicates and provide metrics on how effective the program is. Our bug bounty reports are all stored in a Jira project — finding duplicates is easy, and we’re able to get good metrics about the number of impactful reports we receive and how much we are paying out

How to operate and maintain your bug bounty program

As with anything you do in security, once you build it you need to maintain it. Operating your bug bounty program takes resources and is particularly expensive initially as you spend time getting the program set up and learn what works for your team and company. Automation is a good choice here, however I’ve found it best to operate things manually for the first few weeks to better understand your program, then set up low-cost automation to handle common manual tasks.

As an example, one of the first things we automated was our auto-reply responses to submissions. This auto-reply lists our terms and out-of-scope areas to discourage low-effort reports, providing the caveat that if it’s out of scope, we typically won’t respond. These small pieces of automation save us from manually responding to submissions which are out of scope, reducing the total volume of reports requiring attention by about 50%.

You’ll also want to build an SOP for processing bug bounty reports internally, including the relevant teams. Having this documented helps other teams understand what’s required of them, and gives a consistent experience to bug bounty reporters. The diagram below shows our rough process for triaging, analysing, remediating, and rewarding bug bounties:

In your SOP — you should also decide whether you want to identify your security team individually when communicating with bug bounty hunters or use a generic email address. If the issue is legitimate and interesting, our team generally introduces themselves and learns a bit more about the person submitting the reports. This helps build relationships with people who are ultimately helping make your organisation more secure, getting more of their time and increasing the number of valuable reports we receive. For initial engagements or low value findings, we respond using our bugbounty@ mailbox instead.

Validating reports

When validating whether a reported issue is a legitimate vulnerability you will need to go deeper than just what’s in the report. The person submitting the report doesn’t have access to your engineering team and documentation so they’re not able to look at the code and mitigation to understand what the root cause is, and see where else in your code base the same issue might exist. When talking with your engineering teams about the vulnerability, ask them to scope the impact. Having them determine the blast radius of a bug — including where else the bug might exist and what an attacker could do above what has been reported — is a good way to educate them and reduce the likelihood similar bugs occur in the future. The increased accountability is a bonus too. Finally — ask the bug reporter to validate the fix too.

Vendors vs doing it yourself

Bug bounty program vendors, like HackerOne and BugCrowd, can be effective to take a lot of operational burden off your hands. Generally, the way they work is by handling the triage phase of reports and getting better report quality through targeted pentesting of your products, by reputable bug bounty hunters on their platform. You pay more for their services (effectively paying a premium on top of the bug bounty amounts), but you are paying to reduce workload on your own team which is likely your most scarce resource. You can also explore working with vendors to set explicit targets for your bug bounty program, such as number of findings and money awarded. We run our own bug bounty program, but it’s worth getting in contact with vendors to see if they’re a good fit for your team and security program.

Lastly, if you have a bug bounty hunter submit a legitimate and interesting report, make sure to note their name and contact details! They’ll likely pop up again in the future and you’ll want to encourage their engagement. For more details on this, look out for the “Opening the door to bug bounty hunters with better findings” section in part three.

This is the first entry in a three-part series on starting a bug bounty program. Continue reading Part 2: Budgets and payments, and dealing with beg bounties here.

Part 1: A pragmatic guide to building your bug bounty program was originally published in Airwallex Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Airwallex, we care about who you are, how you approach problems, your goals, and whether we’re a good fit. This blog will shed light on what it’s like to interview for an engineering position at Airwallex.

All of our interview paths first involve a call with a recruiter who will tell you a little more about Airwallex, the role, and the hiring process. We try to keep our interviews fairly informal and laid back so you’re able to operate at your best — so wear what you want, come relaxed and well-rested, and if the interviews are too early, too late or you require any other accommodations that will help you do your best, please let us know!

First, some interview tips

• Practice medium and hard questions on LeetCode beforehand. You’ll want to be able to solve these in about 30–40 minutes.
• Clarify the problem before you solve it. What are some ambiguous parts that could change your approach?
• Start with naive solutions, then improve. It’s easier to start with something and make progress than to try to get the perfect solution straight away.
• Tell us what you’re thinking. We want to see how you approach problems, including what solutions you’re considering, what assumptions you’re making, where you see issues before you write code, and so on.
• If you get stuck and can’t make any progress, you can always ask for help.
• Come prepared with questions for us! We’ll be transparent — this is your opportunity to understand what Airwallex is like and how you can grow here.

The Tech Screen (60 minutes)

After chatting with a recruiter, the first interview is a tech screen where you’ll tell us a little about your background and solve a coding challenge. These are pretty similar to easy and medium questions on platforms like LeetCode. We’re most interested in seeing your understanding of basic and common algorithms and how well you can apply them in coding challenges.

The tech screen is also a great opportunity for you to ask some of our engineers about life at Airwallex — such as what challenges we’re facing, or the best parts of the role and what it’s like working with a global team.

The Take Home Challenge or Live Coding Challenge (60 minutes live or 3–4 hours at home)

For our next interview, you have a choice between a take home challenge, or a live coding challenge. Both interview formats aim to go deeper into your technical ability — the code portion is more challenging than the tech screen. We’re interested in your ability to write readable code, make reasonable assumptions, and add a few tests to make sure your solution is correct.

In the take home challenge, you’ll be given a code challenge that you can work on in your own time. You’ll be provided with a set of files that outline that problem — which you can solve in a common language of your choosing — and you’ll return the files to us afterwards to review. We treat the files in the same way that we would treat any other code review i.e. whether the solution works, how easy your code is to read, the quality (not quantity!) of tests, etc. We typically find candidates complete the challenge in about 3–4 hours.

In the live coding challenge, we dig into a more challenging coding question in a 60 minute interview — we want to see your ability to take a problem, make assumptions, understand edge cases, code an initial solution in a language you’re comfortable with, write some tests, and iterate. It’s a good idea to find the trivial solution first and make it more efficient, rather than trying to find the best solution straight away. We’ll also ask you to assess the time complexity to see how well you can assess your own solution.

The System Design and Problem Solving Challenge (60–90 minutes)

The system design and problem solving challenge looks to assess how you approach problems at higher levels. We slightly modify this interview for each candidate (don’t worry we’ll let you know beforehand!) to dig into areas that we think are most relevant — you may have an interview that consists of just problem solving, or one that is solely focused on system design and architecture.

If you choose to complete a take home code challenge (as mentioned above), this interview will start with a code review of your solution. During this interview, one of our engineers will review your code and ask how you think you could improve it. We try to keep this as close to a real code review as possible.

Our systems assessment involves starting with a product and designing the technical solution behind it — such as coming up with the right architecture for a live messaging app. You should make sure you clarify the problem, the scale, and the functional and non-functional requirements. We want to see how you can think about a user, their requirements, and how that maps to a technical solution.

Our problem solving challenge is designed to understand how you approach abstract problems, and how well you can make assumptions, think through flow-on effects, and map those back to data structures and algorithms. Our typical problem solving challenge will start with a real world but ambiguous problem, such as, “what’s the fastest way to cross a city?”. We want to see how you scope and clarify the problem to make it more solvable. This includes making assumptions and focusing on the factors that have the greatest impact, then identifying a solution. We’ll then ask what data structures or algorithms your solution maps to, but we generally don’t expect you to write any code.

Final Interview (60 minutes)

Our final interview is with one of our senior leaders in engineering — usually our CEO, CTO, or a VP of Engineering. Hiring is critical to our success and we have engagement across the entire company to find and hire the best people we can find. This interview is our opportunity to make sure you’ll be a great culture fit for our team, you resonate with our company values, and to discuss the growth opportunities within Airwallex. It’s also your chance to ask any additional questions you might still have about the company, our engineering team, the direction we’re moving in, or anything else!

What happens next

After your final interview, our interviewers discuss how you did and assess where you’d be a great fit in the company. We try to be as thoughtful as possible about our hiring — including writing a thesis that outlines what your future looks like at the company, where you would be most successful, and which team would benefit the most with you on it. You should also take some time to reflect on your interview experience — it’s important that it’s a mutual fit.

Finally — we love feedback. We have designed our interview process to match how we work day-to-day, and try to connect you with people who can transparently talk about what life is like at Airwallex. If you have any suggestions or comments on what went well, or where we can improve, please let us know!

Good luck, and we look forward to meeting you!

We’re hiring! Check out our open roles here.

Getting Hired was originally published in Airwallex Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a leader in engineering, I’ve found one of the greatest challenges is deciding when to hand things over to others, particularly your reports. It often feels like you’re delegating things “not worth your time”, or that it’s more efficient to do them yourself.

However, it’s important to recognise your role has changed — you’re no longer leading the implementation of a lot of the work you’re responsible for, but instead you are the coach. Put simply, your role is no longer just about you.

The sooner you can shift your focus from your own execution to your team, the sooner you can meaningfully grow and support the people you’re responsible for.

In this post, I’ll share a few ideas on how you can reframe handing off work — often large and challenging projects — in a way that empowers and grows others in your team, while also ensuring team success.

Ease of task can be one of the biggest barriers leaders face when delegating workload to others. For example, your team might be building new functionality on top of a code base that you have more experience with. It’s tempting to say, “I’ll take this task”, rationalising with “it’s the fastest way for our team to push out this new feature”. However, you should ask yourself: am I making a short term efficiency gain by sacrificing personal growth and long term efficiency of the team?

As a leader, you are responsible for the growth of each person on your team. The fastest way to help them grow is to set challenges where they will likely make mistakes (hear me out), in ways that will help them grow quickly, not cause significant negative impact, and with the support to ultimately be successful. Put another way, ensure they fail at the right rate.

What makes the tradeoff — of faster/lower-risk delivery against growth — worthwhile, is that growth is a long term investment with a significant long term upside.

By giving someone work they might fail at, you are driving professional development and making your team more valuable over time. You’re getting the flywheel spinning too — as people grow and gain more experience, they’ll be able to coach others.

When balancing handling tasks myself or delegating, I like to consider the following areas:

1. Calculating relative growth
2. Considering tasks as one way or two way streets
3. Being explicit about intent and support

Calculating relative growth

How much you learn and grow when working on a task or deliverable, is proportional to the amount of times you’ve done it before. In other words, growth is relative to experience. You know what to do, you know where it won’t work, and you know what to avoid.

While repeated tasks offer a smaller amount of professional growth (generally speaking), new tasks give people the opportunity to learn, make mistakes, and grow.

Delegating to others means you can focus on the bigger picture or tasks that only you are uniquely able to take on, with the added benefit of experiencing higher growth yourself by working on new challenges.

Ultimately, the goal is to grow each individual and in turn, the collective team.

Considering tasks as one-way or two-way streets

The second way I like to model delegating is by considering tasks as one-way or two-way streets — or put differently, how easily can you undo a decision, action, or mistake? This is a quick and effective way to evaluate the impact of potential failure.

• A one-way street is very difficult to reverse: This usually requires significant resources, or has a technical or cultural cost to the team. For example: a significant architectural decision
• A two-way street is relatively simple to reverse: For example: writing tests, or building a small or isolated feature.

This model gives people the chance to fail, while working on tasks that are relatively easy to fix (should something go awry).

Evaluating tasks as a one-way or two-way street provides clarity on the impact of failure. That being said, I’ve found the potential growth gained from failing is often high enough to justify the risk.

When you combine the above two approaches — calculating relative growth and seeing tasks as one-way or two-way streets — it becomes easier to understand the value of delegation and identify good candidates to give to other team members, and ultimately invest in the growth of your team.

However this can increase the risk of not delivering things and of people feeling overwhelmed. We want to try and minimise this risk, and we can do this easily by being clear about what you’re doing, and how you’re available to help.

Being explicit about intent and support

People inevitably want to succeed. It’s uncomfortable to consider failure, particularly in front of a manager, project lead or (often scariest) your peers. Therefore, as a leader, you must create an environment that maximises the upside of failure, while also reducing fear. This begins with clarity. Leaders should ensure their team has a clear understanding of the following:

• What you are trying to achieve
• When they’re being challenged
• That you have confidence in their abilities
• That you are there as a safety net should they need it — this can be to bounce ideas, or to help if things aren’t moving in the right direction

Providing clarity at the outset helps ensure people feel comfortable making mistakes, and comfortable pulling you in if needed. You’re also reducing the risk of missing delivery targets.

I am a fan of near-irresponsible ownership and challenges. I’ve found that handing over large projects, often with a bit of ambiguity, is an effective way to build a sense of ownership, develop problem solving abilities, and instil the confidence needed to tackle hard problems.

I often reiterate these intentions to my team: the challenge I’m asking you to solve is hard, I’m giving you ownership of finding a solution, I’m comfortable with mistakes, and I will be your safety net.

As a practical example, we recently ran an intern program for the first time with one of our engineering teams. Rather than recreate what I had done previously, this was delegated to one of the engineers. I gave some suggestions on how to get started, let him know that I trusted his judgment, and that if he needed help, or wanted someone to bounce ideas off, I was available. Whenever there were roadblocks, he would pull me in, I would help out, then leave him to it.

I.e.: Trust the person, set them up to grow, then act as a safety net.

As a result, we now have another person on our team who understands what’s required to build a successful intern program. When organising our intern program this summer, I didn’t need to be involved — instead, we’re able to get more of the team involved in the process, continuing the cycle.

Wrapping up

Growth is a long term investment that does require a tradeoff of faster/lower-risk delivery. By delegating more difficult projects to others on the team however, you’re investing in their growth and the team’s collective abilities.

Think about the relative growth of the work you take on, evaluate whether it’s a one-way or two-way street, and when delegating, be explicit about your intent and the support you’ll provide. Combining these steps will help accelerate your team’s growth, build a higher output team in the future, and help you focus on what you need to do.

Looking to take the next step in your career? Check out our careers page for open roles.

Back to blog

The benefits of setting your team up for (strategic) failure was originally published in Airwallex Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

TLDR;

• Humans need focus to be their most productive, creative, innovative, and effective. We want to spend as much time in this state as possible
• Productivity tools can both help and hinder productivity — be aware of Weapons of Mass Distraction
• Understanding how these tools are useful, as well as how they hurt productivity, focus, and effort, is important to mitigate the downsides and ensure we’re using them in a sane way
• You should try turn your notifications off permanently and block focus time in your calendar. No, seriously, you should

Form over function

In 1906, the first open plan office opened in the US. Designed by Frank Lloyd Wright, cubicles and compartments were seen as the enemy of social barriers — he focused on tearing down the physical walls in an attempt to reduce the psychological and social ones. Throughout the 20th century, this style of office layout grew in popularity, growing into hot-desking in the 1980s, and finally landing on its most common form as long rows of desks in the 2000s.

115 years later, Frank’s gift of aesthetically pleasing spaces is at the height of its popularity. Open plan spaces look great. They look like they would be amazing for the modern knowledge-economy workplace. The promises of great collaboration are over-sold, and the negative impact on individuals are glossed over as necessary and immaterial downsides.

Increasingly, people are becoming more aware of the impact that open plan office spaces have on their productivity. Speak to a handful of people throughout our company and they’ll tell you about the downsides of modern office spaces — there are a ton of distractions, limited ability to discourage others from interrupting, one-size-fits-all for heating and lighting, and noise pollution.

It’s well understood that people do their best work when they have the time to get into the zone. Ask any dev and they’ll explain how building new features requires 15–30 mins upfront to build a mental model of the systems and code you’re working with, how they piece together, etc. and how a single distraction can destroy that mental model. Ask anyone in design and they’ll explain how being able to conceive and iterate on ideas is easiest in a concentrated block, or several concentrated sessions.

None of this is ground breaking — it’s all common sense, and I’d hope that you’re agreeing with the content to this point, and not really surprised.

We are cognisant of distractions in the workplace because they’re “real”. We can see them. We can measure the distraction comfortably because we receive physical signals from our brain that we are distracted — we look at the person talking loudly at the desk next to us, we hear the person saying “hey elliot, got a sec?”, we feel the cold/hot of the room temperature. Our body is providing us feedback and our brain rightfully treats it as a negative — distractions.

It’s difficult to trick our brains and bodies into treating distractions as positive experiences.

The tools and technologies we use each day are a different story and aren’t limited by physical constraints.

Over the past 15 years, we’ve seen the meteoric rise of the distraction economy — companies whose sole mission is to take as much of your time as possible and provide metrics to stakeholders on how engaged their users are. They operate exclusively in the digital world with interactions through your phone or computer. When we talk about the distraction economy most people will focus on social media — notifications from Facebook, the constant stream of emails from LinkedIn (someone viewed your profile! please dedicate part of your day to this insignificant information!), Twitter, and so on.

The way that these tools and applications capture increasing amounts of your attention is well documented and most people understand it. In essence, they use a bunch of data to understand how humans function psychologically, and optimise on how to give your brain a dopamine hit as frequently as possible to get you hooked. Someone’s looking at your profile on LinkedIn? Feels good! Someone liked your post on instagram? Feels good!

While we have been focusing on social media, we’ve glossed over the tools that we use every day and undervalued the negative impact they have on our ability to focus, their deterioration of our productivity, and their contribution to stress and anxiety of the modern workplace. These tools are architected to grab as much of your time as possible and are engineered for engagement — they are pulling the same levers as social media.

How we got here

Messaging apps are sold as “the email killer”, the “ultimate productivity tool,” and most recently “your digital HQ”. In essence, it’s just a way to message people in realtime with a bunch of other integrations thrown in to capture more of your attention.

These applications are both contributing to, and deteriorating, productivity. If we take productivity at its most fundamental definition, we can measure it as the meaningful output of an individual, team, or organisation. Achieving meaningful output, however, takes time and focus.

The positive contributions to productivity are fairly obvious — it’s a method of communicating with other employees and provide channels for wider communications across teams and the company. There are some benefits to centralising information and notifications, connecting employees socially, and it’s good for real time communication when required.

However, the model in which these tools are used also works against productivity. It takes 10–15 minutes to build the mental model to work at on something, depending on the task and complexity. When we’re dedicating time for focused work, we’re aiming to maximise the time spent with that mental model continually being developed while working on a given task, and reduce the number of times we need to rebuild it when context switching or getting distracted. More commonly — we want to get in the zone. Research suggests that if you’re working in an un-focused manner (i.e. getting distracted constantly), your productivity nose dives by above 40%.

The core problem with messaging apps is that they are a significant contributor to distractions. The core of their product is distractions — instant messages are delivered instantly, regardless of what the recipient is doing, and with no context about the urgency, unless you allow yourself to be distracted and read the message. It is the equivalent of tearing down the walls in the office and sticking everyone at one big desk.

Their integrations with other products are also touted as a significant benefit and productivity boost. This is true in a sense — it’s nice being able to approve requests from your messaging app as a kind of notifications-hub, but we have to be thoughtful of the negative too. When you integrate yet another product or workflow into these tools, you’re adding yet another channel and source of distractions. As an example, integrating Google Workspace leads to some nice notifications about docs changes, and it’s cool being able to respond to threads from certain tools, but ultimately it’s another distraction in the form of a notification that disrupts your focus, requires you to look at the message to understand if it’s urgent, maybe deal with, then try and go back to what you were doing. That disruption takes a fraction of a second and sets you back 15 minutes.

The problem

Modern messaging apps have 3 core downsides:

1. There is no cost to sending a message
2. Messages have equal priority unless you context-switch to read them
3. They are engineered for dopamine hits at the cost of productivity and mental health

There is no cost to sending a message

When someone sends you a chat message, they write some content and press send. If they typo a message, or send something unclear, or miss context, it doesn’t matter — it’s an instant messaging platform, so they’ll just provide that context in a second message, or maybe once they get a response.

The recipient is (probably) working on something — maybe they’re writing code, drafting a response to a customer, reviewing a legal document, etc. They’re in the middle of a paragraph/code-block and hear the chat notification chime and see the notification in the top right corner of the screen. Instantly and uncontrollably, the recipient context switches to you and your message. This takes a few seconds of their time, but kills their mental model of what they were working on.

The cost to the recipient of any message is significantly higher than the cost to the sender — it takes seconds to send a message to disrupt a mental model that takes 15 minutes to build. If we compare this to the office, if you have a question for someone, walk over to their desk, and see that they have headphones on and are concentrating, you’ll ask yourself “is my question/ask more important than their focus/current efforts?”, and then choose whether or not to distract them.

Most instant messaging apps miss the ability to limit messages to only those that are urgent, and prevent all notifications otherwise. Even when you snooze notifications, in most apps the recipient still gets the message and a little notification indicator pops up in their app tray on their desktop, or in the Chrome tab. Their only solution is to fully close the application to avoid the distraction.

Messages have equal priority unless you context-switch to read them

Which of the following notifications do I need to read, context-switch to, and deal with first?

Chat applications are carefully engineered to increase the time spent using the product. They could provide a method for users to better categorise or prioritise their message importance (similar to email rules). They could provide subjects or a similar format to email for people to get at-a-glance context on the underlying messages. However, they choose not to implement these — likely because it reduces engagement.

We have to think about how humans work physiologically too. Once you’ve read a message and removed the alarming-red notification icon, you get a little dopamine hit and mentally check something off your list — you feel good regardless of whether you are dealing with the most important thing.

If someone messages me with a true urgent request, I have no way to identify that without going through each message and triaging it. If I snooze notifications, I still have to read anything I’m tagged in to triage it.

Most of these product’s design is oriented around making the user feel good, not necessarily whether their users are more productive. They want you to feel the dopamine hit you get when you’re productive, but you don’t actually need to be productive — just engaged with the product. Unless your job is to read instant messages all day, there’s a good change you feel good once you’ve closed out all of your unread messages, then feel overwhelmed by the “real” work still left to be done. In fact, you probably feel like you have less time just by having notifications and unread messages waiting, even if those notifications aren’t relevant to you.

We also have to put our business hats on when thinking about tools — as a company, why would a company who sells a messaging application push you out of their platform to do focused work, rather than making people feel productive? From a pure business perspective, if you’re selling enterprise software, you don’t want metrics that show lower engagement/less use of the product. Instead, they integrate everything and draw you in.

Productivity tools are engineered for dopamine hits at the cost of productivity and mental health.

Expanding on the above point — messaging apps has a cost to productivity through reducing focus and impacts mental health within organisations by directly contributing to the feeling of being overwhelmed.

In the same way that the world went crazy for open plan offices, companies have an undying and unhealthy adoration of “productivity tools”. We have overvalued better collaboration between teams compared to the negative impact to individuals’ productivity and ability to focus. Messaging apps are built around providing positive feedback to users when they use the product. These products’ designers, product managers, and engineers have studied the data of what gets the most engagement, and know that notifications and integrations trigger a dopamine hit roughly equating to “oh wow I have a lot of notifications, I must be working hard/valued” — similar to “likes” on Instagram or LinkedIn.

Over time this builds up and people feel overwhelmed and anxious by the volume of notifications (how can I respond to everyone immediately?), or anxious by the lack of notifications (am I not valued?). Then someone with good intentions integrates another tool — like adding Google Workspace notifications to their messaging tool — and the problem grows.

Instant messaging is a problem too — the social expectation is that the responses are instant. These product don’t encourage asynchronous discussions, and nor should they. When I’ve chatted about this with friends and family, people feel bad for not responding to messages straight away, then feel overwhelmed when there are a bunch of messages they need a response to. We’re trapped — you can either respond straight away and be overwhelmed with actual work, or respond later and be overwhelmed by not meeting societal expectations.

I don’t know anyone who can’t relate to the story of being under the crunch with ambitious goals and timelines, and being distracted and swamped with random messages and questions from people. Is it necessary?

Surely it’s not all bad?

I’m pretty open that I think that messaging apps are poorly used in the modern workplace and hurt organisation productivity — but that doesn’t mean that I don’t see their value. Instant messaging definitely has a place in the workplace — there is a lot of value in being able to quickly iterate with people, like being able to hop on a video call to hash something out, or having a central messaging channel to provide updates and context while dealing with an emergency. When there’s an incident or investigation, I am in that channel, paying attention to updates, until it is closed, and I value whatever tool we’re using.

The promise for greater productivity is a nice idea, but I think the implementation fails. It’s nice having notifications from Google Workspace in our chat applications, but I still prefer to check my email on my terms, decide what I want to work on, then reply to the notifications in the product where I have the context and focus to be thoughtful.

Like any product, a lot of the downsides in these tools are in how they are used. The more thoughtful we can be about our messaging app use, the better our experience will be. We are in control of how we use it, what we use it for, and we can remain aware of the downsides in order to mitigate them and not fall victim. We can fight instant messaging addiction and reclaim our time and sanity.

The optimal way to operate an office is to have quiet, focused areas for employees to spend their focused time with no distractions, while provide an area where they can collaborate and context switch. You need collaboration to innovate and discuss ideas, but you need focus to execute.

In the same way that there is benefit to having open spaces in offices for people to talk, hang out, whiteboard, etc, messaging apps are the same. We should be treating these as our place to talk, hang out, whiteboard, etc, not as where we do our work. Having a message app open all day and being distracted by headphones is the same as having your whole team sitting within 30cm of you and announcing everything they do. We should be closing messaging apps and focusing while executing, and picking them back up for ideation and discussion when we need to be connected.

What you can do

About 3–4 years ago while working at a previous company I was getting swamped with messages — trying to coordinate multiple teams and complex projects, with a long stream of questions and updates on a wide range of things. I remember naively feeling at the time that I was crazy busy and I didn’t know how I could get anything else done. I also felt kind of validated — I had so many messages to read and track that I must be doing something right!

After chatting through the busyness with a friend, he recommended I read Deep Work by Cal Newport. To summarise poorly (and I highly recommend reading the book), Deep Work provides a research-backed argument that the modern workplace is not built for productivity, and evidence shows that we need focused, distractionless settings to be able to work effectively. The more time we can spend in a focused state, the greater the output.

A day after reading Deep Work, I turned off all chat and email notifications everywhere, just to see what would happen. I have kept this running for multiple years now — no matter who messages me, no matter what time, I don’t receive a notification on my laptop or phone. In my messaging app profile I provide an alternative means of contact if it’s an emergency.

This is the best decision I have made in my career, and it’s the advice that I give every person who listens to me ramble for a couple of minutes. I have never had a time in which turning off notifications had severe consequences — and when someone truly needed me, they got in touch.

I also started closing messaging and email clients on my laptop (and anything else I didn’t need) if I wanted to focus. This stops the “maybe I’ll just make sure there’s no fires” habit.

In an effort to carve out better time for myself to do focused work, I also started putting large blocks in my calendar to indicate when a) I needed time to focus, and b) I was spending time outside of work, such as in the evenings. I created a full-day block on Wednesdays in my calendar which discourages people from taking my time, and as a result I have ended up with a full day where I decide my priorities, and can work in a focused way. This is by far my most productive day of the week, and where I usually find the time to work on things outside my immediately priorities (like this blog post). Putting blocks in my calendars for the evenings also provides signal to people about when I am available and helps them be cognisant of when I am spending time outside of work — they are discouraged from booking late meetings if they don’t need to.

The end result of these decisions is that I feel like I have control over my priorities, that I’m more relaxed, and that I have the time to focus on things and complete them faster and to a higher quality. It has been great for my personal life too — while I’m eating dinner, hanging out with my wife or friends, or just doing something that’s not work, I can focus on that. I can be more present and be more productive with people I care about outside of work. Sitting down for dinner and not having your phone buzz is a wonderful feeling.

Common concerns

At this point you are probably have a list of concerns or weaknesses to turning off notifications. For most of these there are usually good solutions:

How do people contact you in emergencies?

In my messaging app profile I have instructions on how to contact me if something is urgent. I ask the other person to download WhatsApp or Signal and message me there — this inflicts a cost to them to message me, and if the emergency is significant enough, they will eat that cost. If this sounds selfish — it is. If I don’t protect my time, who will?

I also provide an alternative escalation mechanism to contacting me — meaning that I am able to be paged if something goes wrong. Currently this is hooked up to a Jira queue.

If there is an emergency, I will sit in the messaging app room until it’s resolved.

Why don’t you just snooze notifications?

Why not just turn them off altogether? Snoozing is a half-effort of reclaiming your time and focus. Having notifications and allowing yourself to be distracted should be the exception — why choose to work in an unfocused way?

How often do you check for messages?

It depends, but basically when I’m between things and context switching won’t be disruptive. If I’ve finished reviewing a doc, or between meetings, I’m usually not in a focused state and will go make sure there’s nothing too urgent.

How does this solve the problem of not distinguishing high priority vs low priority messages?

I treat everything as low priority by default. If things are truly urgent, I will hear about it through other means, and I have given people a clear way to escalate urgent problems.

I can’t just turn off my notifications

Yes you can. Do it for a week. Don’t tell anyone. See how many fires occur as a result. Collect some data and determine if it’s something you value.

I’m in meetings all day, so this doesn’t really help me

Being in meetings doesn’t mean that a) you don’t need to focus in those meetings, and b) you couldn’t benefit from having more focus in the rare times you’re not in meetings. If the majority of your day is taken up by conversations, wouldn’t it be most productive to be focused during that time? Having less distractions and being more present is a better use of your, and everyone else’s, time.

In the time between meetings, if you need some time to review emails or docs, don’t check your messages. Keep yourself focused on the task at hand and make the most of the fleeting time between meetings.

When I turn my notifications off won’t I just have a big backlog to clear out?

I’ve found it useful to treat this like email. It’s fine to have a backlog of messages to clear out, and you can do that in a focused way. When I check unread messages, I first read all messages and mark the ones that need action as unread to come back to after the first review. The backlog can be intimidating, but it also gives you a good sense of the different priorities of the messages you receive — some are purely informational.