Growth, but at what cost?

Leave a comment

Tough times at Revolut. Image credit to Monito on Flickr.

Get (sh)it done

How does this Slack message make you feel?

Screenshot with credit to Wired, from their article on the culture and practices of Revolut, a UK-based FinTech startup.

There are a number of aspects to this message that make me feel uneasy.

  • The threatening tone.
  • An expectation to work weekends.
  • The open, public declaration of there being a watch list, and the open, public threat that you might get put on it.
  • A “simple rule”, which is that staff that do not hit their KPIs get fired with no negotiations.
  • The Slack emoji reactions: “push”, “get (sh)it done”, a tank, the Mortal Kombat logo. The implication that this is a war, and that winning the war must happen at all costs.

Now, don’t get me wrong – I love startups, and I love an audacious belief to want to take on the world and win. However, something is going (or has gone) wrong with startup culture.

I don’t believe that we’ve ended up where we are through malicious intent. However, we are all influenced by the practices and celebrated successes of the famous companies that we see publicized in our industry, and those celebrated successes are the “unicorns”, the 10X rebels: hustling hard, being disruptive, vacuuming talent and competitors in a race to become the dominant force in the market.

We read books, we watch podcasts, we follow influential business people on Twitter, and slowly, with time, we move the norm towards an extreme because of the echo chamber that surrounds us. Building technology has been enabled by, but also heavily tainted by, growth-or-die culture.

Can there not be a middle ground?

Growth at all costs

SaaS is obsessed with growth. Valuations of companies are typically driven by their revenue and their year on year growth percentage. VCs push founders and their boards to deliver significant multiples of their initial investment.

2x isn’t enough. 5x is middling to average. 10x is the number that has become a cliché: 10x thinking, 10x scaling and 10x engineers. And sure, that’s all well and good – I’d love 10x growth as much as the next person – but relentless focus on only growth begins to breed the wrong behavior.

Growth should not trump good business practices.

Growth should not come at the cost of employees.

Growth should not negatively impact society and the planet.

For VCs, only a small handful of their many portfolio companies need to exit well for them to successfully grow their investment fund. The rest can fail, and although it is a shame, it isn’t the end of the world, because the banker’s books are balanced.

It is extremely helpful to have a challenging VC pushing a company for more, in the same way that the coach of a sports team pushes the players for more. The players should still aim to achieve within the rules of the game.

Additionally, when the VC view is just one view of a diverse selection (VC: “grow 10x or lose”, CTO: “build incredible technology”, CEO: “hire, grow and support fantastic people”), then the tension in the antagonism of opposing viewpoints can create fantastic companies.

Yet, strangely, the worldview of the banker (“grow aggressively or die!”) is becoming the de facto startup culture, ahead of the passion to build amazing things they once dreamed about, or to create jobs in local areas, or to support the lives of employees and their families whilst doing work that they are passionate about.

Aggressive growth at all costs towards aggressive targets can cause poor behavior that can lead to poor culture. Caring about numbers can trump caring about people, and dangerous short-term views and strategies can chosen against sensible long-term strategies. It can make people cheat. Ethics can begin to be compromised.

Take a look at this leaked take home test for Revolut.

Screenshot, again, from Wired. “200 or more sign-ups would be a very strong indication that you’d go into the next round of interview”.

In a high-stress, growth-driven environment this take home interview task could have been seen as a clever way of singling out motivated candidates and also contributing by crowdsourcing to challenging company KPIs. I doubt there was any explicit malice. However, this task is effectively asking people to work for free, which is illegal in some countries.

Cultural norms and high pressure can blinker good judgement in large groups of people. We see it through history, and we see it in companies that go horribly wrong.

Toil glamour

So who is to blame? I think all of us are.

Growth-or-die culture, hustle culture – whatever you wish to call it – is beginning to leak beyond the office and into the daily lives of a whole generation of workers. We are at the point now where many young founders have only been exposed to one way of doing business: grow at all costs until you exit or self-destruct. They can sometimes apply that same logic to their own lives.

An excellent article by Erin Griffith for The New York Times describes “performative workaholism” culture: how celebration of hustle lifestyle (read: toil glamour) is entering the mainstream as an aspiration and a badge of honor, as a grouping of likeminded individuals who have rebranded the rat race as their purpose.

Within that article, we are treated to this tweet:

We can look at the picture of the carved water cooler cucumber and laugh at how silly it is, and perhaps titter at the thought of Dunelm selling “Get Shit Done” embroidered cushions in place of “Live, Life, Love” for your sofa.

Alternatively, we can consider how even co-working spaces – that we don’t actually work for, hence shouldn’t determine our culture – are promoting burnout and workaholism to people that have not got the years of experience to realize that it isn’t going to end well.

Another noteworthy article by Anne Helen Petersen for Buzzfeed explores how Millennials that are working long hours, paying back large debts, and unable to save for their first homes, are feeling the full force of burnout, to the point that running simple errands (“adulting”) can send them into spirals of overwhelm.

A more recent New York Times article highlights the trend that 30-somethings who are financially stable – typically those without significant debt and own their first home – in expensive areas of the US such as New York, Chicago and Boston, are only able to do so with significant support from their boomer parents, even if they have a highly paid, upwardly mobile job.

Is it any wonder that fast growing startups attract those most willing to hustle unsustainably because they believe that they might just be able to escape the rat race through an acquisition or float? Is it a surprise that the rat race is so inevitable for the younger generation – regardless of the prestige of their job – that the only way to tolerate it is to celebrate it?

Is it any wonder that those with a real opportunity to achieve financial escape velocity might begin to bend the rules to ensure it happens?

I guarantee that Revolut are not an anomaly.

We need to reframe success

I believe that we need to rethink our definitions of success in our industry.

I don’t think that it is healthy to continue building companies around a primary function to produce a hockey stick. We need to stop filling up column inches with talk of unicorns and revenue multiples and dedicate time and publicity to companies that are in it for the long term.

We need to focus on, and celebrate:

  • Those that create innovative technology that is meaningful for their users and the world.
  • Those that choose not to locate in big cities and instead begin to turn around forgotten parts of our countries.
  • Those that allow remote and flexible working to enable people to ride the waves of life without letting their mental or physical health suffer.
  • Those that give staff real opportunities to learn, grow and stay for many years.
  • Those that do impactful work for the community and for charity.

Technology companies have a lot to answer for.

How many of us are Certified B Corporations? How many give meaningful amounts to charity, such as 1% for the Planet? Are we really looking after our staff first, our users second and our investors third, or have we got that the wrong way round?

Our industry generates billions of revenue, but are we doing it in a sustainable way for the health of our companies, our people, society and the planet?

Do we think that our companies are going to be around in 100 years? Are we making the right ethical choices about what we do and how we do it?

We all have a say in this matter. Leaders can set an example from the top. However, if we don’t have the power to change where we work then we can vote with our feet, even if it means being paid less.

If we’re not willing to do that, then why not?

Carve out your own thinking space

comments 2
Two calendar events scheduled at the same time have a fight. The one called “Quick chat” wins. Photo by Eugene Lim on Unsplash.

A message to you, Rudy

Dear Managers,

Do you feel that your day is a conveyor belt of meetings, starting at 9AM and ending at 5PM?

Do you find that despite the existence of that space you left in your calendar, neatly hollowed out between stacks of meetings where you intended to eat your lunch, that yet again someone has booked in a meeting called “Quick chat” with no prior warning, without asking you for permission, without giving you any idea what it’s about?

Do you feel that your time outside of scheduled meetings is your own?

Do you find that on a rare day where you have three hours without meetings, you have absolutely no idea what to do with yourself, because you’ve been in reactive mode for weeks on end?

It’s time to take control of your calendar to create space for you. Yes, you.

Yours sincerely,


Management isn’t all about meetings

Having a chaotically rammed schedule isn’t a badge of honour. It’s the fast track to burnout, overwhelm, lack of future planning, and to being unable to pick up critical items immediately as they arise.

As you progress to managing more people, projects, areas of your application, or whatever you end up owning, you can easily slip into a continual reactive mode of operation. This is dangerous.

In this mode you are very rarely taking time to focus on the work you deem most important. Instead, you rely on others to tell you what you should be spending your time on.

I would argue that reactivity should only be part of your role rather than the whole. As well as being available by request for others, you should also be setting your own agenda for the improvement of the areas that you are accountable for. You should be blocking out time to do so, and defending that time rigorously.

But what should you be doing?

If you have become a purely reactive manager, then you may initially find it challenging to decide on what else you should be working on that isn’t just being reactive.

(I know. I struggled with the exact same thing.)

However, before we dive into exactly what you should be doing, we should look at the how.


We begin with the adaption of a mindset that may feel peculiar to you if you have been existing reactively.

The mindset is that your time is important, and you are completely within your rights to control your time to increase the value of what you work on.

This can mean saying no to meetings, initiatives, chats, and anything else that isn’t helping you accomplish the goals that you, your staff, and your company has.

If you are being sucked into ephemera then turn it down. If some work could be delegated elsewhere, then do so.

Your time is precious. However, claiming it can be challenging. Coming from reactive mode into selective mode can make you feel as if you are being selfish, or self-important, or disappointing others.

Perhaps there are truthful elements to all of those self judgements, but regardless of whether you feel them keenly, you should be doing the correct thing for yourself, which should also be the correct thing for the business.

You should be spending your time on the most valuable things, and that should be applauded.

Practical implementation

So you’ve embraced the mindset. But what’s next? Claiming that space.

The way that I create space for myself in the week is by blocking out portions of my calendar. I used to leave parts of the day where I had no meetings as empty space, but invariably others feel that a gap in your calendar is an open invitation to claim it, so I began to take matters into my own hands.

By blocking out chunks of time with a calendar entry called “Deep work” or “No meetings please” or similar, others will think twice about booking over that slot when there is a legitimately free slot later in the day.

It’s easier for the booker to debate in their own minds about whether creating a calendar clash faux pas is acceptable, rather than you needing to have the conversation with them after they’ve claimed a free slot that wasn’t really free because you were actually using that time to work on something else.

Another possibility is setting the default visibility of your events in your calendar to private. Personally, I don’t do this, unless it’s for legitimately sensitive meetings, however having a blanket private policy means that people will be even less likely to book over one of your existing meetings because they will absolutely no idea what it is.

If you’re using Google Calendar, you can even set it to automatically reject meetings that are booked over ones that you already have in your calendar, but I’ve found that in practice this causes more pain that it’s worth, especially when your calendar automatically rejects that impromptu chat with your CEO because you’ve got “Lunch” there already.

Example activities

So now that you’ve nailed blocking out time in your calendar for yourself, what should you actually be doing? Well, that’s ultimately up to you, but here’s some ideas:

  • Mentally “walking the floor”. In your head, iterate through all of the ongoing projects and areas of which you have ownership. What’s going well? What could do with more immediate support from you? Would any of your staff benefit from more time with you? Get it all out of your head into a list and contemplate it.
  • Thinking and planning for the future. Reactive managers rarely get the time to get ahead on what’s next. What are the next projects going to be? Who is going to do them? Is there any work that we could be doing now that could ensure that future work is faster (e.g. building something as a reusable service versus just bashing out the code). What are other teams working on, and can any of it be of use to you? When was the last time you checked in with your peers? Are there any really annoying processes that need improving or killing?
  • Putting time into initiatives that help more than just your immediate team(s). A while ago I wrote about Management Bugs, which is a project that started out of my own self-enforced deep work time. It was interesting to me, it helped out the wider department as well as just my staff, and it gave me wider input into teams that I didn’t normally work with.  What could you be doing to help out your department? Could you dedicate some time to code review of other areas of the application, or help set up a working group for a pressing issue that nobody has the time to move forward?
  • Just thinking. A radical thing to do is nothing specific by default. See where your mind takes you. Walk round the block and it’ll find something important, I bet you.

One more thing…

There’s another benefit of blocking out time like this for yourself. It creates more space in your calendar that you can throw away if the proverbial poop hits the fan.

If the application sets on fire and needs all hands on deck, or if you have a difficult personal situation to handle with one of your staff, you can instantly cancel all of the commitments that you’ve set only for yourself, which makes you a more available manager them others.

That’s important.

People will wonder how you always manage to find the time to get critical things done so quickly. It’s easy when you can fight with your own time, rather than the time of others.

Who could be your Jeff Dean?

comments 2
Portrait of Jeff Dean. From Faces of Open Source, who hopefully won’t mind me using it.


If you’re a programmer, you’ve probably relished in some of the many Jeff Dean facts. Here’s a selection for you:

  • Jeff Dean’s PIN is the last 4 digits of pi.
  • Jeff Dean proved that P = NP when he solved all NP problems in polynomial time on a whiteboard.
  • Jeff Dean once shifted a bit so hard it ended up on another computer.
  • Jeff Dean can beat you at Connect 4 in three moves.
  • There is no ‘Ctrl’ key on Jeff Dean’s keyboard. Jeff Dean is always in control.

Indeed, these “facts” aren’t facts at all, and there’s plenty more where they came from. If Chuck Norris is the embodiment of machismo then Jeff Dean has evolved into the industry’s manifestation of superhuman computer science wizardry.  

You may not know who Jeff Dean is, which, I must add, is entirely unreasonable. Let’s bring you up to speed. Aside from Jeff’s primary job, which is being the Internet, what else has he done in his career?


Before he joined Google in 1999, Jeff attained his Ph.D. from the University of Washington. His research focused on optimizing compilers. His research took him to Digital Equipment Corporation’s (DEC) Western Research Lab, before being convinced to come and join a young company with some interesting problems to solve. That company was Google. According to Slate, there were only around 20 other staff there at the time. It was very early doors at a pivotal company.

During the last 19 years, Jeff has co-designed and implemented a large proportion of the most impactful and world-renowned Google infrastructure, including numerous iterations of the crawling and search platform, the initial development of AdSense, Protocol Buffers, GFS, MapReduce, BigTable (which you may use as HBase), Google Translate, and more recently, TensorFlow. If you’re working in a software company solving problems with large amounts of data, you’re probably using a system or library that evolved from something that Jeff created.


It’s no accident that Jeff has been involved in Google’s most innovative projects. In addition to being a programming sorcerer, he is equally good at helping others grow through his mentorship and technical talks, thus allowing others to multiply their careers by working with him. He also is highly respected and listened to by Google’s higher ups, making sure that he gets to place himself on the most impactful projects.

A candid Quora answer was written about what it’s like working with Jeff, which, surprisingly, isn’t all roses:

I worked with Jeff Dean for about a year when I was on the Google Plus team.

He’s mostly just a really friendly, smart, helpful coworker.  Like any other Google engineer, you could walk over to his desk, ask why a particular product worked the way it did and he’d give you a really good description of the decision factors and thought process that went into that particular architecture. He gave tech talks and demos to show his work and fielded questions just like any other senior engineering staff member.

But he was also a little intimidating. Jeff definitely has the ear of upper management and they give him free rein to pretty much work on whatever he wants to.  So if you’re working on a particular project that is at cross-purposes with something that he wants to do, then you kind of just get railroaded because his code is getting *launched* no matter what…  So you may have to just adjust your plans to accommodate!

So there’s a bit of “jujitsu” to working with high-powered folks like him — you find ways to align your projects so that their weight is being thrown in behind you, not against you.


Portrait of Sanjay Ghemawat, also from Faces of Open Source. I also hope they don’t mind me using it.

A recent New Yorker article gave a candid insight into Jeff’s life and also his partnership with Sanjay Ghemawat. The pair work inseparably, often choosing to pair program together, bouncing ideas off each other whilst one forges ahead on the keyboard. They worked together in a similar fashion at DEC. They even live inseparably: “Uncle Sanjay” often comes to dinner at the Dean’s household on Fridays.

To the purist programmer, and aspiring technical wizard, their situation seems perfect: two best friends working on the most interesting problems, together, in a trusted self-directed manner, free from the pressure of typical feature delivery and sprints. They’re some of the world’s best engineers, so they just get on with what naturally comes next, since they are implicitly drawn to the problems that are on the cusp of innovation that will be impactful for Google.

The reality for the 99%

But, as you’re reading this, you’re probably thinking that’s all well and good for Jeff and Sanjay, superstar engineers who have actually changed the world: they can have their freedom, but we can’t. They were in the right place with the right intellects at the right time.

Instead, us less-than-geniuses get our silly deadlines set by people who don’t know anything about engineering, we get processes and ceremonies that detract from actually getting good work done, and we sit in crowded open plan offices where we constantly hear noisy sales calls on the phone all day. Good for them, we say. Good for them.

Here’s the question: are Jeff and Sanjay a direct consequence of right brain, right place, right time, or is any of their situation replicable within our own working lives? After all, their situation seems unreachable. The New Yorker describes the leveling system within Google’s engineering department as follows:

Today, Google’s engineers exist in a Great Chain of Being that begins at Level 1. At the bottom are the I.T. support staff. Level 2s are fresh out of college; Level 3s often have master’s degrees. Getting to Level 4 takes several years, or a Ph.D. Most progression stops at Level 5. Level 6 engineers—the top ten per cent—are so capable that they could be said to be the reason a project succeeds; Level 7s are Level 6s with a long track record. Principal Engineers, the Level 8s, are associated with a major product or piece of infrastructure. Distinguished Engineers, the Level 9s, are spoken of with reverence. To become a Google Fellow, a Level 10, is to win an honor that will follow you for life. Google Fellows are usually the world’s leading experts in their fields. Jeff and Sanjay are Google Senior Fellows—the company’s first and only Level 11s.

Here’s another thought: if 31 year old Jeff and 33 year old Sanjay turned up at Google today, would they be given the same freedom and autonomy that they currently have at 51 and 53? Or would they end up in a regular development team for countless years, working on a tiny, tiny cog in a gigantic machine?

A formula for success

We could make some hypotheses about why Jeff and Sanjay have been so successful.

  • Preparation. They are both extremely smart individuals.
  • Luck. They joined a world-class company at a critical time in its growth, allowing them to work on the most important problems.
  • Riding the company growth curve. Their success in said problems allowed them more and more access to two critical things: the ear of the upper management and the visibility of the cutting edge of their domain.
  • Earned autonomy. Trust from management allowed them their own choice of work and protection from less innovative projects taking their time.
  • Multiplied output: Access to innovative work allowed them to apply themselves to the problems that made themselves and the company grow.

Not all of us have the fortune or geographical placement to get a foot in the door at the very beginning of the next Google or Facebook. However, there are ways that we can create opportunities for our staff to emulate how Jeff and Sanjay work once we get our departments to a reasonable size: say to the point that there are a small handful of engineering teams.

What we can do is to add roles to the top of the individual contributor (IC) track that allow staff to become more self-directed, to propose their own projects, and to live outside of traditional teams.

The top of the IC track

A year ago at Brandwatch we promoted a small number of senior and long tenured staff to the position of Principal Engineer. This isn’t a role that we have invented; a quick search on Google will show you that it’s pretty well known and has been around for a fairly long time. For example, Jay Kreps was a Principal Engineer at LinkedIn when they were working internally on Kafka. There are similar role names at similarly large companies, such as Distinguished Engineer.

Engineers in these roles aren’t just hitting deadlines by clearing out tickets. Instead, as described by Drew Eckhardt, they’re doing work that materially improves whole company gross profit. This can be innovative architecture that leads to new products, scaling and optimization that saves significant percentages of company budget, and acting as a role model and coach to other engineers who become dramatically better at their job for spending time with them.

From my research, the role at companies of that size can often include management. An answer on Quora suggests that people at this level at Google (Level 8+) have more than 50 people in their division. However, we are not at Google size, nor did we want to blur our individual contributor and management tracks together.

We kept our Principal Engineer role solely about the engineering, because that’s probably what Jeff would have wanted if I could hire him.

How I implemented a Principal Engineer role

We have an Engineering department of around 160 people. We wanted to allow the chance for our best performing senior engineers to break away from the traditional scrum team format and to become more self-directed in their work. The exact reporting line differs in our numerous divisions, but I wanted to share with you how it works in my division.

I run the Applications division, which is mostly focussed around a suite of our core SaaS products. This does involve a number of interesting infrastructure and architecture challenges, but the bulk of the development effort is closer to the user: much more so than the division working on our web crawling, data infrastructure and primary storage.

Due to this, the roadmap of my division is primarily led by Product rather than Engineering. Carving out the space in order to do Engineering-led innovative projects – notably those that may not have a immediate pay off, such as infrastructure that can invent new product possibilities – can be hard to prioritize against Product’s feature roadmap.

To reuse a compiler optimization term, I hoisted the promoted Principal Engineer out of a team and had them report to me instead.

A diagram of where the Principal Engineer sits in my division. Dotted lines represent that other parts of the org chart have been hidden.

The Principal Engineer’s own work stream is set mutually between myself and them. This sometimes means that they are working alone, and sometimes they may be doing some work for one or more teams. This allows them to be a welcome addition to any given project, rather than a spoken-for resource that could do any old piece of work dished out to them. It protects their time and their interests.

A recent article from Silvia Botros, a Principal Engineer at SendGrid, and the accompanying comments on Hacker News highlight how the Principal role requires cross-organizational collaboration, whole department and company understanding, and strategic thinking about where technology is going, both inside and outside of the company. This aspect is the key that sets Principal Engineers apart from their Senior Engineer counterparts.

Some of the traits that we outlined for Principal Engineer are below. These traits form part of our internal career tracks document.

  • Experience: Typically has 10+ years of experience. May have previously been a Senior Engineer, Principal Engineer, or CTO at a start-up. Is a deep technical expert in their area and has a drive and vision for where we should be going in the future.
  • Technical knowledge: An expert, potentially at a global level, in their area. Designs, builds and suggests architecture that will grow the company in the future. Has a track record of leading the design and implementation of high risk or mission critical projects, particularly those that require the application or invention of new technology or techniques.
  • Mentorship: The go-to mentor and confidante for our engineers. Is an expert and patient teacher.
  • Consensus building: Champions new technologies and the modernization of legacy systems. Is able to win the hearts and minds of senior leadership in the company and also motivate and drive their colleagues in Engineering.
  • Conflict resolution: Can contribute to discussions and even resolve conflict at a senior leadership level. Rides the balance of business needs and engineering needs expertly.
  • Time spent reading or writing code: 75%+

Currently, our three core products have one Principal Engineer mapped to each of them. As far as I can tell they are happy in their roles, but I’m sure they can correct me in the comments if they’re not.

It’s working out pretty well so far. The Principal Engineer in my division has delivered a new distributed bitmap index system to speed up our products. In another other division, we led a major project to rearchitect our storage to deliver 50x speed ups for our customers with the largest data sets.

In summary

You and I will probably never be as successful as Jeff Dean or Sanjay Ghemawat, however, we can create the space within our organizations to allow others to form similar skills and work on highly interesting and challenging problems.

Implementing Principal Engineer roles, even at smaller companies, can have an extremely positive effect: it can champion engineering-led projects, give individuals great career growth, inspire others to stay on the IC track rather than jumping into management for progression, and, most importantly, can result in the invention of some excellent technology.

Who could be your Jeff Dean? Think about it.