Transcript
Suhail Patel: I want to spend time giving all of my secrets to growth away, especially in a growing organization. I’m going to start my talk with advice that I give to engineers at the senior level. A safe anchor point for many senior engineers has always been technical mastery. You see a problem. You design some architecture. You work in a team to crank out some code. You build a complicated system, roll it out at scale, rinse and repeat. This is a happy place for many engineers. Naturally, you think in order to progress, the journey should in theory look something like this. You expect to be rewarded as you take on more technically challenging problems, climbing the ladder.
As you get to staff-plus, your role is to solve the most complex technical problems. It’s natural to think like this. As you get to staff-plus, the technical challenges are a small part of the equation. Sophie Weston’s talk described career growth as a journey. It’s not a linear ladder that you climb, but rather a meandering path filled with difficulties and opportunities and tangents along the way. I want to spend my time giving some of these tangents away. You need to master influence, communication, and strategic thinking. You need to find intrinsic motivation and take control of your own growth journey. Don’t leave it in the hands of your manager or leaders or peers to define your growth. My talk is going to give practical advice on finding and filling in the cracks within your organization, as you get to and go beyond staff-plus. These are actionable takeaways on how you should be thinking about your use of time. These are going to be techniques to grow yourself, grow your teams, and grow your organization.
Professional Background
My name is Suhail. I’m a Principal Engineer at a company called Monzo. We’re based in London. I work in the platform group, where we provide all of Monzo’s underlying infrastructure, libraries, and tooling so that engineers can focus on building a bank and not have to worry about the infrastructure. Monzo is a consumer-facing retail bank in the UK and in the U.S. We’re expanding into European geographies in 2025. We don’t have physical branches. We power all of our banking features through an online app. We have over 11 million customers and rapidly growing in both our personal banking and business banking offerings. The inspiration of my talk was a reflection of a mistake that I made a decade ago.
Every day, some of my colleagues at the time would go outside and grab a coffee at a local coffee shop. I didn’t really like coffee at that time, so I didn’t really attend. That’s 30 minutes that I could spend writing more code, and getting more tickets across the line, and more story points, and delivering increasing shareholder value. Little did I know that these coffee trips are where the real social connection got made. Naturally, after the social connection was made and the ice was broken, it’s where the decisions got discussed and ideas were formed. Nowadays, these social visits, they work in an environment where everyone is in person. That’s not really how we work nowadays. We only really get to know our colleagues through their profile photo and how they communicate on Slack.
If you’re really lucky, you might share a stand-up, or you might have a one-to-one over video call, or a discussion session where you’re engaged with some of these colleagues. It’s easy for people to form a perception based on the limited interaction that you might have through your profile photo and your persona on these messaging platforms. We use Slack internally really religiously. I can’t remember the last time I actually sent a work email. Tools like Slack have a visibility problem. It’s very heavily biased towards things that are relevant in the current point in time. Once time elapses, it’s really difficult to find things in the past. You drown in a sea of noise when you try to find something in the past. At Monzo, we don’t use Slack for long-form content or for detailed discussion. I want to give people an opportunity to see that long-form side of me, where that deep thinking happens. We have to find other avenues.
Beyond Engineering
I want to cover a few areas like these in depth. These go just beyond writing code on a daily basis. Why are one-to-ones and interviews and onboarding and writing and public speaking important as an individual contributor? I want to cover why these are great uses of time and how you can leverage these things that you might be roped into for your company, for your company needs, and how you could use those for personal leverage. Personally, for me, I’m an inherently selfish person. I like to engage with people as early as possible, and I want to be a friendly face. Part of the goal is a selfish goal. I want to be visible publicly and internally. I want other leaders and engineers to think about me when they have a problem that they might be facing. This, for me, is the best form of soft influence.
Conversely, I want to know who I want to reach out to. I don’t want to be bounced around between people when I have a problem. I want to be able to directly go to the person who’s going to help me solve my problems and advocate for changes that I want to make. This is especially important because I run a platform team. Our platform team is focused on solving infrastructure blockers. Finding impactful work goes beyond just polishing the Kubernetes cluster every quarter. Our technology stack, by design, doesn’t have all the batteries included. We’re opinionated about what we build and what we support. I got to go speak to people to understand what bits we should double down on. Software design and architecture doesn’t happen in a vacuum. We don’t want people to be rolling their own technologies, because I don’t think that way we succeed as a platform team in providing all of these technologies across Monzo.
One-to-Ones, and Discussions with Others in a Safe Setting
Many engineers, they often revert to a mode where they think one-on-ones are talking about performance, or selfish needs, or what to do better, or things that you could be working on. Some of the best one-to-ones I’ve had are the ones with no agenda. Learning about someone’s family dynamics, or vacation they went on, or their passion for cooking, or in my case, you can come speak to me, I’ll bite your ear off about talking about coffee. I used to work with an engineer who used to work in a glass factory, and we spent an entire 30 minutes talking about all the machinery they operated to move these massive glass panes around. Obviously, one-to-ones have a bit of a time cost. While the social element is important, often there is a desire or purpose to talk about moving a technical problem forward, or discussing new challenges.
By breaking the social connection, the ice, you can get to these problems in a much more deeper manner. Nowadays, my technique is to have all of these one-to-ones in person, as much as possible, logistics providing. I find virtual one-to-ones to be quite distracting. For example, you get a notification on your screen, or maybe an incident is going on, and your attention is immediately diverted. Whereas you can’t really do that in person. Nothing beats having someone’s undivided attention. Extending that into the manager one-to-one. A ton has been written about having structure for your manager one-to-one. You’ll see tons of literature on having brag documents, and showcasing your achievements, and managing upwards. These techniques really work when you’re early on in your career.
How should that style change when you become a leader? As you become a leader, you have two primary responsibilities. Sophie touched on this quite succinctly. Sponsoring people who might need that boost in recognition, and also, conversely, folks who might need a bit of support. Also flagging up challenges in shipping velocity. The manager one-to-one, as you become a leader, shifts from purely individualistic needs to the needs of your team and your organization. As a leader, you need to listen extremely carefully to the technical and organizational challenges raised by your managers and peers. Use this to inform you and your priorities, where opportunities lie beyond your day-to-day. One of the key goals is expanding your sphere of people. They call it sphere of influence.
As engineering managers and leaders join in other areas of the organization, and as your company grows, at some point, your organizational hierarchy becomes much more complex to keep on top of. I remember when I joined early on in Monzo, you could meet everyone. We were all in one office. You could go and speak to people. There was a channel where the CTO announced everyone who had joined, and a bio, and everyone got up in the all-hands and gave a 10-minute pitch about themselves. In a small organization, you can do that. As you’re adding tens of engineers on a week-to-week basis, that stuff falls down quite rapidly. Naturally, what happens is, when someone has a business need, you get a reach-out from someone, or someone will make a connection on your behalf. For example, my manager might put me in touch with someone else in another part of the organization. A lot of that relies on luck, too much luck for my liking.
Interviewing
How do you find leaders you can learn from and rely on without having an immediate business need in mind, at this particular point in time? The best in technology that we have, we’ve gone towards forced automation. You have things like Donut bot. You might get lucky, Donut might match you with the right person who has a solution for all of your immediate problems without you even knowing it. How do you make your own luck? How do you find and invest in the right people who are going to be a net positive for you? I spend a fair amount of my time week to week interviewing. Most individual contributors that I speak to hate interviewing, because it’s more time spent away from writing code and solving the immediate business problem. I truly believe that interviewing is the most highest leveraged things you could be doing as an individual contributor.
The goal of the interview isn’t to grill the candidate and ask a boilerplate list of questions that your company has provided, like a robot. That’s such a missed opportunity. As a leader, you can use it as an opportunity to pry into how other organizations work and the architectures that they’ve built, and the problems that this individual have solved for that you might not be familiar with. Tailor the interview for the person you’re speaking to, is common advice that we get. My absolute favorite interview to run is what we like to call the technical project deep dive. We run this interview with engineering leaders. The leaders can bring a problem that they’re intricately familiar with. It’s like a reverse systems design. It’s one that they solve for within their company, so they’re the expert. They come in and they explain the system that they ended up with and the context behind it, alongside all the technical, scaling, and organizational challenges. It’s two engineers basically geeking out on a virtual whiteboard and sharing knowledge.
If you’ve been to QCon, the architectures track is basically that every time I run this particular interview, but in a one-to-one setting. Quite often, I’ve come away learning more about a new technology or a challenge that we’re facing right now, or how to deploy something in a production setting. Interviews like these don’t have a binary solution to a defined problem, which makes it really hard to score. I can see why many organizations don’t do this. As a leader, you can extract signals from this interview format. We really value diversity in the thoughts in the people that we hire. The way that we interview really matches that.
One of my really popular blog posts on the Monzo blog is demystifying our interview process for backend engineers. Rather than keeping our interview process obscured away, we give the entire interview format away, and exactly what signals we’re looking for, and what books to read, and what to focus on, and what not to focus on. Personally, for me, this post has been a huge net benefit, because I constantly hear from people who have joined the interview and said, “I read your blog post, because it was sent to me by the hiring coordinator”, and that helps break the ice. People are going to interview with us, and folks who don’t even make it through the process, I get reach-outs from them on a daily basis. They are thankful that this blog post helped them ease the nerves. As a result, I get to expand my network of people. It’s a double win-win.
Something that was instilled in me in my very first job, where I worked for a small startup, is always be hiring. Tech as an industry isn’t all that large. If you’re looking for a specific set of skills or expertise, that filters down the number of people quite significantly. I’ve had my fair share of bad interviews. My first ever interview, I was given a task to write some Java code on paper, while the interviewer sat there and answered questions on his Blackberry. Then he got into an argument with me about how garbage collection works in Java. People remember and speak about bad hiring practices and intense interview formats.
As a leader, you have influence in what these formats look like. You have influence in your interviewing practices. You can frame your interview practices so that candidates are shouting your praises. They come away with a positive perception. You can influence the interview process within your company and set it up for success to find great people.
Leveraging Onboarding
When a new person joins, there’s a window of time where their calendar is mostly empty. It’s also quite a scary time for new joiners, because new people are in unfamiliar territory. They might not have many friends and peers that they can rely on. They don’t have even any structure to their day. I found this to be the perfect opportunity to reach out and say hi. Provide an anchor point to answer any questions. Everyone has questions on day 1. You’re getting bombarded with information and context. Have someone with tenure like yourself break some of the ice and help answer even some of the basic questions. This sort of reach-out only takes a couple minutes each week. That interaction means the world to someone else. We have a Slack channel called Yay, which is where it gets posted by an automation of all the new people that have joined. I spend a couple minutes every week just looking at that channel and just doing a quick reach-out, saying hi, introducing myself.
From there, a connection can bloom. That’s all you need to get started. While we’re talking about onboarding, this is one of the first meaningful places of documentation and code that a new engineer or engineering manager or director will read and write. We even recommend our onboarding for folks in the manager or director track to gain context on the technologies we talk about daily. We’ve invested really heavily in our onboarding process for backend, web, and mobile engineers. Again, this work has been deliberately done and shaped by individual contributors. It’s engineers talking to other engineers. The motivation for this investment is twofold. We want new engineers to get onboarded and shipping quickly. Also, onboarding is the perfect place to so establish patterns and principles.
In our onboarding document, one of my favorite chapters is called legacy patterns. It’s patterns that we want to deprecate, stuff you will come across in the code base that we intentionally call out and say, don’t continue to do this. It’s one of our most powerful chapters because folks can understand that code bases are evolving over time. Our code base isn’t perfectly manicured.
However, these human-driven processes, like writing documentation and interviewing and things like that, are the primary ways cracks can form within your organization. You don’t have a CI check for your interview process or your onboarding documentation. All too often we succumb to processes like how we interview or hire because that’s always the way that we’ve done things within our organization.
Using the onboarding example, onboarding documentation is the last thing that most people think about. You roll out a new system or you’ve updated a framework or a library specification. Where’s the checkbox that says, update the onboarding documentation? Something that is meant to be a paved road that’s designed to help get engineers started becomes littered with footguns and potholes. This can meaningfully reduce confidence in day 1 for a new starter. Imagine someone ships something and they immediately cause an incident. That person is going to be scared to shipping and production. It’s going to take a long amount of time for them to reduce their shield. As an IC leader, you have a lot of influence to go and challenge and improve these processes meaningfully.
Writing Visibly for Others to Learn
As I’ve been on a growth journey, one thing has been a constant. There’s a lot of writing to be done. I spend a lot of my time writing documents. I’m going to put my hands up and say I’m not the best at writing. I’ve never been one for prose, or I’ve not maintained an interesting blog. I’d be terrible as a LinkedIn influencer. I’m always worried about being perceived for having an idea that hasn’t been fully formed, and that idea being challenged and knocked down. An idea being dissected and challenged is something that I’m always worried about.
One technique, especially internally, that’s unleashed me from that anxiety, is making it crystal clear in any documentation I write on how well formed the idea is and who the target audience is, and whether I’m even soliciting external feedback. That way, I can put my thoughts in public rather than DMing it to someone without fear of answering to a bunch of bystanders. I can write down half-formed ideas and I can come back and augment as I learn more information or find other people or read books on things like that.
Public Speaking to Expose Yourself Outside Your Org
When you’ve got an opinion that is well formed, it is important to showcase and advertise it. This can be through writing or through blog posts, but also giving talks and presentations like this one. Often, I hear people say that their work isn’t novel, their work isn’t innovative, their work isn’t brand new, it’s all derivative. I argue that most of the work that we do on a day-to-day basis in our industry is derivative. My entire presentation is derived from the many shoulders of people who have written documentation and literature on how to grow engineering organizations and how to grow yourself as an engineer. I’m eternally grateful for that. Some of these people are here at QCon. People want to hear your unique perspective too. You can get started by sharing some of that unique perspective internally. It doesn’t need to be polished or curated. Some of the best internal talks that I’ve seen have been the unconference style, where you have maybe 15, 20 minutes of setting the context.
Then you let people unleash and ask questions or draw on a virtual whiteboard, or go through a group. From there, you can build real social connection and break the ice. Seven years ago, I got on stage at QCon, a stage very much like this, for the first time in London, and gave my first ever conference talk. It was my first ever QCon and my first ever big conference. I’d given one or two talks at meetups before. It was quite a scary prospect. I’m an imposter, the imposter syndrome definitely kicked in. Rather interestingly, just like 5 minutes before this talk, my watch gave me a ping and said, your heart rate is elevated. I’m an imposter today right now. I am very nervous on this stage. You don’t see behind this exterior, but I’m sweating underneath. I’m so glad that I didn’t back out. Giving that first talk has led to a huge shift in my career. I’ve been able to travel the world on other people’s dimes, by giving talks and speaking about my experiences. Going technically deep and just nerding out with the audience.
Attending conferences is great, it’s not for everyone. If you’re here just for the talks, just to listen to the talks, you are drastically missing out. Conferences like QCon have a fantastic speaker to attendee ratio. The real value is finding people and talking to people and making those connections. I also deem this part of the always be hiring. These are people that you might not hire into your organization. I’d wish to have Sam Newman or Sarah Wells and all these folks in my organization, but I might be wishing for too much right here. I’ve got all these people that I can rely on. If I’ve got a technical problem, I can go and reach out to Sam. He’s a connection on my LinkedIn, number one. It’s someone that I can reach out to. I’ve built that social connection with those individuals, which helps me a lot in my career.
Making Ambitious Bets
Once you’ve gotten back from your conferences, chock-full of ideas and inspiration, and maybe even a network full of people, you need to take what you’ve learned and put it into practice. As a technical leader, you need to place ambitious bets. That bet can be paying down technical debt, maybe investing in a new technology that you’ve learned, making an existing system more efficient. These seem relatively obvious.
Most senior engineers will know that this is the case. There is a series of organizational and team bets too. For example, writing documentation so that others can self-serve, automating some pain away, lightening up your floater workload. This frees up the time of yourself and also of others. I take strong inspiration from Annie Duke’s book, “Thinking in Bets”. You have finite brain capacity and finite people to go and implement a vision. Let’s say that people listen to everything that you say. You have that power. You only have a finite capacity of people and a finite amount of time. You need to be deliberate in the bets that you advocate for.
Note that I said advocate for. Bets can come from elsewhere. Not every bet is the one that only I make. These might be bets that are being made by other people that need a bit of support, a bit of boost, a bit of a leg up. Part of the role as a leader is supporting choices which align, but can also be a net benefit, and also knowing when to defer something for later. Every choice is a bet on a particular future outcome.
Not every bet needs to be massive. We’re not going to wake up tomorrow and all say, we’re all going to rewrite all of our existing systems. I often hear from a lot of senior engineers, especially senior and staff-plus engineers wanting to align themselves with only the most impactful work. How can I do the most impactful thing within my organization? Then, what they do is they spend absolutely ages trying to figure out what that most impactful work is. That is time that is wasted.
Often, the high impact business initiatives are well-staffed and already well-funded. They might just need your support on big decisions, but once teams find their rhythm, they run like clockwork. There’s no point aligning yourself with them. Say you have a smoldering fire in an adjacent area, a system that’s in maintenance mode. It’s not performing well, but it’s not broken enough for an entire team that’s working on the ambitious thing to go and drop everything and fix it right now. Fixing this kind of stuff at root gets put aside. We’ll deal with it later. We’re going to be rewriting that system in 6 months anyway, but it’s still in production. What that leads to is an incident, and that takes away time from an entire team. This is cyclical. I see this in every organization that I speak to.
A system goes into some level of maintenance mode, it isn’t well looked after, an incident occurs. You see this in many post-mortems. This could have been preventable with a bit of TLC. Often, it is our decision-making process as leaders that gets us into this state. Don’t let your quest for the most impactful thing detract from delivering on impact. You can’t just shield away as being a bystander when these things go wrong.
Building Teams for Project Success
A few years ago, we had a very interesting conversation with a financial regulator here in the UK. We run all of our banking infrastructure on top of AWS. As part of some new regulation, they mandated us to consider the very unlikely, but potentially small situation that all of AWS goes down permanently. We spent a fair amount of time walking the regulator through options, especially because we’re very cloud native. We build all of our infrastructure on top of AWS. We work with AWS to embed their products and embed their technologies within our organization. It’s quite a big ask. Like what happens if AWS just disappears off the face of the earth? One option that we considered is that we’re going to take all of our existing infrastructure and make it modular and go multi-cloud. I get this question a lot. Why didn’t you just go multi-cloud? We’ll have an entire copy of our infrastructure in another cloud provider.
That dramatically increases the effort in the amount of infrastructure that we need to keep in sync and also doubling our platform costs. Instead, we went on quite a different route. We challenged ourselves and placed a bet that we could engineer a small but effective backup bank for the most critical business needs. One that could provide the minimum amount of functionality that customers want to transact and send money, which is what the regulator cared most about. We’ve got entire blog posts on our blog on the technical details, if you’re interested in that, and future talks coming. Suffice to say, just spinning up a backup bank isn’t an easy task. There’s a lot that’s involved. This required coordination amongst many parts of the company and many different stakeholders.
One of the decisions that we made as individual contributors is that we had technical implementation that was centralized within one team. Rather than causing a bunch of swirl across the organization amongst competing priorities, we curated a centralized team with expertise across the breadth of Monzo to go and ask the right questions and have implementation coordinated centrally. The working pattern here was dictated and established by engineers. It wasn’t TPMs and product managers and things like that. We got rid of all of the overhead that was involved in this decision-making process and engineers came in and used their conviction to say, with conviction, we’re going to be able to build this. This is what we need and this is the kinds of people that we need at these particular points in time to be able to execute.
One of the best things that you can do as a leader is invest in a playbook for running technical projects, big or small. This isn’t necessarily a rigid step-by-step process, but you need to outline the things that you consider for running a technical project to success. This seems quite rudimentary on the outset, and this could be an entire talk in itself, from systems discovery to socializing your ideas, running architecture reviews. There’s a whole social element before you even get to writing a line of code. When you actually get to technical implementation, you need to think about your implementation and then how you’re going to safely roll it out. Once you’ve rolled it out, where is future ownership going to sit? How long is the system intended to be in production? Throughout this entire exercise, you’re going to be thinking about things like cost both in terms of the financial bottom line and also the opportunity cost and people cost.
Remember, the amount of people you have access to is finite. I think John Allspaw said it best from his blog post in 2017, engineering decision-making is a socially constructed activity. Running technical projects isn’t about making just localized decisions and picking technology, especially in a growing organization. Disparate processes are being developed independently and they need to glue together at the end. This is how technical projects come together.
What we do at Monzo is we run architecture reviews and these are structured proposal documents which outline what we’re building in plain English. Sometimes this will have things like a bit of sample code or API specifications and a whole bunch of diagrams, and an architecture review can come at many different stages. It can be before a single line of code is written to get a sense check for the unknowns and the dependencies that might come out of the woodwork. Alternatively, it can be after writing a prototype to the point where it’s ready for future extensions or rollout to customers. We run these at different stages.
One principle, though, is that the architecture review is not a gating process. It’s not there for engineers to come in and just say no. It’s there to collaboratively solicit expertise. What we want to do is we want to use soft influence to steer people in the right direction and nudge them to go and build on top of our values and our architectural principles. You have a lot of access and context. I get invited to many architecture reviews and I make a lot of connections. I get involved in many discussions and proposal reviews and more. For me, giving that context outwards is one of the most powerful things I can do when relevant.
This empowers to help more people understand the way that I think and the way that the organization thinks. Some of the best leaders that I’ve met make their decision process, including input from others and the context behind their decision-making process really clear and really visible. As a bonus, it serves as a basis of documentation for the future. This phrase is often termed, give away your Lego. Tell people what you’re working on, how you’re working on it, how you’ve reached a certain decision, what bits have you taken into account, what discussions have you had, what you need to follow up on.
Beyond just sharing context within your organization, shouting it into the ether, there’s also formal mentoring where you take someone under your wing. I think most people understand what the mentoring relationship is, giving guidance, tips, and advice. With mentoring, make sure you align with your mentee on the end state of your mentoring relationship. Mentoring, I don’t think, is meant to be a permanent exercise. Otherwise, that just becomes a routine check-in. Does the mentee want to succeed in a particular project or navigate a hurdle that they’ve had within their professional relationship with someone, or learning a new skill, or leveling up at something? Make that end state really clear. Once you’ve reached that end state, even as a leader, you can shout about that success when you see another person succeed. When a particular project is done, equally important is celebrating the wins. Large projects, especially, can be very stressful endeavors, lasting weeks, months, and sometimes years to get over the line.
As leaders, it is up to us to publicly celebrate key milestones being achieved and be an amplifier. It’s very easy for me to put together a little bit of budget and help celebrate that team’s success. Stickers, swag, dinners, call it whatever you like, whatever method works well for people, these things go down a tree. Also celebrating in engineering forums, like a big collective channel, like a big team channel or squad channel, a leadership channel, can really help bring visibility forward and promote a job well done. Especially highlighting the people who were involved is really key. When key milestones are reached and when the project is over, it’s important to do focused retrospectives. How do folks feel about the project? How do folks feel about the journey to get there? Where you ended up? What the future health of that system looks like? It’s a great opportunity to talk about incidents, retrospective blockers, and how you made progress.
Often, projects don’t go linearly to 100%. They meander. Often, you’ll have tremendous progress and then get blocked on a big stumbling block, run into a brick wall, which might take a bunch of time to navigate around. This stuff is completely normal and it’s important to have these retrospectives and understand how these could have been caught earlier, if they could have been caught earlier.
Normalizing Incidents
No matter how good your architectural design is, I’d be lying if I said everything works perfectly first time round. Systems can go bad. Often that’s when projects are being worked on. Quite often, you see a lot of post-mortem reports, especially in the public sphere. It’s usually when something is being touched, something that was being modified, a system was being rolled out. Very rarely do you see stuff go down in a stable state in most mature engineering organizations. In reality, production is where all the fun bugs surface. Your response as a leader needs to be measured relative to the impact. This is a perfect way for us leaders to lend a supporting hand to folks who might be earlier on in their career. Having an incident can really impact someone’s confidence. Words of support, actions of support, and words of encouragement can be very helpful to these individuals.
Incidents are the true test of psychological safety, and being able to dive into issues under pressure. Being vocal about what went wrong and how your team intends to fix it or how a squad intends to fix it and under what time frame can be massively helpful, even for the smallest of issues. It’s about owning the problems. As leaders, we need to instill this mentality with our team members, help them work through this process. I’m sure I’m preaching to the choir here. For some folks, incidents will be part and parcel of things that they do on a day-to-day basis. Incidents can be turned into positive advertisements and advocacy and understandings and empathy for the complexities and the virtues of your project and also your principles. It’s an opportunity to showcase as a leader how you fix problems at the root.
One technique that I personally really like is investigation documents. Often, in incidents, you have structure, you have a timeline, you have cause analysis, and you have contributing factors, and post-mortems, and many other things. How can you apply those practices outside of incidents? Maybe there’s just a bug that you’ve caught or a request has come in. As you’re onboarding someone, someone needs to go through the ringer and go through a bunch of step-by-steps. These techniques that can be used outside of an incident, just in a much less stressful way. Start with the context in an investigation doc as you understand it and provide a narrative of how you investigate things.
Most crucially, include paths that didn’t come to fruition. Think of it as writing down a trail of your thoughts. In these investigation documents, similar to how I described writing in the past, you can talk about how fully formed your ideas are and the target audience. You can assume some level of competency, some level of knowledge for these investigation documents. These investigation documents are suited towards someone of your caliber and your expertise and the expertise of your peers and your team. You can include things like code, ad hoc SQL queries, scripts that you might have run. Because you want to make sure that your analysis is correct. You’re not meandering down a bad path.
Lastly, it’s important, even if you don’t get to these in your day-to-day structure, to include any follow-on steps. You aren’t committing to these things. These things aren’t tickets on your team’s Jira board. At least you’ve spent some time thinking about that at that particular point in time, so if that issue happens again, you know exactly what to do. Lastly, put these docs in a really visible space. We put these in a big Notion database in our squad pages so that they are easily discoverable.
The Rapid Pace of Software, Technical Design, and Implementation
Beyond writing words and talking about things in the public sphere, the world of software, technical design, implementation is marching forward much faster than we can keep on top of even as leaders. Things that weren’t conceivable even a few years ago are now possible on modern compute.
The other day I actually saw an SSD disk which is faster than a DDR4 RAM stick, in throughput, that is. Many of the paradigms that we’ve become so used to are being rapidly challenged as hardware and software progresses. Take for example software like DuckDB. If you’ve not played with DuckDB, it’s really awesome technology. If you’ve ever thought of data warehouses or you use something like Databricks, or Athena, or Snowflake, or what have you, you’re going to think about large clusters spending tens of thousands of dollars on compute, or even having something out of band like a ClickHouse cluster and things like that. DuckDB is a data warehouse that runs like SQLite. It can run in your browser. You can hoover up a whole heap of data and analyze it really quickly. It gives you a lot of power locally. It can be embedded within your application binary.
If you’re running, for example, a little bit of analytics within your software, you can attach DuckDB and do analytical queries in band within your process. It’s just one of many examples. The challenge is how do you find and how do you keep on top of all of these extracurricular activities while also learning all of these new technologies and keeping on top of hardware, doing all the one-to-ones, conferences, all the interviewing, where is the time to deliver software? Does anyone’s calendar look like that? That is not my calendar, thankfully, but my calendar looked very similar and it was really quite depressing. Just even giving a presentation like this, I like to say to people who are preparing for QCon, every minute that you are spending presenting on stage is 15 to 20 minutes of prep. Who here has 20 hours spare of uninterrupted focus time in your working week? No one. I’m afraid to say, unfortunately, there is not a magic bullet for time. You have to be intentional on how you spend your time in growth and learning.
This is very similar to what Sophie said. Sometimes it does take time outside of normal working hours. I mentioned very earlier that I’m selfish. I decide to spend the time by asking one very simple question. Will this provide me with commiserate value in return? If I spend 20 hours on this, will I get return for that 20 hours spent? If the answer is yes, then I will go and spend the time. Otherwise, I will politely decline the opportunity.
Folks might remember the world of defragging your hard drive. It’s very empowering to do the same with your calendar and your day-to-day routine. Becoming a bit more intentional where you spend your time and your energy. If there’s one thing to take away from this talk, think about, where is the time where you’re actually playing with stuff and experimenting time? Where is that slotted in into your day-to-day? We often become so beholden to our calendar, especially when you’re in a company with tenure. You have repeating one-to-ones and you’ve built established processes, and you’ve got a bazillion squad meetings and a review over here and a whole bunch of other stuff. The leaders that I think execute best and the leaders that I have met aggressively think about an exit strategy for when they’re involved in conversations. An exit strategy for recurring meetings and reducing the time to decision.
For meetings that are unavoidable, things that you have to be involved in, how can you get to a shared understanding as quickly as possible? Let’s say that you’re running a workshop. That workshop is scheduled for three hours. Does that workshop need to be three hours?
Three hours is half of the day. By the point you get into some focus time, the entire day is wasted. Does that workshop need to be three hours long? You take, for example, Amazon. Amazon has the six-pager format to provide context beforehand. Can you reduce the time to get to a yes decision or to get to some level of consensus? Have a concrete agenda and make the best use of your time. What about things like interviews? You’re not going to have a six-pager for an interview or for a one-to-one. How do you derive value from these things? For me, where I see value being derived from things like interviews is, am I learning something from the individual that I’m interviewing, or am I here just checking a box? You have to be intentional in your interviewing practices or your mentoring relationships. These are intentional strategies to reduce the time to positive signal and to make the best use of your time and the time of other people.
Surviving as an Engineer in the Era of LLMs
Beyond time, there’s also the other problem, the blank cursor problem. To get on board with a new technology or to understand a new piece of software, you’d have to scratch your head, get up to speed with something before you can be productive. For me, this is where large language models have been a huge help. They accelerate for me the time to play. You can get something productive and usable in a very short period of time.
Originally, I wanted to give my talk a clickbait title like this one, and it’s no open secret, the world of LLMs are evolving. They can reason through code. If you saw Birgitta’s talk, I thought that was a really balanced talk on the use of LLMs. Every day we see a new product cranking out code, cranking out maybe a well-designed application. If you’ve used Cursor, you’ve used Windsurf, it’s remarkable how these things can reason through an existing code base. Every day we see tweets like this, AI is coming for our jobs. This is from August 2024.
Forty percent to 90% of code being written in a business context is being engineered by AI. Garry Tan recently said, of Y Combinator fame, that 95% of code written in some of the startups in the latest Y Combinator cohort is written by AI. Many of us here will probably roll our eyes. Vibe coding is all the rage right now, and it works well if you maybe have a Greenfield application. Birgitta had a very fun screenshot in her talk, where there was an engineer who put a product out there, and then that product got spammed, and they weren’t very technical, so they didn’t know how to debug it. I don’t think we’re at the stage where you can vibe code your way through many years of context and historical decisions. How do you think about these things as a leader and as an engineer? I recently came across this reference framework. It’s from a place called the AI Native Developer.
Again, you may roll your eyes, AI Native Developer sounds like some job spec, like blockchain developer. Is it a fad? Is it going away? I think this diagram provides a very similar mental model to how I communicate with humans, how I communicate with my peers. For me, as I’ve become a leader, rather than just writing code and being focused in my IDE all day long, I’ve spent a lot of my time talking about my intentions. What do I think my team should be pursuing? Where are my ideas lying? Effectively going from a producer to maybe like an overseer, a manager, doesn’t necessarily mean engineering manager, but overseeing and making sure that these things are set up to success. Making sure that I communicate my intent from generating content, being the person that’s actually writing the SQL query in terms of like data or storing data, to actually providing knowledge on how to work with that data.
With development in the sector, our roles shift more from producer to managing and orchestrating. We have to focus on crafting our intent and getting really good at describing what we want versus how we want it. If you ask me where one of my current focuses lie, for the engineers that are choosing to use AI, it’s inevitable. Engineers are using AI on a day-to-day basis within Monzo. I want to make sure that our code base doesn’t become a dumping ground for AI slop, code that has been generated and nonsensical. This happens twofold. Making sure that we’re providing the right tools, if folks want to use Cursor, or Copilot, or whatever the hot new tool is, they want to go implement an MCP server. We have the ability to be able to do that.
Most importantly, I want to feed in to these tools, all of our legacy patterns and things to avoid. Adding rules for us to say, do it like this. Making sure that we have things like static analysis. I think Birgitta mentioned like Sonatype, and things like that, to be able to catch when these bugs are being delivered into production before they actually get delivered to production. I want to make sure that whatever the fad of the day is, it’s AI today, whatever the new model comes out, doesn’t compromise on our stable and secure posture within Monzo.
What Is the Core Premise of a Staff-Plus Engineer or a Leader?
Let’s go back to my original point at the beginning of this talk. What is the core premise of a staff-plus engineer or a leader within an organization? I’ve talked through a whole bunch of factors. Technical mastery and being great at delivering technical solutions is what most organizations will test for. It’s the thing that you get interviewed for. You’re going to do systems design exercises, and coding exercises, and they’re going to be the foundation of your identity. This stuff is bread and butter. You’re not going to start doing this less and less. You’re not going to forget how to do these things. You’re going to be expected to go dive into the code and architecture and design systems when the going gets tough. There are elements that you need to invest in yourself to think more strategically, especially within a growing organization.
First of all, invest in a playbook to deliver on the hard business outcomes. It’s going to be really company dependent. Your playbook may not be translatable from company to company. It’s going to be based on your company’s ways of working. Part of that playbook is going to be picking and investing in the right technologies at the right point in time. You need to keep an ear in the industry to figure out what those technologies are in the first place.
For me, the best way to do that is learning about these technologies in a setting like this and then getting hands-on. Make sure you invest in your network. Code and systems are ephemeral, but people can really make or break your goals. Within your teams as a leader, be an amplifier of people. People that you support and you manage and people that are outside of your periphery. You might not have direct managerial responsibilities, but the growth of junior engineers is part and parcel of your role. When you need expertise, make sure that you can hire it in or cultivate it within your organization by utilizing your network. Bring your teams along in the pursuit of technical excellence. Things like architecture reviews and incidents are great learning opportunities for less tenured engineers on how to balance technical and organizational priorities. You’re able to give away the way that you think about these problems and help them understand your way of thinking.
Lastly, within your organization, as a leader, you have a license and credibility to invest in ambitious bets. Don’t let technology be the thing that is the blocker for launching your business ideas. That’s what you’re here to achieve. Don’t be a bystander when things are going wrong. Lean in and course correct. The best way is to keep an ear on the ground and aligning with other leaders. Getting in early when they join to build that credibility and build that relationship, and maintaining those relationships rather than waiting for them to come to you. Finally, organizational cracks are something that you have to keep a really close eye on. As a leader, you have the ability to go in and say, I think we should go and fix this thing and I’m going to spend time investing in it. Address these problems at the root. Address these problems before they proliferate and people become tolerant of them.
See more presentations with transcripts
