Hi Yaniv, great to have you on Startup Stories!. For those who may not know, can you please tell us a little bit about yourself and your career background to date?

Some people always dreamed of being an entrepreneur, or have been hustling since they were teenagers. Neither of those apply to me. 

I am a software engineer by trade. After doing a Computer Science degree at University of Melbourne, I ran headlong into the Dot Com bust. There were no jobs, so I ended up starting a PhD at RMIT University in the area of search engines. This turned out to be a stroke of luck: I learned a lot, had a good time, and saw my confidence grow. Instead of ending up at a local Microsoft shop, my expertise in search engines saw me graduate into a job at Google. In 2006 it was already a very large company, but nothing like the behemoth it is today.

I spent ten mostly happy years at Google, working across the Search, YouTube, and Maps divisions. I was surrounded by smart people and learned a huge amount about building high-quality software at global scale. But after ten years, my pace of learning had slowed and I was itching to spread my wings in a way that it was not possible to do at any large organisation.

After a short stint at another scale-up, I found myself as VP Engineering at Airtasker. The engineering team there has achieved an enormous amount, but of course when a new leader is brought in, that is usually because something needs to change. The engineers at Airtasker needed to adapt to operating with a larger team and at a greater scale. 

What was interesting to me was that while there was a significant technical aspect to my role, the real meat of the work was about people, culture, and organisational design: how we worked together, what we valued and rewarded, who we hired, how people were held accountable, and so on. As much as I loved the technical side, I found building and operating a high-performing organisation to be even more fascinating.

From there, it was a natural progression to broaden out my role from VP Engineering to COO: now, instead of working just on a single function, my job was to make sure all the functions at the organisation worked well together towards a common set of goals. I was fortunate to be allowed to expand in this role at Airtasker, and I learned a huge amount there.

When I left Airtasker, I wasn’t sure what to do next. I consulted, coached, and advised many startups and scale-ups. As I did this, I noticed so many repeated patterns, so many places where organisational failings held these companies back from achieving their full potential. And I realised I was not going to be able to help very much just as an advisor.

Finally, I realised that to manifest the sort of organisation I really wanted to work at, I was going to need to put my money where my mouth is: I was going to need to be a founder. When I met the rest of the founding team at Circular, I knew that these were the people I wanted to build an incredible business and organisation with. That was over a year ago, and we haven’t looked back.  

What has been the most rewarding aspect of your startup journey so far?

The answer is, as it often is, the tremendous people I get to work with. But that’s a boring answer! So here’s another thing I’ve found rewarding:

I love how “real” building a startup is. At larger companies, there are many layers of support and safety built into what you do. But those layers of cushioning also serve to dull your senses to the realities of the business at which you work, and all the things that go into making it successful. 

At a startup, there are no cushions. You are fully exposed to the realities of what it takes to succeed, and this rawness and danger sharpens your senses and makes you feel alive. It’s the work equivalent of doing an adventure sport!

How has Circular evolved since its inception? What have been some key pivots or changes you’ve made along the way?

Circular is still a young company, just one-and-a-bit years old. But in that time, we have gone through Y Combinator (a well-known accelerator program), raised significant capital from incredible investors, and gone from a handful of people to a little over 30. 

Most importantly, we’ve grown from nothing to well over 1000 paying customers across two countries. We’ve had to go from proof of concept to running a real and operationally complex business. Our aim has been to keep a culture of ownership and responsibility while thoughtfully adding those layers of process and infrastructure that allows us to serve our customers and keep growing to the next level.

We’ve not had to pivot yet! But of course, as an early-stage startup you need to always be alive to the possibility of major changes in direction. The most important thing is to keep an optimistic but unvarnished view of reality as you go on the learning journey. 

Can you walk us through a typical day in your life? What does your schedule look like and what are some of the most important tasks you focus on?

I’ve never had the capacity to work long hours. This has at times been a source of guilt and Impostor Syndrome, but you can’t fight your body! Instead, I try to make the most of the focus and attention I’m capable of. 

I am also an active parent of a delightful 8 year old, so it’s important to me that I participate strongly in her life. A typical day often includes school drop-offs, family dinner, family walks, and bedtime stories. My work life can be intense, but these other parts of my life are both a duty and a joy, and are not something I will compromise.

Typically I will work between around 8:00 and 5:00, then will do a bit of email/Slack and other catch-up work later in the evening. As a COO of an early-stage but growing startup my job has a lot of variety: I juggle hiring, management, strategy, people & culture, internal communications, planning, operational cadence, analysis, as well as the classic “whatever needs my attention” of startup life. 

Keeping myself from thrashing between all these things and staying focused on the most important tasks can be challenging. I am far from perfect in this regard, but I use three tools to manage my time:

A small Moleskine notebook. Yes, made of paper! I plan the most important tasks to be done at the start of each day and take great satisfaction in crossing them out when they’re done.

Reclaim.ai is a calendar management tool that gives you floating 1:1s, integrates with task managers, protects focus time, and more. It’s the next best thing to having an EA, and I would be lost without it. Full disclosure: I am an investor in Reclaim.ai

A simple Pomodoro Technique timer that forces me to stay focused but then allows me time to recover.

How do you stay motivated and focused when things get tough?

I try to practice “caring a lot, but not too much”. You want to do everything you can to help your startup succeed, but most startups fail and as a founder you live to fight another day. The irony is that if you worry too much about bad things happening to your startup, you will fail to take the smart risks that have the chance to propel you to real success.

It’s important to give yourself a little distance and perspective, to see even tough and challenging situations as a puzzle to be solved, a challenge to be overcome, rather than a threat to your life and wellbeing. Keep your amygdala out of it! 

The Startup Podcast is now into its second season and is continuing to grow. We have had some fantastic episodes on topics like company culture, alignment, and first principles thinking. If you like this newsletter, you will probably also enjoy The Startup Podcast.

Get it now in your favourite listening app!

Why is it so important to invest in culture?

Culture links to identity. Strong culture in an organisation drives mutual loyalty and commitment.

Culture is peer-to-peer. There doesn’t need to be a “boss” watching for people to adhere to the culture.

Culture is self-perpetuating. New members of a group adopt the existing culture.

These things make culture powerful, and just as importantly they make it scalable.

As founders at Circular, we have all experienced a mix of corporate cultures: good, bad, and indifferent. We have seen the massive difference culture can make.

We want to make sure our culture is excellent.

Wallpaper Values

Many organisations proclaim a set of values, ostensibly designed to guide the culture. They rarely work, and are widely mocked because all too often they are “wallpaper values”: they make for a nice poster on a wall, but they don’t actually do anything to influence culture.

At Circular we do not want wallpaper values. Our values are statements of what matters to us as an organisation. Our values take a point of view. And we expect our values to earn their keep: a value is only useful if it makes it easier to make good decisions and stay aligned, and to perpetuate the culture we desire.

Even good organisational values fall flat in practice because on their own, they are not enough. By design, values are broad and can be interpreted in different ways. Values need to be durable and universal, and so they by necessity are abstract and general. As guides for everyday behaviour, they are inadequate.

Virtues to the Rescue

In Ben Horowitz’s excellent book “What You Do Is Who You Are”, it is explained that the Samurai lived by a code of virtues. They venerated actions and conduct in accordance with their virtues above nearly anything else, and this was foundational to their strong and durable culture.

At Circular, we have taken inspiration from the samurai: alongside each of our values, we associate a number of virtues: concrete behaviours that are associated with the value and are manifestations of it. If a value is something you believe, a virtue is something you do because of that belief.

Virtues provide specific guidance about “good” behaviour within a culture and in accordance with its values.

For example, one of our values at Circular is “Seek Unusual Knowledge”. As much as we believe in this value, it is not much use on its own. So we have a number of virtues that go with it. One of these virtues is “Explain Your Reasoning”. In other words, as a Seeker Unusual Knowledge, you must be mindful explain your reasoning. Furthermore, you have a right and a duty to expect others to explain their reasoning too. At Circular, we ask “why”.

In the six or so months since we’ve introduced virtues alongside our values, I can say that they have done much to strengthen our culture. The directness of virtues, the ability to prompt people to behave in a certain specific way, is the missing piece that animates our company values and liberates them from being mere wallpaper.

We have had some phenomenal guests on The Startup Podcast lately.

Last week we had Kyle Poyar, the world’s most eloquent and outspoken advocate of Product Led Growth.

Prior to that we had had Marty Cagan, the public intellectual of product development, author of Inspired and Empowered.

A few weeks earlier we hosted Casey Winters, Chief Product Officer at Eventbrite, and a leading light in the world of Growth: he has held pivotal roles at Pinterest, Grubhub, Canva, Thumbtack and more, and is a Partner at Reforge.

Chris Saad (my partner in crime) and I publish a new episode every week. Whether we host a guest or it’s just the two of us, our aim is always the same: to bring the unique Silicon Valley mindset and knowledge to a broad audience all over the world, with clear and actionable insights. And of course: we explain our reasoning!

I would absolutely love it if you could follow The Startup Podcast (on Apple Podcasts, Spotify, Google Podcasts, or anywhere else good podcasts are found), listen to some episodes, and let me know what you think! It’s become a bit of a passion project, and many of you will enjoy the content… especially if you’re interested in startups.

But there’s something special about reading a book. I think it’s the focus, the prolonged attention to a single theme, that can get under my skin me in a way that shorter form content cannot.

I have been influenced by many books in many different areas, but today I thought I would share the five (plus a bonus two) that have meant the most to me as a People Engineer. Hopefully some of them inspire you in the same way they inspired me!

The Five Dysfunctions of a Team & The Advantage

Patrick Lencioni is one of the best thinkers on organisational health. The Five Dysfunctions of a Team is a parable about the different ways a leadership team can fail, and what to do about it. The Advantage is a kind of companion guide to Five Dysfunctions, giving practical tips on how to create a high-functioning team.

The Five Dysfunctions of a Team on Goodreads.

The Advantage on Goodreads.

No Rules Rules & Powerful

Netflix has one of the most intentionally designed and well-articulated cultures of any large company. Personally, I feel it is one that is worth emulating. Regardless, you will learn a lot about how to think about building an organisational culture and the different types of tradeoffs that the culture embodies.

Powerful was written by Patty McCord, formerly head of People & Culture at Netflix. No Rules Rules was written by Reid Hastings, Founder and CEO of Netflix. They’re both good, and there’s quite a lot of overlap. You’ll do fine reading either.

No Rules Rules on Goodreads.

Powerful on Goodreads.

Working Backwards

While I look up to Netflix on culture, Amazon is the tech company that I admire the most in terms of process and operations. From six-pagers and PRFAQs, to two-pizza teams, single-threaded leaders, and more, Amazon has codified a scalable approach to making decisions about and building products and businesses. Working Backwards is written by two early execs at Amazon and is an enlightening walk through how Amazon does things.

Working Backwards on Goodreads.

What You Do is Who You Are

A book about corporate culture, which for case studies uses that Haitian Slave Revolt, the code of the Samurai, and a prison gang! Entertaining, thought provoking, and genuinely useful. From Ben Horowitz, founder of legendary VC firm Andreesen Horowitz (a16z).

What You Do is Who You Are on Goodreads.

Measure What Matters

The classic book about OKRs by John Doerr. OKRs are a slippery beast, and mastering them is an important part of building a high performance, scalable organisation. This book is a good, accessible guide to what OKRs are, why they can be so powerful, and how to make them not suck

Measure What Matters on Goodreads.

Check it Out: The Startup Podcast

My podcast with Chris Saad continues to publish a new episode each week. To make it easier for you to get into it, here is a selection of episodes that most relate to the topic of People Engineering:

Organisational Design - Hiring your way out of incompetence.

Finding and Hiring Talent - Always Be Closing.

Scale-up Execution Overview - Avoiding Founder Sabotage

The Founder Journey - Building the Thing that Builds the Thing

What Are Your Favourite Books?

Share your favourites in the comments!

Leave a comment

Do you want a weekly masterclass on what it takes to build a high-growth startup, delivered straight into your ears1? Check out The Startup Podcast, a collaboration between myself and Chris Saad.

Readers of People Engineering may particularly enjoy our episode about execution at the scale-up stage.

Follow/subscribe to the podcast right now in your favourite podcast app.

Note: a version of this article first appeared on Earlywork, a community for early-career individuals working in tech and startups. If you’re early in your career, I can strongly recommend joining. The community and the content are top notch.

A scaleup is not just “a big startup”, it’s a fundamentally different beast. 

If a startup is an adorable baby, a scaleup is an awkward teenager. Not as cute, maybe, but filled with wonder and possibility and a newfound strength and sophistication.

Another way that a scaleup is like a teenager is that it is fundamentally defined by the fact that it is going through a period of profound change and transition. 

The most important thing the organisation needs to do is respond effectively to that change.

What changes?

There are two changes that really characterise the transition from a startup to a scaleup.

#1: Entropy

The first of these is really an accumulation of entropy that starts to slow things down. You often hear people talk about technical debt, or organisational debt, or product debt. 

What all of those things mean is that you've been in business long enough, your product has evolved enough, and you have enough customers or users, that things have started getting a bit gnarly and a bit funky. 

The nice clean design, the nice clean architecture, the clean database, the clean pricing; all of these things are no longer so nice or so clean and that's really noticeably starting to slow you down. When you’re used to moving fast and suddenly you find you can’t any more, that can be quite frustrating.

#2: Coordination & Alignment

The other thing that changes is the fundamental limiting factor of the organisation’s ability to succeed. 

At a startup, that limit is basically the number of hours in the day, the amount of raw work you can get done. 

At a scaleup, the limit changes to being about how well you are able to keep all the people in the company aligned and coordinated. 

When there are five people, there's so much to do. 

You don't have much of that entropy so you can really just keep your heads down, do your work.

You don't need to have a lot of meetings, everybody knows what everybody else is doing.

You can hold the whole business in your head. And so it's relatively straightforward, just to know what you need to do and get it done.

But then you reach a stage where you're 30, 50, 80 people, and suddenly everyone just having their head down and doing work isn't producing the same great results. 

And that's because getting 80 people all pointed in the same direction and doing work that is mutually reinforcing is not going to happen by itself. In fact, it’s incredibly hard.

Getting people, many of whom are new, aligned to a clear strategy is not easy. 

Respecting your company's legacy without being bound by it, that’s not easy.

 Not stepping on each other’s toes, that also isn’t easy. 

I hear from founders who say, “I've doubled the size of my team in the last 12 months. And not only are we not twice as productive, we're actually less productive than we were a year ago.” 

With twice as many people! That sounds insane, but it's actually a very common story. And what that means is that the organisation is facing the challenges of being a scaleup, but has not put the pieces in place to keep the team aligned and coordinated. So productivity plummets.

Productivity is not about units of work like lines of code or features delivered. 

Productivity is about the pace of delivery of actual meaningful value that is experienced by the customer and the end user, and ultimately leads to growth in the business in ways that matter.

The implications of these two changes for the leadership of the company are quite profound. During this transition, what happens to the CEO and other senior leaders is that although their job title has stayed the same, their role has radically altered. 

At the startup stage, senior leaders are focused on execution and getting things done, hustling, being directly involved in everything that's happening.

By contrast, the CEO at a scaleup is an organisational leader, an executive. Their job is to set the strategy, communicate it clearly, allocate resources, inspire the team, make sure that people are aligned, make sure that people are motivated. 

It’s a completely different job. 

So one of the most common dysfunctions we see in a company early in its scaleup journey is that its leadership is still operating as though they’re leading a startup, and it’s just not what’s needed anymore.

My company is becoming a scaleup, what does this mean for me?

Employees at emerging scaleups face two key challenges:

#1: Changing Nature of Roles

Even the example of a software engineer who is still a software engineer, the things that they did that used to work well, stop working so well. 

And that's partly because of that entropy increase. The codebase that used to be simple and easy to understand, where you could just make and push changes quickly without any challenge. 

Suddenly, everything takes forever. How can you make yourself productive in such an environment?

#2: Cross-Team Alignment Issues

The second challenge is related to the initial point, which is that your leadership has often not reoriented in their role, and as a result there is a lack of alignment with other teams. 

And so you find that you're working at cross-purposes, there is a lot of conflict, and a lack of momentum and direction.

If you’re at this stage, the first thing to consider is: do I want to stick around? 

Some people prefer the startup environment. If that’s you, then there’s no shame in moving on once things have reached a different stage that no longer matches your skills or inclinations. 

If you are keen on staying on the journey, the most important thing is to welcome change. 

Resistance marks you as a member of the old guard, as somebody who is not willing to evolve with the company. You become an obstacle. So watch, process, learn and figure out how you should change as the organisation does.

The second thing that is important is to become adept at managing up. 

That does not mean “brown nosing”, but rather making it very clear to your leadership what context and guidance you need in order to be able to do your job effectively. 

When everything is changing, people need to articulate their needs or those needs will be neglected. Seek actively to understand the business and its goals, and be proactive in articulating how best you can contribute to them.

I’m thinking of joining a scaleup, what should I look out for?

You’re joining a teenage company, and you want to make sure that it’s on the cusp of a jaw-dropping glow-up rather than sliding into glue-sniffing irrelevance. 

How do you tell the difference?

The biggest thing to look for is organisational self awareness and humility. 

A scaleup is going to be facing a lot of challenges, and the only way to overcome them is with a willingness to face them head-on and be willing to change.

Ultimately the whole organisation needs to do this, but the tone is set at the top.

See if you can get a sense of whether the CEO and other senior leaders understand that their company is going to have to change, and what they’re doing for themselves and the company to change them.

Another thing to look out for: is the company growing super fast? That’s exciting, but be aware that the faster the growth, the greater the likely growing pains. 

Any company that is growing headcount more than 80% or so per annum will have a significant amount of internal chaos. 

Can you thrive in such an environment? Then great, you’re on a rocketship. But on a rocketship, the G forces are high.

Have a look on Glassdoor. Are there a bunch of negative reviews saying “this place isn’t what it used to be”? If so, that’s not necessarily a bad thing! 

Negative reviews might suggest that meaningful change has arrived, and some folks who were more comfortable with the startup culture are not happy about it and moving on. 

However, from reviews alone, it can be hard to tell the difference between a startup that is going through painful but necessary change, and one that is simply getting worse. 

That is why you need to parse these reviews carefully: are people giving examples of genuine dysfunction, or are they simply railing against the change?

If there is no sign that anything has changed, that probably means the company is neglecting the coming storm.

Nonetheless, I remain committed to People Engineering; when I have something worth saying and the time to say it—I shall say it here!

I am a parent, and an observer of parents.

I am a founder, and an observer of founders.

The parallels between a parent’s journey rearing their child, and a founder’s journey growing their company, are simply too strong and too instructive to ignore.

Childhood / Startup

When a company is first founded, it is utterly helpless and dependent on its founder. There is no aspect of the company’s operation that is not subject to the founder’s direct control, no boundaries to the founder’s involvement. The founder is omniscient and omnipotent. Much like a baby freshly born, the identity of a founder and that of their company is deeply intertwined, such that it is difficult to tell where one ends and the other begins.

Being the founder of a startup is a 24/7 job. It is only the founder’s energy and commitment that give the startup life, that propel it forward. For most startup founders, the idea of a vacation is laughable. Even if they do take time off, much like a parent with a child—the company comes with them, and shapes and defines the vacation.

The feeling of being a startup founder is one of being utterly consumed by the company. Although it is exhausting, it is also deeply rewarding and motivating.

Adolescence / Scale-up

Once a company reaches a certain level of scale (typically 30-50 people) it reaches its scale-up phase. Much like a child’s adolescence, this is a period of turmoil and transition. There is too much going on in the company for the founder to be able to meaningfully be able to contribute to all aspects of the business. There are many senior specialists who will not tolerate interference in their area of authority and expertise. The founder needs to learn to give the various individuals and teams within the company space to do things their way.

Although the founder still enmeshes their identity with that of the scale-up company, the sentiment becomes less mutual. The company develops an identity of its own amongst those who work for it that is quite distinct from the identity of the founder. Although the founder looms large within the company, those within it look to them more for guidance and inspiration, for a sense of safety. It is common at this stage for the founder to make unwelcome intrusions into the daily work of the company; employees will perceive this as overreach and micromanagement. Their reaction to such intrusions will be to distance themselves from the founder.

Learning to let go of the “bodily functions” and to take on a new role as a mentor and a guide is one of the toughest challenges a founder faces at the scale-up stage. Failure to meet this challenge will cause a deterioration in the relationship between the company and its founder, to disobedience and resentment; all the hallmarks of a rebellious teenager.

When a founder takes a vacation from their scale-up, they will likely miss the company more than the company misses them.

Adulthood / Mature Company

Having made it through some of the rites of passage that represent adulthood as a company (achieving profitability, going public, having a mature product line, slowing growth), the relationship between the founder and the company becomes one between two non-dependents in a mutually consenting relationship. The founder may no longer be leading the company, but even if they are: they are there as an employee of an entity that is far larger than themselves, that has a life of its own. The founder of a mature company may be important, but they are no longer necessary.

The founder of a mature company is a figurehead, remembered (hopefully with fondness) as the progenitor of a vigorous organisation. However, if they wish to remain involved in the life of the company they must do so on the company’s terms. The fully-mature company makes its own way in the world, dependent on their parents no longer.

Avoiding Dysfunctional Parenting

For both parents and founders, the most common dysfunction I see is this: a mismatch between the role that is being played, and the role that is needed. A parent who gives their teenage child neither freedom nor wise guidance is like a founder who micromanages their scale-up, interfering with daily operations while neglecting to articulate a clear vision or strategy. The parent of adult children who is unable to relate to their children as adults and hence loses the closeness they crave is like a founder of a mature company, ejected unceremoniously as CEO.

In all cases, the way to avoid dysfunction is this: to focus on adapting your role to meet the needs of what is a rapidly changing entity. Too often pride, ego, identity, or simple inattention lead to a founder playing a role that was suitable for yesterday’s company, but no longer meets the needs of the company today.

As a founder, be aware, be present, and always remember to appreciate your company for what it is today.

Tomorrow will be different, and you will never have this exact relationship again.

Meet my other baby! The Startup Podcast is a collaboration between myself and Chris Saad, where we use our extensive operating experience to break down all the different things people working in startups should know. We cover a different topic each week, from hiring to fundraising, ideation to business model selection, execution to managing a market downturn, and more.

We have a five-star rating on both Apple Podcasts and Spotify, and are keen to hear your feedback to keep getting better!

Startups play by different rules than other small businesses. The end goal of a startup is the same as that of any other business: to make a large and growing profit. But the journey there is very different, and during that journey different rules apply. Alex Danco refers to the startup journey as a “controlled bubble”. Learning to play by the right rules is so important.

Your idea doesn’t matter very much. It can be easy to get caught up with the beauty of an idea, but it is dangerous to sanctify it. As Mike Tyson said, “Everyone has a plan until they get punched in the mouth.” Your idea is going to get punched in the mouth a lot.

Execution is where the magic happens, and where it can all go wrong. To a large extent, great organisational execution is what this newsletter is about!

The symbiosis between founders and venture capitalists is what powers the entire ecosystem. I like this definition of symbiosis: “Symbiosis is an intimate, long-term, and specific association between organisms of two or more species.” While it is fun to highlight occasional outpourings of greed and stupidity on either side, and while natural tensions exist, founders and VCs are deeply dependant on one another. It has been delightful to see how truly collaborative the relationship is.

The Startup Podcast

These truths (and more) are the focus of The Startup Podcast, a new project I have begun with Chris Saad. Chris and I have admired each other’s work from a distance for a while, and decided to collaborate on this podcast to share what we’ve learned from our collective experiences in Silicon Valley and Australia. Our dream is to teach people how to approach building truly ambitious, world-changing startups like it’s done in Silicon Valley.

We are five episodes in and showing no signs of slowing down! If startups are at all something that interests you, I encourage you to give it a listen. I believe we’re creating something special.

Ownership is a state of mind. It is a fire in your belly. Ownership drives a laser focus on delivering valuable outcomes for the business. Autonomy and accountability both factor into this. Set lofty goals, work hard to come up with an optimised plan, demand the autonomy and resources needed to achieve those goals. Advocacy to leadership is a key part of having ownership.

Things that individuals and teams with a true sense of ownership have:

A sense of urgency. All your work counts for nothing until it is delivering value. Therefore, a true sense of ownership also drives a sense of urgency. Teams with a sense of ownership can’t wait to start delivering value to their users and their business. This impatience should drive a ruthless desire for efficiency within the team, a bias towards delivery, and a hunger for learning. However, a sense of urgency does not and should not mean burning oneself out, nor does it mean taking damaging shortcuts.

High expectations of each other. Your team’s success is your success, and your team cannot succeed unless all functions are doing their jobs well. Therefore having low expectations of others is equivalent to having low expectations of yourself.

“Good” pressure. Bad pressure comes from outside the team. Bad pressure causes stress and fatigue. Bad pressure is a crushing force and makes a team smaller. Good pressure comes from inside a team, and makes it bigger. It creates energy and motivation, a sense of agency. Think of a balloon, or a tyre. Pressure from within is what allows them to take shape and perform their job. Without pressure they are flaccid and useless. A sense of ownership generates good pressure.

An inclination to escalate. Teams that are driven to deliver value do not tolerate obstacles that stand in the way of doing so. Those that they can remove themselves, they remove themselves. Other obstacles are escalated to their leaders for swift resolution. Obstacles come in many forms: under-resourcing, lack of clarity, missing context, inability to reach a decision, and more. Teams that own see it as their duty to bring those obstacles to the attention of those who can remove them. They understand that otherwise they are not doing their jobs.

Justified conviction in their course of action. A team with a sense of ownership knows the best plan to achieve valuable outcomes in their domain. They know this because they are the world experts in their area of the product, and have the data to justify their beliefs and convictions. Because of this, they are not diverted easily. They are open to feedback and questions from company leaders, but more often than not they defend their position because they know more and have thought more about their domain that their leaders have, or ever will.

Before you go:

If you like my work, here is how you can support its ongoing creation:

🗣️ Share this article with others who may enjoy it.

Share

📃 Subscribe to this newsletter, if you haven't yet.

Subscribe now

♥️ Like this article if you, well, like it.

🎧 Listen and subscribe to The Startup Podcast, a collaboration between me and Chris Saad.

Listen now

Basically:  “1. Move fast; 2. Break things”.

But no. That’s actually not what it means. Implied in the motto is an understanding that there is necessarily a tradeoff between velocity and risk/reliability. Facebook’s motto is taking a position on that tradeoff:  “Move fast, therefore be ok with breaking things” or (even more accurately) “Prioritise moving fast over not breaking things”. Somehow not quite as catchy…

One problem with the Facebook formulation is that it doesn’t specify quite how broken it is OK for things to be. It is not the case at Facebook (and never was) that it was OK for the service to be constantly egregiously broken. Indeed, Facebook has always been a reasonably well-built and stable product.

So how do we decide how broken is too broken?

The Error Budget

For that, we turn to a concept from Site Reliability Engineering.

The excellent “SRE Book” from Google introduces the concept of error budgets for software services. The error budget of a service is simply the quantity of errors that is agreed to be acceptable. The error budget is intrinsically linked to a service’s SLO, but framing it in terms of a budget speaks directly to the tension between moving fast and breaking things:

Product development performance is largely evaluated on product velocity, which creates an incentive to push new code as quickly as possible. Meanwhile, SRE performance is (unsurprisingly) evaluated based upon reliability of a service, which implies an incentive to push back against a high rate of change.

In other words, there is a direct tradeoff between how fast a software product changes, and how reliable that product is from a technical operations perspective. Error budgets are designed to allow that tradeoff to be formalised and negotiated:

The error budget provides a clear, objective metric that determines how unreliable the service is allowed to be within a single quarter. This metric removes the politics from negotiations between the SREs and the product developers when deciding how much risk to allow.

Basically, the error budget is a formal allowance for how often things are allowed to go wrong. If you exceed that budget, you’ve screwed up (and you need to slow down).

Note that it is the intention of an error budget that it be fully (or nearly fully) spent. If a service is coming in month after month well below its error budget, the implication is that the product velocity could be higher, to the benefit of users and the business. In other words, you should be moving faster.

The Fuckup Budget

“This is how much you are allowed to break things.”

I love the concept of error budgeting, and feel that it has applicability well beyond the operational metrics.

On the surface, it feels good for everything to be going smoothly. But is it actually a good thing? In many cases, it means that you have moved more slowly than you could have.

For any organisation, at any stage, there is value in being intentional about how much breakage is ok in service of making progress: in other words, a “Fuckup Budget”.

How many customers is it ok to let down? What defect rate is tolerable? How many bugs is too many? What percentage of bad hires can you efficiently deal with?

If you are like most people, there is a temptation to answer “None. Zero. None. Zero.” But pursuit of perfection leads to extreme caution and ultimately to stasis. So stop, and think about what actual amount of fuckups is OK in the context of what you’re trying to achieve. Set that number, write it down. And then try to reach that number! Remember, if you’re not spending your Fuckup Budget then you could be moving faster.

Happy moving fast! And don’t sweat the breaks.

Exciting news! I have started a podcast, all about startups, technology, and disruption. Check it out, then subscribe on Spotify, Apple Podcasts, or Google Podcasts. Reviews and ratings don’t hurt either!

Enjoy. Also, please follow me on Twitter.

1. You have a job to do, but ultimately it’s more of a personal relationship than a working one.

2. You will get to know each other VERY well. Including the bits the other one doesn’t want to know about you.

3. Your capacity to hurt each other is great, and increases with time.

4. You may divide up responsibilities, but everything one of you does profoundly affects the other.

5. You need to care about each other enough to get through the tough times.

6. If the two of you are not on the same page, the “kids” (employees) are the ones who really suffer.

7. It is easy to accidentally undermine each other. When you let that happen, the “kids” will play you like a pair of fiddles.

8. Communication, vulnerability, trust, and forgiveness are the bedrock of the relationship.

9. When it’s not working, it WILL affect your sleep.

10. When it IS working, it’s one of the most rewarding relationships in your life.

Until July 2021, I was COO at Airtasker.

I have spent the past 4–5 months since I left exploring. I have consulted, coached, written, and spent time getting to know people. It has been a wonderful and educational experience. And now, I have decided on my next act: I am joining an early-stage startup called Circular as co-founder and COO.

Circular is a startup that is bringing sustainable subscription e-commerce to the Asia-Pacific region. Our vision is to accelerate the transition to the “circular economy”: the current model of consumption and disposal is unsustainable and wasteful. We believe we can make subscription the best way to experience technology products, and that on the way we can radically extend the useful lives of devices and reduce e-waste.

The vision and purpose of Circular is certainly one reason I joined the company. But it’s not the only one. In fact, if a great purpose and vision were all it took to get me to join an early-stage startup, I would have joined one long ago.

The Startup Thing

There are many people working in our industry with a profound drive to be founders, to be entrepreneurs. Everything they do in their career is done with a clear purpose: to bring them closer to that point where they can be a successful founder, to build a globe-spanning business from the ground up.

I am not one of those people.

I have been an employee for a vast majority of my working life, and (when I stopped to think about it at all) I was happy to stay on that path. I didn’t think I had the fire in my belly to be amongst a group of people to build something from nothing.

Great founders are visionaries. A visionary is somebody with a clear and specific vision about a future they would like to bring about, and the passion and conviction to work very hard to make that vision a reality. They know where they want to go. They will endure hardship to get there. That’s at the core of being a founder.

It turns out, I am a visionary after all. I do have the fire in my belly; I was just looking in the wrong place.

I’m not a product visionary, or a market visionary. But I do have a vision: it is an organisational vision. I have a clear and specific view of the type of organisational culture and structure that I believe is most conducive to excellent performance, commercial success, and human dignity and happiness. And I will endure hardship to get there; I know this because I have not only endured it in the past but sought it out at previous organisations. At work, nothing is more important to me than making this vision a reality.

Looking back, the evidence has been hiding in plain sight, if only I’d looked for it. It was there in my actions as VP Engineering at Airtasker, and then in my transition to Chief Operating Officer. It was of course there in the fact that I write a newsletter all about organisational and leadership principles, and in my desire to coach and consult on how teams work.

When I met Nick at Circular, and started to get to know him, I realised that he was somebody I wanted to work with. He has a compelling and inspiring vision for Circular as a product and a positive agent of change, and he also has a set of organisational principles and values that mirror my own. The more we talked, the more it seemed like we could partner to build something extraordinary: a fast-growing business that serves the needs of the on-demand subscription economy, while at the same time reducing our burden on the planet. All fuelled by a singular organisational culture that prioritises excellence in execution.

While it is not quite Day Zero at Circular (Nick and the team have laid some incredible groundwork) I am excited and nervous to be joining as Co-Founder and COO. This is the place, amongst these people and this mission, that I hope to be able to fully realise my vision.

My Organisational Vision

A vision need not be original to be powerful, and mine is strongly influenced by many other great leaders and organisations. I am particularly inspired by the cultures and practices of Netflix and Amazon as articulated by their leaders, and by many aspects of Google’s culture as I experienced it in my ten years working there.

Circular is an early stage company, and we are going through a collective exercise to design our culture and values. I don’t want to preempt that. However, there are a few principles that are core to my organisational vision that I would like to share.

I begin with the principles of individual empowerment and collective responsibility. Individual empowerment means that we hand a lot of trust to every individual who works in the organisation. So many organisations don’t do this, despite charging their employees with critical roles. I believe that by treating people like adults, they are likely to act like adults. At the same time, no individual (however empowered) can achieve much without deep collaboration with their peers in the organisation. Therefore, true responsibility must rest with a team of collaborators rather than with any individual. Individual stats matter much less than what’s on the scoreboard. And the success and performance of our team is ultimately how we measure ourselves.

I am also a very strong believer in focusing on outcomes. As an organisation, what we do is less important than what we achieve. When we set goals, we focus on what problems we are trying to solve for our customers, and retain the flexibility to change the execution plan in service of solving those problems. There are a number of principles that flow from a focus on outcomes: strategy centricity, radical transparency, intelligent measurement, and a focus on learning.

To elaborate on the final one of these: it is a principle of mine that extraordinary organisations are optimised for learning. By that, I mean that their culture, processes, and incentives, value applied learning above all else. A startup is about taking a hypothesis about the world, then validating and exploiting it to build a large and defensible business. To do this, the hypothesis must be repeatedly tested and refined. Many mistakes will be made. Much new knowledge will come to light. Therefore, learning, the gaining of robust knowledge about our business and about ourselves, must be valued above nearly everything else. A culture that prioritises knowledge values data, debate, creativity, experimentation, record-keeping. A place where new things are tried and then refined (and sometimes discarded). Above all, a culture permits (and even celebrates) failure and mistakes as essential ingredients for learning and growth.

Underpinning all of this is the need to create an environment of trust and vulnerability. Many workplaces talk about encouraging people to “bring their whole selves to work”, but they often fall short. To me, bringing your whole self to work means much more than feeling safe in your identity. It means being OK with being your true self, not the “best version” of yourself — no matter your identity. It means feeling comfortable sharing your anxieties, your moods, your failures, your weaknesses, your flaws. Without this, there is not a real team, just a group of “LinkedIn Personas”. Greatness cannot be achieved without embracing our own humanity, and that of those around us.

The Circular Opportunity

With COP26 having recently taken place, a consensus has been built that for the sake of humanity, our global economy has to be completely retooled. To do so is the labour of multitudes. The part we have chosen to play is to accelerate the adoption of the circular economy, to turn consumers into custodians, to create a world where there is less waste.

Given that reducing waste is core to our mission, here’s one thing I am determined we will not waste: our opportunity. To grasp it will not be easy: it will require uncomfortable growth and sacrifice, difficult decisions, constant change, dealing with uncertainty and instability. There will no doubt be crises along the way. But I believe that with the group of people we have, with a determination to work together and keep ourselves accountable to the greater goal, we will succeed beyond any reasonable expectations.

I began my career at Google. My first few years there were fairly successful and after 3 or 4 years on the job I thought I knew most of what there was to know about being a software engineer. 

Around this time, Google released a new model for assessing performance for their engineering team, and it was very simple. The only three criteria on which we would be judged were:

1.  The technical difficulty of the work we were doing. 

2. Our leadership skills.

3. The impact that our work had: on the world, on our users, on our business, and on our colleagues.

I was outraged by the third one. 

How is it fair to assess my performance as an engineer on factors that were beyond my control?

It wasn't my job to decide what to build.

It wasn't my job to decide how to go to market.

That was a product manager's job, the marketers job.

My job was to take what they said to build and to build it well. That was what I should be assessed on. 

In fact, I was so outraged that I wrote an internal blog post entitled “Impact Considered Harmful” in which I talked about why this change was so unfair and unreasonable.

In fact, I even had an illustration of a giant asteroid hitting the earth to demonstrate quite how harmful impact could be! I thought I was pretty clever, and that my argument was pretty solid.

But then I cooled down, got to talking with a senior colleague of mine, and he flipped things around for me. I was looking at it all wrong. This wasn't an unfair and capricious judgment based on things that were beyond my control. No. In fact, it was an invitation. More than an invitation: it was a demand.

It was a demand that as an engineer we care about more than just building good software, because software should never be an end in itself. We were being told directly, you are going to be evaluated based on the actual impact of the work you do because ultimately, that is what really matters. 

And the beautiful thing about it is that by making impact a part of our official assessment criteria, it became part of our job description. 🤯

That was actually incredibly empowering. Once I took on board that it was my job as an engineer to actually deliver impact, provide value, then I became a lot more engaged with my cross-functional partners.

I no longer saw it just as my job to do what my product manager told me or what my marketer told me. Instead, I understood that it was my job to partner with them, to respectfully challenge them, and to work together to deliver that impact, which I would ultimately be judged on.

I asked a lot of questions. I challenged assumptions. I insisted on understanding our underlying motivations. I suggested alternative ways of doing things. 

A lot of what I spent my time thinking about would not have been considered software engineering at all by conventional standards. At all times, my eyes were fixed on the horizon of delivering impact. Everything I did was focused on maximum impact for minimum effort.

At first, I was worried that my new empowered attitude to my job would mark me as a troublemaker. And I'm sure some people did feel that way! 

But overwhelmingly, my increased engagement and attention to the big picture that resulted from my focus on driving impact was well received.

For most people, it made me a more valuable and collaborative peer and colleague. Increasingly, people wanted to work with me because my perspective on my job led to better outcomes for the work of the entire team.

Maintaining a laser focus on impact changed things profoundly for me as a professional. It is something that has driven my career for more than 15 years, and continues to do.

Everything I do, I judge by its ability to create impact.

I come from an engineering background and this story is about engineering. But the lessons to be learned apply far more broadly than just engineering. 

Zoom out enough, and every job at every business is about delivering impact.

As an early career professional, you can rapidly increase your value to your employer by orienting yourself and defining your role in that way. 

No matter your role, the behaviours it drives - collaboration, intense curiosity, respectful conflict, and a sense of urgency - serve to simultaneously increase your current value and accelerate your growth.

When I first went from Google to a fairly early-stage startup, it was quite a culture shock. Everything was different to what I was used to. In particular, it was a lot more chaotic than I had expected, and it made me nervous. I tried to put my preconceptions aside, and figure out what was really happening. Eventually, I felt comfortable enough to share my early observations about the software development process at the company. One of the slides had this diagram:

What I had seen was that every company is on a journey, and for every step on that journey there is a "right" amount of process to have in place. Good processes (e.g. documenting what you do, or having approval checklists for product launches) allow your organisation to operate at a larger scale, build higher-quality and more complex systems, reduce risk, and increase predictability. Well-considered and well-implemented processes support teams and individuals in doing their jobs. However, processes come at a cost in terms of raw productivity and throughput, and in the early stages of a startup many of them are too expensive to implement or are simply unnecessary.

When you're two ramen-fuelled developers in a basement, the right amount of process is "not much". When you're a globe-straddling mega-corporation, the right amount of process is "quite a lot". And of course, when you're starting out then "not much" is a natural default.

If you're growing, then, generally the actual amount of process you have in place is going to trail the amount of process you need. I suspect the diagram above describes a large majority of successfully-growing startups. This "process lag" generally manifests in a certain degree of chaos, communication breakdowns, and dropped balls. This is often characterised as "growing pains".

If you're in a role that is responsible for scaling and growing an organisation, what this means is that you're in the business of adding and refining process. Ideally, you get the red ball in the diagram to catch up with the green ball, and then to keep up with it as your organisation goes on its journey. Knowing about good processes is something most experienced managers should not have too much trouble with. The art of it, and one that I look forward to learning, is how to roll them out at just the right pace that they are always supportive, never stifling.

You own a goose that lays golden eggs. (Congratulations)

Every year, the eggs laid by that goose can be sold for a total of $1 million.

That goose is giving you a very good life, but you’re worried. What if the goose is kidnapped? Or gets sick? Or simply flies away? What if golden eggs become less valuable? Or they break while they’re being shipped?

Luckily there’s insurance and other risk management tools. For a price, you can get peace of mind against one of those things going wrong. So you start taking out policies. You buy accidental death insurance, veterinary insurance, transit insurance. You pay for a security detail, a private dietitian, an animal psychologist. You take out futures contracts on gold for hedging. The local mob is only too happy to provide protection in return for fair consideration.

Your goose is safe, and you feel safe. Of course, all that safety costs money. By the time you’ve paid out all your expenses, only $100,000 of that annual million dollars remains.

You’re also so focused on protecting that golden revenue stream that it doesn’t occur to you that some of those golden eggs might hatch into more magic geese, if only you let them.

In the meantime, the years pass. Your goose grows old. Despite every effort, it finally dies. And you realise that in your caution, your aversion to risk, you have made many people wealthy… but not yourself.

Expected value maximisation

One way of making decisions is by using “expected value maximisation”. The expected value of an event is the payoff of an event, multiplied by the probability of that event occurring. The expected value of a decision is the sum of the expected value of all possible events.

For example, if I make a decision that has an 80% chance of yielding $10 and a 20% chance of yielding $100, the expected value is $8 + $20, or $28. Note that it’s not actually possible for the decision to yield $28. Rather, if I were able to take that chance over and over again, $28 is the average amount I would make.

Under expected value maximisation, I would make whichever decision had the largest expected value. This has a certain sound logic: if we were living in a simulation1 and had the opportunity to run the same decision over and over again, then the decision with the highest expected value would have the best outcome on average.

Managing risk

Maximising expected value is not necessarily the best strategy for every situation. For example, if I were personally offered a bet where I staked everything I owned for a 1-in-100 chance of winning $10 billion, I’m not sure it would be wise to take the bet. Sure, the expected value is outstanding, but in the vast majority of possible outcomes I end up with nothing to my name. I only have one life to live, and relatively modest needs. Hedging my financial bets makes sense. I want to protect myself from extreme downside events (like losing everything).

If this weren’t the case, there would be no insurance industry at all. The expected value of a dollar spent on insurance is always less than a dollar (otherwise the industry would be unprofitable). What insurance does is reduce the variance in outcomes: you’re less likely to do extremely poorly, but you’re also less likely to do extremely well.

Similarly, many safety measures have a poor expected value but still make sense to people. When my wife was pregnant, we invested $1000 in tests for genetic conditions that we had a less than 1-in-5000 chance of passing on to our child. Using expected value maximisation, the genetic condition would have to have had an equivalent cost of at least $5 million for this to make raw financial sense. But of course, it was worth it to protect ourselves from the unlikely but extreme negative return.

When to manage risk

It is well known that rental car agencies make most of their profit by selling additional insurance policies, for example to reduce the excess or insure against cracked windshields. These policies are terrible deals. You pay a guaranteed $300 to reduce the excess on a one week rental, to guard against a small chance of having to pay out an extra $2000 if you do serious damage to the vehicle.

The only time it would be rational to buy this crappy insurance is if you could afford to pay $300, but would be ruined financially if required to pay a $2000 excess. Insurance and safety measures with negative expected value are only worth doing if the cost of a possible negative outcome is too extreme to contemplate.

Reducing blast radius

Much of risk management (at least as I have experienced it) tends to focus on reducing the chance of a thing going wrong rather than on reducing the cost of it going wrong. This is a shame, because often it less expensive to reduce the damage caused by failure rather than to prevent it from happening or to insure against the resulting damage.

In software engineering, many of the best operational practices are about reducing blast radius. Rather than gumming up the works with elaborate quality assurance processes, modern tooling emphasizes frequent releases, canarying, comprehensive monitoring, and easy rollbacks. Each of these are about reducing the cost of error rather than reducing their occurrence.

Another example in the legal sphere would be to have a policy of aggressive early settlement with unhappy customers whenever there is a risk of litigation. So rather than implementing complex and costly processes to avoid the possibility of being sued, work to reduce the likely size of the payout.

The Black Swan

By definition risk management focuses on risks that are predictable. In The Black Swan as well as the rest of his Incerto Series, Nassim Nicholas Taleb argues convincingly that humans and organisations systematically underestimate the chance of catastrophic, unpredictable tail events.

What is a Black Swan event? It’s when you flip a coin, you miscue, and it hits you at just the right angle as to cut through your jugular vein. Or when you flip a coin, it rolls under a floor board and in retrieving it, you find a priceless treasure. In any real-world scenario, your list of possible outcomes will never be exhaustive, and the probabilities you capture will never add up to 100%.

By definition, traditional risk management techniques cannot mitigate against Black Swan events. Even worse, such techniques usually elevate the risk of a Black Swan event doing massive harm to the organisation. In other words, it increases the organisation’s fragility.

When an organisation attempts to manage risks through prevention, the main cost will be the slowing and ossification of the organisation. Processes and best practices will reduce initiative and dull responsiveness. The cost to the organisation therefore comes from reduced productivity, decreased innovation, and lack of agility. When the unexpected happens, such an organisation is poorly positioned to respond.

Tying it together

Bringing the above discussion together, I believe the following is a good general approach to thinking about risk:

1. Expected value maximisation is a good place to start, but it is important to be aware of the risk of extreme negative outcomes.

2. Don’t take out insurance except when the cost of an extreme negative outcome would be catastrophic.

3. Minimise taking preventative measures, except where the expected value of the measure is clearly positive or the cost of an extreme negative outcome would be catastrophic.

4. Favour reducing blast radius over putting preventative measures in place. I.e. reduce the magnitude of a possible negative outcome rather than trying to stop it from happening.

5. Be anti-fragile. Remember that slow-moving organisations tend to be destroyed by Black Swans, whereas agile ones often benefit from them.

Startups and risk

In addition to the above, I would like to add the following note when it comes to startups in particular. To avoid confusion, when I talk about a startup business, I am referring to a technology (or similar) business that takes on multiple rounds of external venture capital.

When compared to a private individual or other type of organisation, a startup should lean quite a bit more heavily in the direction of expected value maximisation. Why? A startup is a bet on an extreme positive outcome. It’s a bet on a certain hypothesis or view of reality that, if true, will deliver stunningly good returns. If the bet doesn’t pay off, well, you may as well learn that sooner rather than later. Delaying failure is the worst thing you could do. Venture investors are not interested in a modest return; they are interested in an extreme return, and are very comfortable losing their entire investment in pursuit of that.

As somebody working at a startup, your incentives are more aligned with investors than you might think. A career in startups is forged through rapid learning, often through failure. But whatever you learn from a given startup, you should learn it quickly.

Overemphasizing risk management and diversification might reduce the chance that you go to zero (at least, in the short term). But it does so at the expense of massively reducing the likelihood that you will go to the moon. If you’re a startup, this is a bad tradeoff.

What’s the lesson here? Certainly it is not to be foolhardy or cavalier. Instead, the lesson is about focus: instead of diverting resources and attention on cushioning potential failure, put everything you have into maximising the chance of success.

Still here?

Like this post, or share it with a colleague. I promise the expected value of both actions is positive!

Share

There’s an old idiom, “every cloud has a silver lining”. And a newer one: “never waste a crisis”. Both teach the same lesson: that in failure, in destruction, in upheaval, lies opportunity. Opportunity to learn. Opportunity to rebuild differently, and better. Opportunity to move into spaces created (or vacated) as a result of the upheaval.

We’re pretty good at taking solace of the good that can come from misfortune, the strength that springs from weakness.

But what about the opposite?

The Legend of Icarus

In the old Greek legend, Icarus attempts to escape Crete by crossing the ocean on feathered wings, attached to his arms by wax. He is warned by his father: he must not fly too close to the sea, or the spray will weigh down the feathers and he will plunge to his death. But also: he must not fly too high or the sun will melt the wax, the feathers will come loose, and he will plunge to his death.

Flying feels pretty good. After a while, Icarus feels his confidence rise: he’s flying! And he’s going to make it! He soars through the air.

The sun does its work.

And he plunges to his death.

Beware Your Strength

The Ancient Greeks called it hubris: the overconfidence, the complacency, the dependency that comes with strength, and with success.

You should celebrate your success, and take advantage of your strength. But at the same time, treat your good fortune with caution and with suspicion lest it turn to hubris.

Every silver lining has its cloud.

Let’s get concrete. Below, I’ve detailed a few types of hubris that are particularly common in early and mid-stage organisations:

Dutch Disease

From Wikipedia:

“In economics, the Dutch disease is the apparent causal relationship between the increase in the economic development of a specific sector (for example natural resources) and a decline in other sectors (like the manufacturing sector or agriculture).”

Basically, if you’re too good at one thing (let’s say marketing) it will outcompete alternative uses of resources and effectively suck all the oxygen out of the room. Other functions (e.g. product) will atrophy and become weak and hollowed out. Later on, when you need them… they won’t be there.

Single Point of Failure

This is common when the organisation is blessed with a person (especially a founder) who possesses great strength in a given area (for example, business development). Because they are so good at that thing, their organisation will underinvest in building a scalable capability in that area. Then, when for whatever reason that person is no longer available to perform their function at the necessary scale (too busy raising capital, moved on from the organisation, simply too much work to do) there is nobody else who can pick up the slack.

This can also happen in technical areas if there is a very strong engineer who hoards all the architectural decision-making.

Easy Money

It’s pretty easy to raise money at the moment. And of course, having a lot of money in the bank can be a great source of strength. But it’s also an easy hand to mis-play, and a lot of damage can be done by having too much money. Here are a few examples:

• Thinking that the raise is the goal rather than simply a funding source, and so underinvesting in sustainable growth.

• Going on a mad hiring rush and lowering standards, eroding culture, adding bureaucracy and organisational debt.

• Cultivating a dependency on paid customer acquisition with poor unit economics, which can’t be unwound without cratering growth metrics.

Resting on Your Laurels

A good product innovation will drive compounding growth for multiple years. As you watch those numbers march up and to the right with seemingly little effort on your part, it can be easy to think that it will continue forever. But remember: every exponential growth curve is just an incomplete S-curve. If you aren’t using the good times to build that next killer feature, growth will start slowing down and it will be too late to do anything about it.

Make Yaniv Happy!

You’ve made it this far, which probably means you found this article useful. If you have, please help me turn this frown upside down by showing People Engineering some love:

By liking this post, joining the conversation, sharing it with your colleagues, and subscribing to the newsletter!

¡Gracias!

-Yaniv

Don’t care about the nuts and bolts of hiring engineers? You can probably skip this one. But don’t unsubscribe! I’ll be back next week with more of the generally-applicable People Engineering content you know and (hopefully) love.

This is Part 3 of my series on hiring in tech, in which I present the high-level outline of the hiring process that I recommend for software engineering hires. Although you can read this article on its own, I strongly recommend reading Parts 1 and 2 first as they provide valuable context.

In Part 1 I provided a few general tips for how to think about, design, and conduct an interview process for tech roles more generally.

In Part 2 I discussed four hot-button issues and controversies in the software engineering hiring process.

My Suggested Process

Without further ado, my suggested hiring process! Note that I am assuming that you are following the general best practices highlighted in Part 1, such as writing a proper job description and interviewer assessment rubrics.

Pragmatic coding skills

This is the one part of the hiring process where you attempt to observe the engineer interacting with a codebase in a way that resembles what they may do in their job day to day.

In my experience, there are two reasonable ways to assess pragmatic coding skills:

1. The mock code review. This is not a very well known assessment technique, but I think it’s brilliant and we adopted it to good effect at Airtasker. Code review is an executive / meta function of coding. It is impossible to be a good code reviewer without being a good coder, so this is a great test. It is also very time efficient and ideally suited to being a take-home style challenge in cases where a screener is necessary.

2. Pair programming. If you really want to see the candidate actually write real code in a real text editor, some sort of pair programming exercise is the best choice. Asking them to write something from scratch is inefficient and not a good gauge, so you will want to ask the candidate to add a feature to / refactor some existing code.

A drawback that is shared by both these options is that they require a reasonable amount of preparation on the part of the hiring organisation: you need to have a suitable codebase for the candidate to work from, and in the case of the code review exercise, the PR to review as well. Them’s the breaks. If you aren’t able to do the work, I would actually recommend skipping this phase of the process rather than wasting the candidate’s time by making them build something from scratch.

Algorithmic skills

I covered this in Part 2. Ideally this is conducted as a whiteboard-based exercise or remote equivalent. Start by presenting a problem (e.g. “keep track of the five largest numbers in an unordered list”) and have them discuss, think out loud, sketch ideas on the whiteboard. This should feel conversational. Feel free to interject with questions and prompts. The idea here is that the candidate should figure out an algorithmic solution to the problem before they start writing code, as this is generally easier and less error prone. Generally I encourage interviewers to allow the candidate to get to a more-or-less working solution, even if it is far from optimal. Let the candidate know this. Once they have something that works, that is the time to challenge it from the point of view of efficiency, edge-cases, etc.

Some candidates want to jump straight to coding. You should strongly discourage, but not prohibit, doing so. A small minority of people really do think best in code. If after you caution them that it may not be advisable they still want to jump straight in, let them.

The coding component can be done in an editor, or handwritten on the whiteboard. Whiteboard coding has gotten a bad rap in the past five years, in my opinion unfairly, as many critiques misunderstand the purpose of the exercise. What you are looking for here is an ability to express the algorithm as code. As such, what you are looking for is clarity of thought and expression. This code shouldn’t need to compile; boilerplate is unnecessary; personally I don’t even care if there are syntax errors or misremembered library function names. Fixing syntax errors is trivial; clear expression of algorithms as code is not. Make sure you’re looking for the right things.

Architectural system design

An architectural system design interview is, like the algorithmic interview, a whiteboarding exercise. The main difference is that it takes place at a much higher level of abstraction. The questions should be designed to be open ended; the candidate’s ability to navigate an ambiguous and underspecified space is part of what is being tested here.

Typical architectural system design questions include:

• Design a backend for a Twitter-like service

• Design a service that aggregates news from multiple sources

• Design a system that creates SEO pages for a local listings site

The aim of this interview is to determine how well the candidate can navigate an ambiguous space, set down their assumptions, make conscious and well-considered tradeoffs, identify risks and challenges, and break down a large problem into smaller components. There should be no expectation that the candidate make highly specific infrastructure choices or go into detail about the architecture.

As an example, for the Twitter question above, you will look for the candidate to ideally cover the following:

• State their assumptions around volume of usage and traffic.

• Consider the API primitives.

• Discuss the shape of the follower graph and its infrastructural implications.

• Identify the challenges of “celebrity” accounts on the system architecture.

• Suggest a very high-level database schema that takes account of the above.

• Talk about the data layer: SQL vs. noSQL tradeoffs, sharding, caching etc.

The output of the interview is often a high-level “boxes and arrows” architecture diagram, but this really is a case of the journey being more important than the destination. As an interviewer, it is important to take thorough notes and to guide the interview to explore the candidate’s skills. This should really feel like a collaboration: two peers standing at a whiteboard, nutting out a problem.

A couple of notes on architectural system design interviews:

1. Traditional system design questions tend to have a backend bias. Where the candidate is more experienced in client software, you may wish to come up with a specific set of system design questions that relate to frontend matters.

2. System design skills become more important the more senior a candidate is. Some organisations don’t subject junior candidates to an architectural system design interview; I prefer to include it, but to make sure that the hiring decision-making process weights the importance of the interview appropriately relative to seniority.

Intermission

Are you finding this article useful? Please feed the algorithm (and give me useful feedback) by hitting the like button below.

I’ll wait.

Behavioural interview

Structured behavioural interviews are a type of interview where the interviewers follow a script of pre-determined questions (that’s the structured bit), generally about how the candidate has acted or would act in certain situations (that’s the behavioural bit). Structured behavioural interviews tend not to flow as well or feel as comfortable as some of the more interactive interview formats, but there is decent research to suggest that they are more predictive of job performance than many other types of interviews.

For engineering hiring, a structured behavioural interview can be used to assess or supplement the assessment of so-called “soft” skills and attributes such as communication, leadership, teamwork, and values. Do not neglect these skills and attributes: not only is there nothing soft about them, but I would argue that they are just as important (and in some ways more so) as pure technical skills in enabling a software engineer to succeed as part of a team and an organisation.

Meeting with a senior leader

All but the most junior candidates should have time with a senior leader in the engineering organisation, at the Director or VP level (or equivalent). This is a semi-informal interview in a behavioural style, but is actually more important to function as a sell and a close. It’s a candidate’s market, and this is an important part of getting the candidate bought in and excited about your company: its mission, its potential, and its organisational structure.

Getting to a Decision

I covered this in Part 1: I believe it is important that each interviewer is provided with a specific assessment rubric, and that they provide written feedback prior to discussing the candidate with anybody else, and that there is a decision-making body (which may or may not include the interviewers) whose job it is to make an overall determination about whether to proceed with an offer. This is, in many ways, the most important part of the whole process. It doesn’t matter how good your interviewing process is if the final decision making process is ad hoc and biased.

Good Luck!

It’s a hot market out there, and good engineers are in short supply. Saying “no” to someone is hard, but it’s an important part of making your organisation great. A fair but rigorous hiring process will enhance your brand in the market amongst the people who count: good engineers who want to work with other good engineers, in a place where engineering is valued.

Share

This is Part 2 of my series on hiring in tech, in which I discuss some hot-button issues and controversies in the software engineering hiring process specifically. Don’t care about hiring software engineers? You can probably skip this one.

In Part 1 I provided a few general tips for how to think about, design, and conduct an interview process for tech roles more generally. Although you can read this article on its own, I strongly recommend reading Part 1 first as it provides valuable context.

The Great Algorithms Debate

Let’s get this one out of the way.

Algorithm-based engineering interviews have been made famous by employers like Google and Facebook. Whether to emulate that tends to be an emotive topic.

On the one hand, we have a view that can be summarised as follows:

It is ridiculous to test somebody on their ability to do red-black tree insertion when their day job mostly involves building React components.

On the other hand there is the following view:

Algorithms and data structures are foundational to good software development and testing these abilities is predictive of whether somebody is a good programmer.

I lean towards the latter position: that algorithmic thinking is fundamental to a software engineer’s craft. Furthermore, anecdotally I have reason to believe that solid algorithmic skills correlate quite strongly with a person’s overall skills as a software engineer. Therefore, I am in favour of having one interview that is focused on algorithmic skills.

However, that doesn’t mean that it makes sense to expect your candidate to battle their way through a bunch of esoteric tree manipulation or advanced sorting or dynamic programming or whatever. When I ask algorithmic questions, I tend towards the easier end of the spectrum. But I do then expect the candidate to be able to reason in a clear way about the problem and produce credible code implementing their solution.

Here’s what a good candidate should be able to do with an algorithmic problem:

1. Understand what is being asked of them, and be able to ask clarifying questions.

2. Explicitly state any assumptions they are making.

3. Express their thinking out loud.

4. Converge towards and explain a working algorithm.

5. Consider edge cases.

6. Have a basic understanding of efficiency/algorithmic complexity. Big-O notation is nice to have, but what we’re looking for here is that they understand the difference between something scalable and unscalable.

7. Express their algorithm as clean, clear code. It doesn’t need to compile, but it has to be more than pseudo-code.

That’s it!

What do I consider to be an “easy-ish” algorithmic question? Here are some examples:

• Detect whether a string is a palindrome.

• Keep track of the five largest numbers in an unordered list.

• Given an integer, return its binary representation.

• Create a basic inverted index structure from a string of words.

These sorts of questions are simple enough that they don’t require deep CS experience, but are nuanced enough for a strong candidate to be able to show off a little.

Generalist vs. Specialist

Another difficult topic is that of balancing generalist software engineering skills against more specialised skills. Imagine you’re building a Gatsby application and are looking to add an engineer to a feature team. Do you advertise for a software engineer? A frontend engineer? A React engineer? A Gatsby engineer? And once hired, will the organisation treat them as a software engineer or as a Gatsby engineer?

The answer is context-dependent and nuanced, but I do have a heuristic: aim for generalists unless you have a specific need for a specialist.

There are two reasons why I am biased towards generalist software engineering. The first is pragmatic: within an organisation, the more generalist the orientation of your engineers, the more flexible the organisation is. Imagine you decide to migrate your app from Gatsby to Next.js. Do you need to replace all your current Gatsby devs? If faced with that decision, you will probably just decide to stick with Gatsby… even if that is not otherwise the optimal decision. The state of the art is constantly shifting, as are the needs of the business. Having engineers who view their roles and career aspirations more broadly allows you to deploy them on tools and stacks that are the best fit for the needs of your business.

The second reason is that it is my observation and experience that viewing oneself as a generalist software engineer correlates with being a better engineer overall. My belief here is that a software engineer’s skills in a particular context benefit from having broader knowledge and experience across contexts. A React engineer becomes a better React engineer by understanding how Angular works; a backend engineer becomes a better backend engineer by understanding the concerns of the frontend applications that consume their APIs.

There are of course times when a specialist is just what you need. For example, if you’re building a complex stack on top of Kafka, it’s probably worth having someone on the team with significant Kafka experience. They’ll know where all the bodies are buried. Another time you want a specialist is when speed is of the essence. If you’re an early stage startup trying to get to market ASAP with a Rails backend, significant time will be saved by bringing in an experienced Rails specialist.

There is more to be said… perhaps this should have been a topic all on its own. From a hiring point of view, though, the important thing to do is to make the generalist vs. specialist choice deliberately and carefully (see “Be Clear What You’re Looking For” from Part 1), and to make sure that this choice flows through to the entire process. That means that everything from the job description through to the interview rubric should be formulated with this choice in mind.

The Screener

Many companies have the desire to have a “technical screener” stage to the hiring process: some way of filtering candidates before inviting them to a full onsite (or remote equivalent).

I have seen three main types of screener:

1. The phone screen

2. The take-home challenge

3. The online coding test

It is worth noting that many candidates detest the screener phase, especially if you opt for a take-home challenge or online test. At the extreme, especially in the current buyer’s market, that means that some candidates will simply opt out of your hiring process. Nonetheless, screeners do serve a valuable function for companies who are trying to make sure that their engineers’ valuable time is only spent on candidates who have a decent chance of making it through the process.

What you have here is a classic tradeoff between candidate-friendliness and the efficiency of the process. You should make a decision that suits the circumstances your organisation finds itself in. In a talent-scarce market and if your employer brand is not strong, you probably want to avoid pissing off a single candidate. On the other hand if you have plenty of decent applicants for relatively few positions, you will need a way of deciding who to move forward with and minimise time spent on unviable candidates. For example Google cannot possibly put every applicant who looks good on paper through the full interview process.

Having said that, if you do go ahead with a screener you must do everything you can to respect the candidate’s time and skills. That means:

1. Make sure the time investment from the candidate is modest. Take-home challenges, I’m looking at you! Making somebody invest 12 hours on a challenge is not OK.

2. Keep communications up and turn things around quickly. It is incredibly frustrating to invest your unpaid time in a process only to have the recruiter go quiet or for it to take ages for a decision to be made.

3. If it’s a “no”, provide feedback. The candidate has invested time and effort, make it so there’s something in it for them. That way it’s at least a learning opportunity.

Communication Skills

Software engineers are often stereotyped as giant nerds who can see the girl in the red dress by staring at a wall of code, but have trouble stringing a sentence together or making eye contact.

Like all stereotypes, there is a kernel of truth there. People like that exist in the profession. However, they are not likely to be high performers within an organisational context.

Building a software product is actually a massively collaboratively undertaking. While so-called “hard” technical skills are critical to building robust software, the “soft” skills---expressing complex ideas clearly, listening well, understanding customer and business needs, negotiating and co-operating with others---are just as, if not more, important.

That means that testing for communication and collaboration skills should be an explicit part of your software engineer hiring process. In Part 1 we talked about having rubrics; communication skills should be listed as part of the assessment rubric for at least one of the interviews in the hiring process.

Make sure you don’t hire a savant. Building software is a complex team activity and you need folks who can work well with others.

Did you Find this Valuable?

I hope you enjoyed Part 2 of this series on tech hiring. Next week I will share Part 3, in which I talk through my suggested engineering hiring process.

If you are getting value out of People Engineering, I have a small favour to ask you: please think of one person you know who may enjoy the newsletter and share it with them right now.

How is easy that? You’re already here! Think of someone, and share it with them using this button:

Share

Boom, done! Thanks so much for your support.

-Yaniv

Hiring in tech follows Sturgeon’s Law: 90% of it is crap. If you’re not sure whether your organisation’s process is part of the 90%… it probably is. I started putting down my thoughts on tech hiring in general and eng hiring in particular, and it turns out I have quite a lot of them. So I’ve broken this article into two parts.

In Part 1 (this article) I will provide a few general tips for how to think about, design, and conduct an interview process for tech roles. To be honest, most of this applies well beyond tech, but tech is what I know and there are a couple of things (especially supply/demand dynamics) that lend tech hiring a unique flavour.

In Part 2 (coming next week) I will break down the particular anatomy of a software engineering hiring process, including the controversial topic of testing algorithmic skills.

Be Clear About What You’re Looking For

You’ve decided to hire a new employee. How exciting!

It seems obvious, but somehow it seems quite common for an organisation to embark on a process of hiring a new employee without having a great deal of clarity as to what they’re looking for. There’s usually some sort of job description, but if that’s not been carefully formulated and doesn’t have buy-in from the right stakeholders, it’s not very useful.

At the very least, you should have agreed on:

• Key role responsibilities.

• Knowledge, skills, and abilities that a person will need to possess in order to succeed in this role.

• Level of seniority.

• Salary range / budget.

• Reporting line.

It goes without saying that it is essential to write all this down. This may be standard at a larger organisation, but even if you’re small and scrappy, this is one time when you really need to get it in writing. If you don’t write it down, different people involved in the process will have different ideas of what the right candidate looks like. This is, of course, a recipe for badness.

Respect People’s Time

I once worked with someone in recruiting who felt that getting candidates to invest a lot of time into the process was a good way to get them to demonstrate their commitment.

I disagree. Not only is it disrespectful of people’s time, it is a great way to lose great candidates. This is a candidate’s market: make sure that whatever time you demand of candidates is put to good use. This is true not just within the interviews themselves, but also in the back and forth of scheduling and communicating. There tends to be a lot of “faff” in the interview process (ignored emails, frequent rescheduling) that comes across to the candidate as disrespectful and unprofessional. Try to eliminate that.

The Hard Soft Sell

It is well known that technology roles are subject to significantly different supply/demand dynamics than obtain in many other professions. Technology professionals always have multiple options, and that means that you need to work actively to make sure that they choose you when it comes to offer time.

For an employer, the hiring process is as much about selling the role and organisation to the candidate as it is about assessing the suitability of a candidate. In other words, the hiring process is truly two-way.

At the same time, candidates do not like to feel like they’re being subjected to a hard sell or that you’re trying to pull one one over on them. Honesty and respect are core.

The first part of the sell is simply to have your shit together throughout the process (see the previous section). It’s amazing how much of a good impression a well-run hiring process makes. Beyond that, I recommend the following:

Prepare your interviewers & leave room for questions. Interviewers should be aware that they are representing the company and are selling as well as evaluating. Make sure you provide some basic training in making a candidate feel comfortable. It is also important that all interviewers leave time for the candidate to ask questions. This is where they can really satisfy their curiosity and get answers “straight from the horses mouth”.

Provide access to senior leaders. Senior leaders are well equipped to represent the culture and vision for the organisation, as well as giving a good sense of how things are run. Furthermore, involving senior leaders in the hiring process is important signalling to the candidate that they are valued and that the company is excited about the possibility of having them come on board.

Share internal comms. This works quite well (at least it worked well on me!). You can give a real glimpse into the organisation by sharing some all-staff emails, videos of leadership talks, and that sort of thing. The reality of the company as a “body in motion” is often the most exciting thing about working at a dynamic organisation.

Gather Feedback Effectively

First of all, I would like to make an important philosophical point: it is not an interviewer’s job to make a hire/no-hire decision. Really. If a single interviewer in a single interview could determine everything that was necessary to make such a decision, you would only need one interview. In practice, we nearly always have multiple interviews testing different aspects of the candidate, and the hiring decision is a synthesis of all the data that was gathered through the hiring process (interviews, references, work history).

So if an interviewer’s job is not to make a hire/no-hire recommendation, what is their job? In my view, they have two responsibilities:

1. To provide an accurate (and reasonably detailed) record of what took place during the interview.

2. To provide commentary on how well the candidate did relative to the aspects of the role description that the interview was designed to assess. So if the interviewer conducted an algorithmic interview, they should provide an assessment of how well they performed relative to the expectations of algorithmic proficiency in the role description.

If you’re paying attention, it will occur to you that assessing “how well the candidate did relative to the aspects of the role description that the interview was designed to assess” requires that the interviewer know what those aspects are. For that, you need a rubric: a list of things to look out for (e.g. communication skills, user research skills) and the expected level for each of those things. This needs to be written down and clearly communicated to the interviewers. If this is not done, the interviewers will make their own (arbitrary) decisions about what it is their job to assess.

And yes, interview feedback should be written down. Interviewers hate doing this (I know, I’ve had to write a few novels worth of feedback in my time) but it really is important, as it is the only way to get a record of what happened that can feed into a decision process (see next section).

An important matter of hygiene: interviewers must not discuss the candidate until they have finished writing down their feedback. Groupthink is very real, and allowing interviewers to influence each other’s feedback will reduce the amount of useful information you will get to make a decision.

Making a Decision

Given that the primary purpose of a hiring process is to decide whether or not to extend an offer to somebody, I find it fascinating how little thought goes into the process of making that decision. Often it is left to some sort of ad hoc process between HR/TA and the hiring manager. This is full of opportunity for bias.

You’ve put in a lot of effort in sourcing and interviewing the candidate, so make sure you have a clean, repeatable decision-making process that makes use of all the available information.

My recommendation is to have some sort of hiring meeting consisting of a number of stakeholders (but not necessarily the interviewers). The job of the hiring meeting is to review the available evidence and come to a reasoned, evidence-based decision on whether to proceed with the hire or not. Importantly, this should be more than just taking the interviewer’s word for it. This is where the written feedback comes in. The hiring group knows more than any individual interviewer, and needs to take the evidence skeptically and holistically.

The hiring meeting should proceed in a spirit of inquiry, and should be a place for challenge and debate. How many other important decisions do you make at your organisation without some deep discussion and debate? Your hiring decisions deserve the same respect.

What a Lot of Work!

You may be reading this and thinking to yourself: this is a lot of work. A written role description? Written interviewer notes? Assessment rubrics? Hiring committee?

I won’t lie, it is a lot of work.

But do you know what is even more work? Dealing with the fallout of hiring the wrong person. The management time. The emotional labour and do-over work for everybody who works with them. The time taken to put them through performance improvement plans. Not to mention the missed opportunities.

The work you put into running a decent hiring process is some of the best time you will ever spend.

Join the Conversation

Do you agree with the above? Disagree? Do you have some of your own tips or experiences to share? Please join the conversation in the comments section 👇

Being a manager of people can be a very stressful job. For the first time in your working career, you have a direct moral and legal responsibility to look after the success and wellbeing of other people. People are complicated, and it is inevitable that as a manager you will find yourself quite frequently dealing with problems and challenges on the people side. Your natural inclination, of course, will be to try to fix them. It is, after all, your job.

This is a good sentiment, but one that (if one is not careful) can lead to burnout and underperformance in your job as manager. Spending time fixing the unfixable is a thankless and foolish errand.

Finding Serenity

Religious or not, one cannot help but find this prayer resonant:

God grant me the serenity to accept the things I cannot change, courage to change the things I can, and the wisdom to know the difference

This is known as the Serenity Prayer, and it is deep and profound.

It’s got things backwards though.

It Starts with Wisdom

Possessing the serenity and the courage is all well and good, but without the wisdom part it is all for nought.

Most managers I know have courage in spades. After all, they probably became managers in the first place because they demonstrated a superior degree of responsibility and accountability. Good managers wear the problems of their reports as their own problems, and so they should. The problem comes when I see managers struggling to change things that are simply not in their power to change. They possess the courage to change things, but not yet the wisdom to know what they can change; which leads, in turn to a serenity deficit.

The most common example I see is in the management of underperformance. It usually goes like this:

1. A manager has an underperforming or misbehaving employee on their team.

2. They lean in and try to help them improve their performance or conduct.

3. When this is unsuccessful, and with the encouragement of HR, the employee is placed on a Performance Improvement Plan (PIP). This places a huge strain on both the manager and the employee.

4. Whether or not the PIP is initially successful, the employee eventually reverts to their underperformance.

5. The manager tries again, with increasing desperation and despair.

6. Finally, after way too long, the employee is terminated.

7. The manager feels a profound sense of guilt and failure.

This is a guaranteed serenity-killer for all concerned.

One Simple Trick

There are no short-cuts to attaining wisdom, but in the meantime there is one truth that, if used as a starting principle, can serve you as a manager in good stead:

You cannot force people to change

If you feel up to it, there is also a “strong” version of this conjecture:

People do not fundamentally change

In other words, just like a tree, people can grow but they cannot change who they are. Of course this one can be argued, but it is a pretty decent rule of thumb to use when deciding whether to head down the courage or serenity path.

Know When to Fold ‘em

Knowing whether a people problem is one that requires them to grow (possible) or change (impossible) is where the wisdom part comes in. For this there are no heuristics, and only hard-won wisdom can help you distinguish.

But that’s OK, because people problems tend to demonstrate diminishing returns: if your first intervention isn’t successful, then the likelihood of the second intervention succeeding is quite low, and even lower the third time. If you accept this to be true, then this leads to the following conclusion:

Do not overinvest in solving a people problem.

Give it a good try. You owe that to people. If you see somebody with a performance issue, you should be radically candid and very clear with your feedback and guidance. If, however, you do not see significant positive change after this, don’t spend too long trying again and again to solve the same problem: your courage will become foolishness and, worst of all, you will be diverting your attention from noticing and addressing other problems where your courage can be put to good use.

Every single manager I’ve spoken to (including me, I do tend to talk to myself quite a bit) who has ever had to let someone go expresses the same regret: “I wish I’d done it sooner”. That is the sound of wisdom being attained.

Welcome the serenity into your life, do it sooner, and don’t look back.

Before you start reading, I wanted to let you know that I have appeared as a guest on the latest episode of the Champagne Strategy podcast with John James!

John and I had a great discussion, covering a lot of topics about running a tech organisation, from measuring success, to keeping teams accountable, and what it means to be a good manager.

John says:

This is essential listening for CEO’s or founders at tech companies. It’s essential listing for Chief operations officers or other people in a managerial operational role.

Who am I to argue?

Check it out, available on Apple Podcasts, Spotify, or wherever you listen to podcasts.

A couple of years back, I was part of a leadership team that was trying very hard to be transparent in its communication. Yes, we mentioned it a lot to the company, but we really meant it. Our intention was to provide transparency on the state of the company, the reasons for decisions, our strategy, and so on. We thought we were doing a pretty good job.

But over on Glassdoor, a different story was unfolding:

OK, so one disgruntled employee. But then:

And then:

Uh-oh indeed. But also: what was going on? How could it be that we, as a leadership team, could be trying so genuinely to be transparent, and yet many within our team felt that we were not only failing, but lying?

The Curse of Knowledge

The Curse of Knowledge describes the cognitive bias or limitation that makes it very difficult for humans to imagine what it would be like not to possess a piece of information, and hence to properly put themselves in the shoes of somebody with less knowledge than them.

Imagine that a colleague of yours has confided that they are pregnant, and sworn you to secrecy. Whenever you observe them, that knowledge colours your perception. When they repeatedly cradle their belly, when they fail to have their usual glass of wine of Friday afternoon, when they take more bathroom breaks than they used to, it all seems so obvious. How is it that none of your colleagues appear in the least bit aware of these changes in behaviour and what they signify?

To put yourself in the position of somebody who did not already know that critical piece of information, to imagine how you would (or would not) interpret your colleague’s actions in the absence of that knowledge, takes a great deal of effort. And even when making that effort, the act of empathy will be only partly successful. You cannot un-know something.

That is the Curse of Knowledge.

It is a curse because it dooms the knower to failures of empathy, and because it increases the cognitive distance between a knower and a not-knower. In that distance emerge misunderstandings and misinterpretations.

The Curse & Transparency

So now you’re a senior leader in an organisation. You know what’s happening, from the overall business environment, through to the different personalities on the board, a whole lot of sensitive data on business performance, some upcoming regulatory challenges, and a couple of resignations of key personnel that have not yet been made public.

Imagine that, in mind of the above factors, you’re about to make a few changes to the strategic focus of the company. You step up in front of the whole organisation, reiterate your commitment to transparency, and tell them what is happening (and why).

You’ve shared the change in good faith and yet, somehow, the message doesn’t land. You hear later (if you’re lucky) that people are grumbling about the decision and the reasons given. You said one thing last quarter, and have now totally contradicted yourself. Your reason for shutting down Project A doesn’t make sense, and some people suspect an ulterior motive. There are some rumours that the decision to increase investment in Project B was made in order to further the career of an individual said to be favoured by the CEO.

What just happened?

The Curse of Knowledge just happened.

Your audience didn’t know that the end of a large partnership has rendered Project A unviable. Nor did they know that there will soon be a change in regulations that require a greater in investment in Project B for it to succeed. And that thing you said that contradicted what you said last time? You had discussed this in the leadership team and some compelling data was presented that shed new light on the matter. When new evidence became available, you changed your mind (as you should have).

You could have told your team all these things, but you didn’t. Not because you didn’t want to tell them, but simply because it didn’t occur to you. You knew all these things, and so they were rendered obvious to you. So obvious, in fact, that they did not bear repeating; you failed to put yourself in the shoes of your audience, and you simply forgot to share the context that would have allowed everybody to make sense of the changes that you announced.

The Curse of Knowledge has made your much-vaunted transparency look like little more that hypocritical posturing. People don’t forget hypocrisy: it will end up on Glassdoor.

Communication Heuristics to Battle the Curse

The Curse of Knowledge cannot be fully defeated. However, there are a couple of things you can do to keep it at bay.

The first, and most important, is to overcommunicate. What exactly is meant by overcommunicating? To me, it is two things: (1) repeat your key messages a lot more often than seems reasonable or comfortable; and (2) when in doubt about whether your audience has a particular piece of important context, always err on the side of providing that context.

Overcommunication may seem inefficient but when it comes to communication, robustness is far more important than efficiency. Remember that the costs are asymmetric: communicate too much and you pay the cost of small amounts of wasted time, but communicate too little and it could lead to major disasters.

The second “trick” is to slow down and explicitly consider what your audience does and does not know. Our minds are not intuitively good at doing this, so taking a more systematic approach to audit the key pieces of knowledge and context that underlie and justify a decision is a valuable practice.

A Culture of Transparency

The best (though not the easiest) way to fight the Curse is by creating a culture that acknowledges its existence and simply… works around it.

This is a culture of trust where every person at every level of the company trusts each other’s intentions, is vulnerable and open to human weaknesses, and is comfortable seeking to fill knowledge gaps.

In such a culture, leadership communication doesn’t end with grumbling about lack of transparency, but rather with a robust Q&A session in which knowledge gaps are discovered and remedied in real time. Note that simply creating a Q&A session is not enough, as it is the culture that empowers all employees to ask the difficult questions.

How can you create such a culture? Read my article about changing culture to find out!

Join the Conversation

Do you have thoughts or experiences on transparency within your organisation? Please leave a comment below!

Leave a comment

So, how does an organisation successfully undertake a program of cultural change? I write about the broad factors that are necessary in a previous article.

In this piece, I wanted to zoom into one of the more uncomfortable and therefore less often discussed aspect of cultural change. This is turmoil that is caused when the “old guard” and “new guard” of an organisation clash during a period of cultural change.

An Uncomfortable Truth

In my experience, cultural change is very difficult to effect without some turnover of personnel. This takes two forms:

1. Bringing in new people who have the experience and belief in the culture that you aim to create.

2. Exiting people who are either unwilling or unable to go on the journey to the new culture and way of doing things.

Why is this the case? There are two reasons.

The first reason is that as a leader, it is much easier to get a new way of doing things to take effect if you have people inside your team who already have experienced the new way of doing things. This is experience they will have gained elsewhere, so this normally requires external hiring.

The second reason is that you are trying to change culture, and culture has an immune system. Despite your leadership role and positional authority, if there is a critical mass of people representing the old culture, your changes will be rejected as though they were a foreign organ. So, it is important to dilute the effect of the existing culture, and especially to remove the “white blood cells”: those members of the Old Guard who are actively resistant to change.

I wish it wasn’t this way, but in both my experience and my observation, it is the reality of the matter. So for the rest of this post, I will offer some suggestions for how to deal with this difficult transition for the three groups involved: the leaders, members of the New Guard, and members of the Old Guard.

For Leaders: Be Honest & Buckle Up

The worst thing a leader can do in this situation is to downplay the magnitude of change and disruption that is going to happen. This is not the kind of “underpromise and overdeliver” you are looking for.

Be honest and clear with your team. Explain what needs to change, and why it needs to change. Explain that cherished values and traditions will be disrupted, that the place won’t feel the same by the time it is all done. Explain that it is likely that not everybody here today is going to still be around at the other end of the transition.

At the same time, paint a picture of the promised land. The team will not be blind to the many problems that have been piling up. Most individual will understand the need for things to change, and some will be excited to go on the journey. Make it clear that although this change may be arduous, the result will be worth it and will result in much growth and valuable experience for everyone involved.

And finally: buckle up. These sorts of transitions are never easy. Logistically, they’re hard. Emotionally, they’re even harder. There are going to be moments when you doubt yourself, and other moments where it’s clear you’ve screwed something up. Celebrate the small wins, and remember to keep track of the progress that’s been made. Cultural change takes place over months and years, not days and weeks. And it’s never done. But when you take stock and look how far you’ve come… it can be incredibly rewarding.

For the New Guard: Be Empathetic

You’re part of the New Guard. Awesome. You’ve been hired, and either implicitly or explicitly instructed to be an agent of change. You have experience, skills, and attitudes that are different from those possessed by longer-tenured members of the team.

You. Are. Hot. Shit.

As a member of the New Guard, it is painfully easy to be a jerk, or at the very least to come across as one. You look at existing infrastructure, existing ways of doing things, and can see how they can be improved. You are itching to share these better ways. But for those who have been around for longer, your enthusiasm for better ways may sound like “Everything you did is shit. I can do it better. Look at how clever I am.”

So, start with empathy and with appreciation. Realise that without the efforts of those in the Old Guard, there would be no growing organisation to change. They must have been doing something very right. And now that you’ve realised that, vocalise it. Show that you understand that at a different stage of the company, the needs and the constraints were different. Just because things need to change, it doesn’t mean that the old way was bad or wrong.

Develop relationships. Show appreciation. Approach what exists with curiosity rather than contempt. In my experience, what the Old Guard craves the most is understanding, appreciation, and most of all respect. That is their due; give it to them.

For the Old Guard: Look Inside Yourself

Being a member the Old Guard sucks. You used to be the ultimate insider, comfortable and assured of your place, with the ear of leadership. Suddenly you feel on the outside, faced with a bunch of shiny new people hand-picked from elsewhere, and asked to change your practices to new ones that you may not agree with.

You probably feel misunderstood and under-appreciated. You see other members of the Old Guard depart, not always of their own volition. You may start to feel targeted; you and other members of the Old Guard start muttering about a “purge”. Of course, those at the top may indeed be incompetent or malicious. But even in cases where a necessary change is being skilfully undertaken, it probably won’t feel great.

The situation is this: the company needs to grow and change, and you either need to change with it, or move on.

This is a moment for you to introspect, and make a decision. Do you have enough confidence in the leadership’s intentions and skills to go through this transition? Do you have the skills and inclination to do so? Can you put bitter feelings aside? Do you even want to work for the sort of organisation that this one needs to become?

If the answer is yes, this will be a challenging but rewarding experience for you that could lead to much personal growth.

If the answer to any of those questions is no, start planning for an exit… before that plan is made for you. Though it can be hard to leave a place you love and that you have put so much into, this does not have to be a negative experience. It is fine to specialise in a certain phase of an organisation’s journey, and going to new things can be refreshing and stimulating. Plan to go on your own terms, and with no hard feelings. What you contributed can never be taken away from you… think of yourself as a graduate and alumnus of the organisation. Nobody did anything wrong.

The Rocketship

Rockets have multiple stages. The early stages do much of the work of getting the rocket out of Earth’s deep gravity well. But when the fuel is spent, they have done their job. Those early stages are discarded.

Of course, the fact that they are eventually discarded and don’t make it all the way to space does not mean that the early stages are unimportant. On the contrary, they are essential. The later stages can only operate due to the work done by the early stages. (side note: founders should recognise this by putting appropriate equity terms in place)

As with rocketships, so with “rocketships”. If you join a high-growth venture, understand that it will have different stages. Some people may be able to remain with the rocketship across multiple stages, but others will not. That doesn’t make those people unimportant. On the contrary, they are essential.

Don’t Go Yet!

Please join the conversation, share, and consider subscribing.

Share