Monzo’s Stephen Whitworth on the benefits of writing, the ideal candidate for high growth companies and tightening Slack communication
One of the greatest things about covering the tech industry is that the sector is inchoate; everything is new, things develop quickly. There’s so much to analyse and review, and comparably very few doing it well. Finding a niche is easy, but doing it justice is another thing, particularly when those at the coalface and in the know are often working hard enough without putting pen to paper in their spare time. So we are grateful for those with insight who do find the time. One is Stephen Whitworth, author of the newsletter High Growth Engineering and part of the engineering team at UK-based online bank Monzo, the team behind the instantly recognisable flash of fluorescent orange in many wallets and purses. Stephen took some time out of his valuable holiday to speak to Revive about his stellar newsletter, mastering the jack-of-all-trades role, and diplomatically negotiating Slack.
Hi Stephen. Why did you decide to start your newsletter High Growth Engineering?
I started it for a couple of reasons. Firstly, I thought that there was a lot of talk about software engineering in the abstract, but none particularly targeted to the mechanics of how engineering actually gets done at fast growing companies. It's quite different to 'programming'. There's a distinct set of trade-offs that need to be made. You need to build to tight time constraints. You need to change direction often, based on feedback. Systems need to be rebuilt relatively often, and you need to learn a spidey sense for when you should rebuild or soldier on for a couple more months with a janky system. I had plenty of productive conversations at work about these topics, but I couldn't find much on my Twitter feed about it.
What characteristics do high growth companies tend to look for in the people they hire?
Strong generalists do very well at high growth companies. This is simply because there's often too much to do. Specialists that exceed in one area can be useful, but the number of roles at these companies are limited - for example, infrastructure or security teams. In general, breadth of knowledge tends to win over depth of knowledge.
Proactivity and ownership is also key. People that want to own problems end-to-end tend to do very well at these sorts of companies. This means being happy starting off with poorly defined work, figuring out what it means, working on it, and estimating the impact of it after you've shipped it.
To be very general, having good judgement is key to doing well at these companies, and I discuss the concept quite a lot. That's hard to pick up with anything else but burned fingers through experience, I think.
And how can prospective employees show evidence of these traits?
Good question! I'm not sure I have a great answer. Going back to before, I think that writing online is a really great way to provide 'proof of work'. Pick up a couple of different skills and simply write about what you've learned. You'll demonstrate a few things in the process: the ability to write well, pick up new skills quickly, and the confidence to be vulnerable in public by discussing what you don't know. All of these things are great characteristics to have in someone that's looking to join.
How does the job of a software engineer, coder or data scientist in a fast-growing start-up differ from a similar position in a more established, steady organisation?
The lines are more blurred between the roles in a fast growing company. In the past month, I've spent time working as a data scientist, product manager and software engineer, if not formally! This speaks to the proactivity point I mentioned previously: you need to be willing to get your hands dirty across multiple disciplines. I can't particularly speak for more established companies as I've always worked at smaller companies, but I imagine that specialisation would be more highly valued.
How can a mentor (or several) help new employees thrive in high growth companies?
I think it depends what you're looking for. In terms of engineering, it's always helpful to be on a team with a really great engineer that's a couple of levels more senior than you. You'll improve very quickly through getting your code reviewed, and the osmosis of picking up techniques in their approach. I had this at my previous company, and it really helped me.
In more general terms, I think judgement - as discussed above - is the best thing to try and gain from mentors. This might be as simple as feedback on papers you're writing, or chatting through a potential decision. More often than not, a mentor will have been through a similar situation before - often multiple times. They can help you avoid potential potholes!
New employees in high growth companies may quickly notice that ways of working are inefficient and code quality is low or excessively complex. How can someone propose improvements without rocking the boat or disrupting a successful product or service?
The primary issues that high growth companies face is that of opportunity cost: the benefit of the thing that you can't do, because you're doing this. Start ups are often bottlenecked on engineering. Before you propose improvements, ask yourself the question: 'am I proposing this refactor because I believe it will fundamentally improve the business, or because the code is written in a way that is distasteful to me?'. Steer away from the latter, otherwise you'll lose credit against your judgement.
In terms of code quality being low: there are many examples of companies doing extremely well with very poor code quality. The two are often less correlated than you think in the short term! This definitely slows you down a lot in the longer term, but pushing forward with low code quality isn't a bad tradeoff to make in the right circumstances.
You’ve written about Slack in larger companies before. What advice can you give to new employees approaching the delicate task of joining in existing channels of communication and creating new ones?
Monzo is a bit of an outlier here! We tend to create a Slack channel for anything and everything. In general, I'd advise a larger number of more specific channels, than fewer, more general channels. For example, have a temporary channel for the new marketing campaign you're about to launch, instead of discussing everything in #marketing. More specificity allows people to follow along with the content they're interested in.
In terms of joining in existing channels of communication: like software engineering, there's something to be said for consistency, regardless of whether the current approach is suboptimal. Join along with the patterns that people are already using. If you think there's improvements to be made - for example, you might want to suggest using semantic emoji - write a proposal for it first. That way, you're not coming in with a sledgehammer.