I’ve just started a new role and struggled to keep up with the writing, so thought this would be a good excuse to post an update. So here they are:

Making Waves

First up, I joined Harry Murray from Wave Talent on their Product Talks podcast . We covered:

• 🧮Going from accountancy to tech

• 🤝On being and working with founders

• 🔍Unpacking MVPs + Product Discovery

• 📚The importance of mentorship

• 🤔Going from entrepreneur to employee

Strap in, it’s 54 minutes:

Found by Few’s 'How To Get My Job'

I also joined Danielle Bowman, founder at Found by Few, where we talked about the transition from founder to employee.

If you’re short on time to watch the first one, we made this a mere 15 minutes. You’re welcome:

Or you can watch the video on LinkedIn.

That’s all for now. I’m going to try to get some new posts out soon, so watch this space.

Like many other founders I’ve spoken with, the prospect of moving into traditional employment is pretty daunting. Will companies be looking for more conventional backgrounds? What level should I even be applying for? Do my skills translate? And will employers see that?

For me, the time is right. I’ve learned a huge amount about innovation, team building, scaling and management. I’m now looking to join a place where what I’ve learned can contribute towards the mission of a more established company, and help move the world forward in some way in the short time that I’m on this earth.

Over the last few months I’ve spoken with dozens of potential hirers and founders and discovered that the journey from founder to employee is not straightforward.

In this post, I’ll share why I think founders can get overlooked as potential star hires, and try to give some practical advice to hiring managers and recruiters when assessing former founder candidates, as well as tips for founders that are looking for roles. 

It’s polarising

In my experience on this journey is that I’ve had two reactions when speaking with companies and applying for roles:

Admiration

For some organisations, the experience is highly valued - sought after, even. These are generally either scaleups with a culture that embraces entrepreneurship or founder-led organisations. 

It takes a lot to start something from scratch. Founders need courage and conviction, and the journey builds resilience and develops mature judgement.

And on the other hand…

Fear

For more traditional organisations, but also some scaleups, founders can trigger an almost fight or flight response. Especially organisations that are past the stage of being founder-led.

I believe this is driven simply by unfamiliarity.

Founders are uncommon, since most people don’t start businesses. I don’t know the exact statistics but if you’re recruiting for a product manager role for example, at a guess maybe 1 in 20 CVs have ‘founder’ in the job history. 

Since they’re a small population, it makes it really difficult for hiring managers and recruiters to know what to do with them. They likely did not match the brief that was imagined when thinking about the role requirements. It’s simply easier to review the other 19 CVs.

Also, the prevailing image of a founder probably isn’t someone you’d want working for you. Elon Musk, Steve Jobs, Mark Zuckerberg. Obviously these aren’t representative, but maybe this is the image that comes to mind for some when they see ‘founder’ in the job history?

Founders often don't fit the conventional mould. They’re misfits, taking the path less trodden, making them unpredictable in the eyes of hiring managers. Better to stick to someone with a conventional background, right?

The trough of despair

I’ve spoken with some founders who have had a really tough time trying to transition from founder to employee. Here’s one such story by Ted Skyba who made over 1000 applications in his search for a role after building his business to a $250m valuation.

“No one from more than 1000 companies recognised in me the person every founder is looking for — the one who will treat business like their own.”

I’ve spoken with other founders who feel like the deck is stacked against them when looking to transition into traditional employment. Some give up entirely, going back into entrepreneurship out of perceived necessity rather than choice.

But there’s hope

Reassuringly, I have met several former founders over the last few months that found gainful employment.

They all experienced a lot of the same challenges, but they all found ways to overcome them, and to leverage their startup experience as an asset that was relatable to the employer.

I’ll share what I’ve learned from them and how I’ve approached my own search. But first, here’s advice for recruiters and hiring managers that get a founder CV in their pile of applications.

Advice for Hiring Managers + Recruiters

Seek to understand

The first hurdle is to understand what being a founder is, and what motivates the candidate. There are a few frameworks to categorise founders into archetypes that focus more on job roles than motivations. The Hipster, Hacker and Hustler classic for example.

But what’s most interesting is what drives them. What’s their passion and motivation? Why did they have the burning need to start a startup? And how might that burning desire translate into working with you?

I’ve had a go at defining 3 common motivators that drive people to become a startup founder:

Proprietors

Stubborn, Forever Founder, Autocratic

I’ve stolen the term from here, but this describes what I think is often the caricature of the entrepreneur. The one that simply would never work for someone else. 

Kevin O'Leary from Shark Tank stands out as an example here. He lasted 5 minutes in employment before vowing never to work for someone else:

"I realised then that when you work for somebody else, you're basically their slave. From that day on I swore I'd never work for anyone else. That was the beginning of my journey.”

I think these are pretty rare, maybe 5% of founders, but they are disproportionately represented in coverage so it feels like there are more of them.

They’re not going to submit a job application to work at your company, so don’t worry about them.

Missionaries

Passionate, Ambitious, Courageous

These founders are driven by a cause. They're a great fit if they believe in your company's mission. 

This is most founders. Driven by purpose, optimism, ambition, and the desire to have an impact on the world.

I’d put myself in this camp. My co-founder of 10 years, Sam, too.

I would hazard a guess that most founder job applications you receive are from this type of person - they’ll simply be looking for a new mission and purpose to pursue with the same passion they once through at their own startup.

Technician

Exceptional, Craftsperson, Superhero

I don’t want to suggest that we should take too many learnings from FTX’s corporate structure, but a Technician is a lesser seen founder that is simply an incredibly talented specialist in their field. 

These founders are less common since they are more specialist than generalist, and generalism is the muscle you see in most founders.

These 10x types might excel in senior individual contributor roles rather than management positions.

Diversity of Experience

It’s an unfortunate byproduct of human nature that we like to associate ourselves with people who look like, think like and act like ourselves. Diversity initiatives help to correct for this by promoting diversity across gender, race and background.

Overlooking founders because of non-traditional job histories I believe is a missed opportunity to create diversity of experiences within organisations. 

Job applications will often be filtered at the start of the process by looking for traditional role progression - consider instead throwing in some founder CVs in there too that don’t fit the mould. You may be pleasantly surprised.

Dig deep

Understand their motivations and passions. Understand what their unique experience is and what they’ve learned from it. Don’t pigeonhole them (yes, I know I literally explained a founder pigeonholing framework about 2 seconds ago).

Drive into gaps and weaknesses - chances are they will be pretty self-aware. 

You may have to go off script from your usual line of questions.

A friend of mine put it like this:

“If you’re not considering founders, you’re going to miss some unbelievable people. Have an approach for unconventional CVs.”

Advice for Founders on the Job Hunt

All that said - it’s incumbent on the job seeker to do the work. I know I’m influential, but chances are this post won’t reach everyone it needs to. So here’s my advice on seeking work as a founder that’s recently handed in their badge and gun.

Find Your Box

When I started my first startup in 2012 after leaving the corporate world, I discovered what product management was, fell in love with it, and decided that I was going to position myself in that track. Having wrapped up as CPO at Coconut, I’ve found it fairly easy to go for product roles.

Prospective hirers definitely raised the fact that ‘My CV looks different to other product managers/leaders’. But it was close enough to be considered alongside them.

However, speaking with other founders, they completed their founder journey in a more ‘generalist’ position. Should they become a Marketer? BizDev? Sales? Product? 

I think this is part of the challenge that Ted Skyba had. You can’t market yourself as a swiss army knife when companies are looking to hire a stanley knife.

Ultimately it’s a positioning exercise. What does the customer/employer want, and how do I communicate my profile in a way that fits with that. This will probably mean leaving loads of good stuff out. Since you’ll have a ton of experience that simply doesn’t match up to the job requirement for what you’re going after.

Focus on your strengths. But with a founder flavouring to them that adds something special.  

This might mean tailoring multiple CVs for different roles.

If you do this then you will have to make sure your LinkedIn profile somehow works with it. I didn’t have to do this myself so my advice stops there.

I started off with a simple 1 pager CV for the first couple of months of my search. This gave me time to figure out exactly what people were looking for, which meant when I came to do it, I could do it well. That said - I should have made my CV sooner. 

I was over-reliant on my personal connections, warm intros and company reputation. But then this didn’t carry over once my CV got cold forwarded internally. I think I lost out on some opportunities as a result.

Know What You Want 

The founder background is already making people’s flight or fight brains trigger - don’t add to it by also introducing uncertainty in what you’re looking for. 

I had a clear thesis of what I was looking for that I arrived at in the first few weeks of my search. It was also sufficiently broad to keep enough opportunities open to me.

Looking for a product role within fintech, series B to corporate, in early stage businesses or new or early stage products within a product portfolio.

This fit in with my startup background so that I could sell that experience as a plus, probably outperforming candidates that had more traditional backgrounds. That was my thesis at least.

It’s hard for everyone

“No one gets back to my job applications because I’m a founder”. I think this is wrong. 

Speaking with non-founders they have exactly the same experience as founders when it comes to the job application process. Ghosting is commonplace, automated rejection emails if you’re lucky.

Don’t be downbeat thinking that you’re not getting bites since you’re a founder. It’s tough out there for everyone looking for a new role. It takes work and time.

Here’s my funnel

I think my funnel stats are useful for founders looking to embark on the process, here’s mine. Obviously everyone’s journey is going to be different.

I had ~100 meetings with prospective employers, recruiters and potential introducers over 4 months. One of those months was August which was pretty dead. I’d expected the process to take 3-6 months based on conversations with other founders.

I submitted my CV against 14 job applications. I opted for leveraging my personal contacts and networking on LinkedIn over submitting cold job applications, since the hit rate is so low (expect ~1% for cold applications).

Of my 14 job applications, 7 of those were cold - I did a few just to test the theory that they don’t really work. That said, 1 did lead to interview, but it landed on the desk of someone I knew. The rest I received no response or auto-rejection.

The remaining 7 warm ones were through personal connections and networking. 3 of those led to formal interview processes, the other 4 I had initial conversations but timing wasn’t right for one reason or another.

I went through 4 formal interview processes in total.

I got 1 job offer. I took it.

(I got an offer halfway through writing this - in case you’ve noticed the tone change, that’s why!)

I think I got incredibly lucky to have the conversion rate on interview to offer that I did - I’d been advised by recruiters to expect to be doing several interviews per week.

I avoided doing lots of applications to companies I couldn’t see myself being passionate about working with. A downside of this was limited interview practice. I had to prepare well to counter this, researching interviewers thoroughly and scripting out my ‘stories’ to use in response to ‘tell us about a time when’ questions.

Everyone asks these 2 questions

1. Why aren't you starting another company? 
2. Can you work under someone? 

Be ready with your answers. It’s a chance to sell yourself, and also educate them on founder misconceptions.

For me - I started companies because I want to have an impact. I believe my best way to continue doing that is to join an org that’s doing something exciting, where my entrepreneurial experience can have a disproportionate impact. 

And for 2 - running a startup does not make you unaccountable to others. We had a board of directors, we had investors. We had a team that we were accountable to - leading them with influence rather than absolute authority. Running a startup requires collaboration just like any other job.

Find your sponsor

Given the ‘some people get it some people don’t’ dynamic with the founder background, it’s important to win over a sponsor, usually the hiring manager. 

This isn’t really founder specific advice. But the chance of there being someone with influence over the decision who’d prefer making a more traditional hire increases the overall risk of their being a voice of descent in the process.

It’ll ultimately be up to the sponsor to make the call and push on your behalf, so clearly addressing any concerns surrounding that up front should help with that.

This doesn’t always work. Some companies’ hiring processes allow for sponsors to influence the outcome more than others. 

===

I hope this post helps to give a few more of the unconventional adventurers that are startup founders a shot at getting amazing roles in ambitious companies. Any questions or comments feel free to hit me up on LinkedIn.

So, I’ve got some thoughts on Open Banking to say the least. Tom Beckenham (Founder of Comma now VP at Weavr) recently posted about his pet peeves with Open Banking, which got me thinking about mine.

The way the UK has approached the requirements to open up their data and create secure, reliable APIs for Third Party Providers (TPPs) to integrate with is way more joined up than those in other countries.

PSD2 requires EU banking providers to provide API access to TPPs, but doesn’t provide a standard in how to do that. And the US are only just getting round to introducing Open Banking regulation which is much needed - without it I’m sure we’ll continue to see things like Fidelity recently turning off their support for anyone not using their preferred aggregation provider, Akoya.

So - the standard is great. Well done UK. Great work.

But, if you are a TPP or aspiring AISP looking to get into the Open Banking game, I’ve collected a list of gotchas that you might encounter when implementing account aggregation services. If you’re looking to use an aggregation service like Plaid, TrueLayer or Yapily, or even connect directly, then this list should help you navigate some of the lesser known nuances of working with Open Banking data.

Descriptors are non-standard

Here’s an example of the raw descriptors for Starbucks transactions in London:

Amex        STARBUCKS LONDON
Barclaycard Starbucks, London
Barclays    STARBUCKS COFFEE ON 01 OCT CLP
HSBC        STARBUCKS LONDON
Lloyds      STARBUCKSMBNA STARBUCKS LONDON GBR
Monzo       Starbucks
Nationwide  Contactless Payment STARBUCKS
Natwest     3041 01OCT CD STARBUCKS LONDON GB
RBS         STARBUCKS LONDON GBR GBR 7779
Santander   CARD PAYMENT TO STARBUCKS ON 07-11
Starling    STARBUCKS LONDON GBR
Tide        STARBUCKS LONDON

Banks use some combination of the following:

• Merchant Name

• Merchant City/Location

• Merchant Country

• Authorisation Date

• Payment Method

This problem usually gets solved at the aggregator level through some kind of transaction enrichment service. Most of the time you’ll get ‘Starbucks’ out.

But making a purchase using Santander at your local, single branch coffee shop? There’s a long tail of merchants that may not be covered by your chosen enrichment method. 

In my experience this was pretty Pareto - about 20% of transactions representing 80% of merchants. At Coconut we had to build our own algorithms to cover the long tail, which duplicated the effort that had already been done by our aggregator provider for the more popular merchants.

Dealing with Payment Processors

Payment processors like Curve, SumUp and Zettle appear in transaction descriptions, but they’re not the merchants. Depending on how you approach merchant identification, you need to cater to stripping these out effectively to avoid getting this:

CRV*Trainline CD 3226            > Curve
SumUp *Mobilegear Ltd            > SumUp
Zettle_*Black Sheep Co Guildford > Zettle

When you want this:

CRV*Trainline CD 3226            > Trainline
SumUp *Mobilegear Ltd            > Mobilegear Ltd
Zettle_*Black Sheep Co Guildford > Black Sheep Co

This sounds obvious and really depends on whether your merchant identification is done through regex and algorithms or a machine learning model that isn’t as good as a human at picking up on what the merchant name should be when there are a couple mentioned. 

I can’t really think of use cases where you want to keep the payment processor prefix, so I think most people will want to strip them out. Here’s a pretty decent list along with some regexes to get you started, use at your own risk:

2Co                 ^2CO\.COM\*(.+)
Curve               ^CRV\*(.+)
EventBrite          ^EB\s\*(.+)
GooglePay           ^GOOGLE\s+\*(.+)
Kashing             ^KASHING\*(.+)
Klarna              ^KLARNA\s*\s(.+)
MangoPay            ^MGP\*(.+)
PayPal              ^PAYPAL\s+\*(.+)
PayPoint            ^PPOINT_\*(.+)
Secondary Purchases ^SP\s(.+)
Skrill              ^SKR\*(.+)$
Square              ^SQ \*(.+)
Sumup               ^SUMUP\s+\*(.+)
WePay               ^WPY\*(.+)
Zettle              ^ZETTLE\_\*(.+)
ZTL                 ^ZTL\*(.+)

You’ll want to figure out ApplePay too, but that one requires a bit more effort.

Timestamps aren’t available on everything

Some banks offer timestamps, some just give dates (ie all transactions take place at 00:00). A knock on impact of this is that you can’t match the transaction ordering in the banking app that the user sees, which can sometimes lead to customer queries:

Provider      Timestamps?
Amex          No - date only
Barclaycard   Yes
Barclays      Yes
HSBC          No - date only
Lloyds        No - date only
MBNA          No - date only
Monzo         Yes
Nationwide    No - date only
Natwest       No - date only
RBS           No - date only
Revolut       Yes
Santander     No - date only
Starling      Yes
Tide          Yes

The common theme being that neo banks provide timestamps, high street banks don’t.

This means if you want to try and check running balances in your bank account versus those in the TPP app (eg PFM or Accounting app), you can’t. At least not intra day - you have to check the day’s closing balance from accounting app to bank statement. 

Running balances aren’t always available

What’s more is that running balances are available on some providers, not others. But also this is not an exact science which we’ll come to, since the running balance on a transaction can change (yes, that’s right):

Provider      Running Balance?
Amex          No
Barclaycard   Yes
Barclays      Yes
HSBC          Yes
Lloyds        Yes
MBNA          Yes
Monzo         No
Nationwide    Yes
Natwest       Yes
RBS           Yes
Revolut       Yes
Santander     Yes
Starling      No
Tide          No

The common theme being this time that neo banks don’t provide running balances, high street banks do. Probably because if we used the timestamps to try to confirm the transaction ordering and check the running balance is right, it would probably open a can of worms. So I guess it’s one or the other.

Also given the high street banks have had many more years to get their running balances in order. It’s a harder problem than you might think.

References aren’t always there

Want to apply logic based on references? Well you can’t because some banks don’t provide them. At Coconut we used payment references to automatically match incoming payments to invoices - it meant this feature simply was not available if you used Revolut or Nationwide.

Most banks provide the reference in the descriptor - some put a delimited (eg ‘ref:’) so you can unpick it. Some just stick it at the end, so you can’t figure out what’s descriptor and what’s reference.

Provider     Provides Reference?
Barclays     Yes - Part of descriptor, no delimiter
HSBC         Yes - Part of descriptor, no delimiter
Lloyds       Yes - Separate reference field
Monzo        Yes - Reference is the descriptor
Nationwide   No 
Natwest      Yes - Part of descriptor, no delimiter
RBS          Yes - Part of descriptor, no delimiter
Revolut      No
Santander    Yes - Part of descriptor with delimiter
Starling     Yes - Reference is the descriptor
Tide         Yes - Part of descriptor with delimiter

And if you’re Monzo or Starling, you put the reference in the descriptor.

Monzo/Starling Descriptors are References

For some reason, Monzo and Starling have mapped their ‘references’ to ‘descriptors’ in the API. I think because the ‘reference’ usually contains a description of what the transaction was for (eg birthday money) rather than who it was with (eg Mum). They have a separate ‘counterparty’ field for ‘who it was with’.

I’m sure they have their reasons for doing this. But from a TPP perspective it means these banks behave differently to all the others. Our approach was to flip these back, putting counterparty to descriptor and descriptor to reference.

Starling Spaces != Monzo Pots

While we’re on the subject. You’d expect Starling Spaces and Monzo Pots savings products to work the same, right? They don’t. 

Starling Spaces are not separate accounts available through their API, instead their balances get added into the current account balance. This leads to support tickets asking why Starling app balances don’t match what the TPP is showing.

Monzo Pots are linked to their parent current account, but they are separate accounts. Although you cannot separately decide on whether they are imported, as consent is provided at the parent account level.

Most other banking apps simply treat savings accounts as separate accounts: separate balances, transactions and consents.

Transaction types are non-standard

Want to have special logic based on whether a transaction is a card purchase, direct debit or bank transfer? Well, each bank passes through this data differently.

Across all accounts all transactions we’d see a split that looks like this:

• Payments In 20%

• Payments Out 20%

• Card Purchases/Refunds 50%

• Direct Debits 8%

• Bank Fees 1%

• Cash Withdrawals 1%

These all have their own traits. Card Purchases and Direct Debits all have a merchant at the other side of the transaction that will look identical no matter who buys from them. For Payments In, the descriptors are set by the sending bank, so they also look identical across different users.

But for Payments Out the descriptors are set by the user - two users sending to the same account may look different. The introduction of Confirmation of Payee has started to reduce this inconsistency, but it very much depends on the bank’s UX. 

There’s nothing to stop me writing weird and wonderful names in my banking app. Especially for my own accounts where I’ll often write the bank name rather than my own name, since having 4 accounts called ‘Adam Goodall’ is not helpful for me. This is widely common practice for people to write ‘Chase’ as the account name on their Chase account when sending from their HSBC account, for example.

Knowing the transaction type is therefore useful for picking up on the nuances surrounding each type. The problem is that, you guessed it, you don’t get this reliably.

Barclays doesn’t provide transaction type in the proper field, but instead appends a transaction type code to the descriptor that you can use to identify the transaction type yourself. We had to write custom code to do this.

Santander puts the transaction type in long form at the front of each descriptor (eg ‘Faster Payment to xxx’), so you have to use those to imply the transaction type, and then strip them from the transaction descriptors to make them readable, particularly on mobile devices.

In an ideal world your aggregator provider has done this for you. If they’ve made Barclays work then that’s a good sign that they understand this problem.

Duplicates happen

And it depends on the bank as to the causes. Each one a different edge case. At Coconut we wrote a deduplication service that could automatically identify duplicates and merge them with some success. But it’s an industry-wide problem.

Transactions can disappear

This happens less. When we operated a current account we would have reversing transactions take place - not refunds, but reversals of previously cleared transactions. These would sometimes come back out as a separate balance-affecting reversal. But sometimes they would simply revert the original transaction. It seemed to depend on the time being the clearing and the reversal.

Mostly when transactions ‘disappeared’, they would reappear under a different transaction ID (see below for transaction IDs changing).

Transaction amounts can change

That’s right, post clearing too. Foreign card transactions change amount from pending to clearing when the rate locks in. But post clearing, amounts can change - typically car rentals, airlines etc where merchants seemingly have superpowers to bend the rules of time and space, applying additional charges by rewriting history on a cleared transaction value.

On Coconut’s current account product, we’d see accounts go into negative balance by cleared transaction amounts changing after the fact. These were different to pre-authorisations. Post-authorisations?

The Mastercard processing rules are a heavy read but there are plenty of mentions of reversals, corrections and errors that can lead to movements in seemingly cleared transactions, which I think is the cause of the behaviour we observed (it was always card transactions).

In Open Banking, this means that you will observe transactions changing amount when you go back and hit the API a day later for the same transaction. I think generally though the window for change is finite and short. 

To be honest we didn’t have much trouble with this - we just updated the amounts when we saw them change using a 14 day rolling window, which worked in our product context.

Transaction dates can change

Yep dates can change too. Either through very odd edge cases that almost never happen, or sometimes a change with a banking provider (neo banks) in how they serve the transactions.

Transaction descriptors can change

And of course descriptions can change. It’s rare, it seemed to affect foreign transactions most and probably a function of the clearing process. 

Transaction IDs can change

And if all that can change, why not let the IDs change too. Our aggregator introduced a feature offering persistent IDs on transactions to help with this. But it was not supported on all banks. This certainly didn’t help deduplication efforts, since you could not rely on the IDs.

Transaction IDs aren’t unique

And if they can change, let’s make them not unique while we’re at it. HSBC comes to mind with this - the way they present FX fees is to have a separate fee transaction but with same ID. This means any deduplication logic needs to not infer two transactions as being duplicates if they have the same ID. But adding in the amount as well works in the HSBC case.

We’ve come a long way

Let’s not forget, before 2018, millions of banking customers in the UK and globally were handing over their online banking credentials to screen scraping providers like Yodlee and Salt Edge to store in decryptable format in their databases. They would send their robots to login to online banking services every day using those credentials, and download the latest transactions to serve them up through an API to TPPs.

Thank the lord those companies kept those credentials safe. It would have been pretty world ending if they hadn’t. But it was also common for those services to go down whenever the bank updated their web portals. Banks sent letters to customers telling them to stop using TPPs that used this technology, harming competition and consumers in the process.

Through Open Banking we can now manage consent, get secure feeds with decent uptime, and transaction data in a somewhat standard format. And hopefully this article helps you navigate the last mile of working with Open Banking transaction data.

(PS. If anything I’ve written here doesn’t make sense based on your own experience working with Open Banking data, this was my experience using TrueLayer as the aggregator)

“I’m passionate about learning, and love to read. Writing up book summaries lets me consolidate learning and share my best reads with others. Enjoy…”

At Coconut, my second startup, we employed some of Amazon’s working practices - namely the 6 pager and the PR/FAQ. I wish I’d have read ‘Working Backwards’ to really understand the power and provenance of these tools.

The book, by Bill Carr and Colin Bryar, offers readers a behind-the-scenes look at Amazon's culture, leadership principles and unique processes. Many ex-Amazonians have since taken the practices to other companies now. When people say their company does things in an ‘Amazon way’, this book has helped me understand what they mean.

No powerpoint, 6 pagers, PR/FAQs aka Working Backwards, leadership principles, bar raisers to name a few, Amazon have developed a number of counter-intuitive but highly effective practices that every company should consider deploying. 

Amazon Leadership Principles

Most companies try to steer their culture by codifying values that they want their employees to live by. These will typically live on a careers or about page on a company’s website and serve both to communicate to customers the brand values of the business, whilst also being used to assess new hires, and measure employee performance. 

Amazon does things differently. They have a set of ‘Leadership Principles’ instead. There are 16 of them. Way more than any company would have for its equivalent ‘values’.

They do however have four ‘principles’: customer obsession rather than competitor focus, passion for invention, commitment to operational excellence, and long-term thinking. Maybe these are their ‘values’. But it’s a fundamentally different architecture to most companies. 

The leadership principles are:

1. Customer Obsession: Amazon places customers at the centre of everything it does. This principle emphasises the importance of understanding customer needs and relentlessly working to exceed their expectations.

2. Ownership: Amazon values leaders who take ownership of their projects and decisions. This principle encourages accountability and the willingness to go above and beyond to deliver results.

3. Invent and Simplify: Amazon promotes a culture of innovation and continuous improvement. Leaders are encouraged to question the status quo and seek innovative solutions to problems.

4. Are Right, A Lot: This principle highlights the importance of making data-driven decisions and being willing to admit when you're wrong. It encourages a culture of constructive debate and learning from mistakes.

5. Learn and Be Curious: Amazon encourages employees to never stop learning and to continuously seek new knowledge and skills. This promotes a culture of personal and professional growth.

6. Hire and Develop the Best: Amazon places a strong emphasis on hiring exceptional talent and investing in their development. Leaders are expected to raise the bar for talent within their teams.

7. Insist on the Highest Standards: This principle underscores the importance of maintaining high-quality products and services. It's about setting and achieving ambitious goals.

8. Think Big: Amazon encourages employees to think long-term and envision bold, ambitious projects. This principle promotes innovation and the pursuit of transformative ideas.

9. Bias for Action: Amazon values quick decision-making and action. It emphasises the importance of avoiding paralysis by analysis and being willing to take calculated risks.

10. Frugality: Amazon is known for its efficient use of resources. This principle encourages employees to be mindful of spending and to find cost-effective solutions.

11. Earn Trust: Trust is paramount at Amazon, both with customers and among colleagues. This principle emphasises the importance of integrity and transparency.

12. Dive Deep: Amazon leaders are expected to understand the details of their business thoroughly. This involves digging into data and being hands-on when necessary.

13. Have Backbone; Disagree and Commit: Healthy debate is encouraged, but once a decision is made, it's important to commit fully and execute with determination.

Three more have been added since the book was written: Deliver Results, Strive to be Earth’s Best Employer, and Success and Scale Bring Broad Responsibility. 

Two-pizza teams

You’ve probably heard of two pizza teams. What you might not have heard about was that this was partially borne from Amazon’s early monolithic architecture, aka ‘Obidos’ - named after the fastest part of the Amazon River. But also - the narrowest part. As the tech scaled, dependencies multiplied, and shipping small changes to one part of the system would cause things to break in seemingly unrelated areas.

Amazon decided to reorganise itself into small, autonomous teams. Ones that can be fed with just two pizzas. Combined with a focus on building tech and API-based services that sought to reduce dependencies in order to achieve team autonomy, and rapid execution.

Not to conflate this with micro-services. Amazon themselves have gone back and forth with micro-services. It’s about building your organisation team-first, respecting Conway’s law, and finding the natural fracture planes that let you split your teams in a way that supports manageable cognitive load and ‘single-threaded’ leadership.

Single-threaded Leaders

You may have read Peter Thiel’s book Zero to One, where he talked about his approach at PayPal of giving each leader just one thing to focus on. Well Amazon does this too. They called it being ‘single-threaded’, focusing on just one goal. It enables leaders to avoid doing many things badly, instead doing just one thing brilliantly.

No PowerPoint

Amazon famously banned PowerPoint presentations in favour of well-structured narratives. This encourages clear thinking and effective communication. They commonly use 6 pagers to read at the start of meetings, replacing the typical slides+presenter process as part of a meeting kick off. Why do this? They explain:

• Slide decks don’t allow the connections between ideas to be made versus written narratives

• Too much weight is given to presenter ability to determine the success or failure of the meeting

• Meeting participants can easily derail a presented narrative by jumping ahead with questions, breaking the presenters flow and worse still undermining them in the process.

• Group think can ensue by completing a polished presentation and asking for questions at the end - first to speak will set the tone.

Presenting written narratives at the start of the meeting, and swapping the presentation time for reading time means:

• Ideas speak for themselves, rather than being carried (or failed by) by presenter gravitas

• Readers have time to write questions and contemplate the information, before hearing and being influenced by others’ contributions.

• No time is wasted, since the reading time would have been used by presenting time anyway.

They warn not to require the document to be circulated beforehand - it adds pressure to the preparers and the readers to read in advance. And inevitably at least some people won’t read in advance, meaning you need to take the reading time anyway or start the meeting with everyone out of sync.

I personally love this approach, and plan to use it more than I have done in the past. It feels incredibly unnatural, but it makes a lot of sense.

‘Working backwards’

The "Working Backwards" process is central to Amazon's product development. It starts with writing a press release and FAQ document (aka a PR/FAQ) for the product before any code is written, forcing teams to think through the customer experience first.

We used these at Coconut, they’re great. They focus the team on the customer impact, market opportunity and connecting the solution to it. It makes sure that the product solution keeps its focus on solving the customer problem. And acts as an artefact for product marketing and launch communications from the very start of the project.

‘Bar Raisers’

Amazon sets high hiring standards, and the company is constantly working to raise the bar for talent. Leaders are expected to be actively involved in the hiring process. 

I recently went through an Amazon-esque interview process, and it was quite different to other companies I’ve interviewed with for a few reasons:

• Interviewers dive deep into one principle/value, rather than trying to cover them all off.

• All interviews are one to one, not one to many (not sure if this is an Amazon thing)

As a result they are much more conversational, more fluid, I think because of the dive deep approach - it means interviewers can continue the conversation by building on the previous question. Rather than having to move on in a hurry trying to cover off all the company values in a single session. I much preferred this and it’s made me reflect on my own interviewing style.

The job of the ‘Bar Raiser’ at Amazon is to make sure the process is followed to ensure great talent gets hired. Once interviews are complete, interviewers must write up their feedback straight after including a hiring recommendation - (strongly) inclined/not include to hire - undecided is not an option. 

These recommendations have to be put forward without having any feedback from other interviewers to avoid leading the witness. Finally, they come together and discuss the feedback as a group for the hiring manager to make a decision based on the recommendations. The Bar Raiser in the room also gets a veto, should the hiring manager make an obviously wrong decision - something Amazon only have on record happening 3 times in their history.

What stands out about Amazon’s processes is that they really understand our human biases, and create processes to minimise their impact and save us from bad decisions.

Web Services, Prime, Fire, Kindle and more

The second part of the book goes into detail on the journey delivering many of Amazon’s famous initiatives, the failures that took place to get to the products we know today, all while referencing the implementation of the practices it discusses in the first part of the book. I won’t go into any of these here, but if you’ve consumed any of Amazon’s services (who hasn’t?), you’ll find this a fascinating read.

You can buy Working Backwards on Amazon.

I’m passionate about learning, and love reading books. Writing up book summaries and reviews helps me consolidate learning and share my best reads with others. Enjoy…

I recently read "Decisive” by Chip Heath and Dan Heath, one of the best reads I’ve had in a while. It was a cathartic read, replaying many decisions I’ve made either myself or in teams, and thinking through how they might have played out differently had I applied some of the lessons here.

Decisions are hard, namely because of the devils of bias on all our shoulders that help nudge us in the wrong direction. This book has a few simple principles to bring structure and process to help reach better decisions.

The authors state early on that the research and academia surrounding decision making is complex and often borderline impenetrable outside of those that dedicate their careers to research on the topic. They have intentionally written the book in a way that the lessons are simple enough to be held in the average person’s brain the next time a decision making process comes their way. 

Heath & Heath explain the biases that we commonly encounter, including:

1. Confirmation Bias: The tendency to seek information that confirms preexisting beliefs, leading to a one-sided view of a situation.

2. Narrow Framing: Focusing on a single aspect of a decision while neglecting the broader context or alternative options.

3. Short-Term Emotion: Allowing strong, immediate emotions to drive decisions, often at the expense of long-term goals and rationality.

4. Overconfidence Bias: Overestimating one's abilities and underestimating the likelihood of negative outcomes, leading to risky choices.

5. Hindsight Bias: Believing, after an event has occurred, that the outcome was predictable all along, which can distort one's evaluation of past decisions.

6. Sunk Cost Fallacy: Continuing to invest in a decision or project based on prior investments, even when it's clear that continuing is not in one's best interest.

7. Anchoring Bias: Giving disproportionate weight to the first piece of information encountered, often leading to skewed judgments.

8. Availability Heuristic: Relying on readily available information or recent experiences to make decisions, which can lead to skewed perceptions of probability.

9. Groupthink: Prioritising consensus and harmony in group decision-making, often at the expense of critical evaluation and diverse perspectives.

10. Status Quo Bias: Preferring the current state or sticking with the default option because change or deviation requires more effort or perceived risk.

I’ve seen all of these play out through myself and others. I’ve had sometimes had success at reducing or removing their influence in the past, sometimes less so. 

To focus on just one of these - Narrow framing often comes up in the discussion of ideas for product development. There are loads of good ideas that make sense to execute in isolation, but they’re almost always a trade off that needs to be considered against their opportunity costs. 

More substantial, one-off decisions can arrive in a context of ‘do we do this or not’. I can think of several decisions that I’m sure we’d have made differently if we’d approached them using the advice to ‘widen your options’ (below), and instead considering the trade-offs and alternatives, and deciding instead on ‘which do we choose’. 

Tackling these biases, Chip & Dan suggest the following four pillars. What’s nice is that they are pretty much sequenced along the decision making journey, from identifying the decision to be made, evaluating it, making it, and learning from it.

1. Widen Your Options: The authors argue that many decisions fail because people limit themselves to a narrow set of options. To overcome this, they suggest techniques like considering the opportunity cost of your choices, exploring "multitracking" (pursuing multiple options simultaneously), and seeking out diverse perspectives to expand your choices.

2. Reality-Test Your Assumptions: Decisions often go awry because they are based on flawed assumptions. The book encourages readers to challenge their assumptions by gathering more information, conducting experiments, and testing their beliefs. It introduces the concept of the "ooch" – a small-scale, low-risk experiment to learn more about a potential decision.

3. Attain Distance Before Deciding: Emotions can cloud judgment and lead to impulsive decisions. The Heath brothers suggest that you should create emotional distance by imagining you're advising a friend or by taking a step back from the situation to gain perspective. This can help you make more rational choices.

4. Prepare to Be Wrong: Accepting that you might be wrong and embracing uncertainty is crucial in decision-making. The authors recommend adopting a "bookend" approach, where you consider the best-case and worst-case scenarios. By preparing for both outcomes, you can mitigate risk and make more robust decisions.

Thanks to the Heath bros for this great read. You can pick up your copy here.