Author: Mark Allen
MMS • Mark Allen
Key Takeaways
- Many software engineers reach a career point where strong performance no longer guarantees advancement, and demonstrating strategic and organizational impact becomes essential for further growth.
- With the help of allies, leveraging your manager and by listening to leadership, you’ll need to identify what is impactful for the business.
- You may need to rethink your internal brand – how you’re perceived by senior colleagues and peers, targeting a few areas of significant scope where you can become seen as an organisational expert.
- You’ll need to think probabilistically, and figure out how to handle biasing towards saying yes, without becoming a ‘yes person’.
- This will all require time, patience and continuing to nail the basics of your day job. By starting small, you prove your ability to take on and deliver smaller projects, you’ll begin to build new relationships, your internal brand and get noticed for bigger things.
What makes a strategic conversation
Strategic conversations happen all the time, at all levels of every organisation. When we hear strategy, we think of the C-Suite talking about business trajectory and long term plan. Yet it also includes engineering and product leaders meeting to talk about a re-org, or even a team tech lead, senior engineer and product manager planning out the roadmap.
With each conversation, who is invited matters. To increase your impact and grow your career, you need to be involved in conversations that happen at a greater scope than the scope you have in your current role. This is where priorities are decided, where projects are given out and where the inputs into decision-making surface. Being involved will give you influence over this, help you direct and maximise your impact, and also allow you to bring better context to your day job, and to those working around you.
How to get invited
There are a few ways being invited to strategic conversations can happen. For the luckiest amongst us, position, domain knowledge or the expertise developed over a career will make being invited obvious – if you’re the company’s primary Kubernetes expert, you’re going to be invited to meetings on Kubernetes.
So let’s assume that you’re not an obvious invite. Your journey to getting invited to strategic conversations requires a few key approaches.
Identify what matters
It’ll be difficult to get invited to strategic conversations if you don’t know what matters in the organisation. If you don’t know where the important conversations are happening, find out.
It might be that your manager is kind or capable enough to already give you loads of strategic context. That’s contingent on both a) having a kind and good manager and not one that wants to hoard all opportunities for themself and b) having a well-informed manager.
So ask your manager how they get strategic context – or if your manager isn’t good at this, your manager’s manager. Or perhaps the product director. Ask someone who’s good at this: “Where do you get the strategic context that helps you make decisions? What meetings are most useful – are there any that I could join? What slack channels do you always keep track of? Whose posts always catch your eye?”
And observe what your manager does. At Isometric, my manager is our CTO. I’ve noticed that she’s incredibly engaged with our commercial operations – she’s really observant on the internal slack channels that our commercial teams dedicate to discussing our largest and most enterprise accounts, even if there isn’t an immediate need for the technology team to be involved. By adopting the same behaviour, I was quickly able to figure out who the most important partners are; how they work; what our partners’ priorities are; what our sales teams’ priorities are. I can now rattle off the top 25 companies we’re targeting for deals; I can tell you every company we signed each week for the last month. I’m able to bring all this back to my team to provide better context.
Be a beginner again
Being a beginner is about having curiosity and a keenness to learn. When we started off in software, as beginners, we embarked on a rapid growth journey in terms of technical expertise, fueled by this curiosity, willingness to ask questions and make mistakes. It was probably in this period of our career where some of the rapidest changes in our level of business impact took place.
Even today, as very senior professionals, we probably all still have retained that deep technical curiosity. How does the system work? What caused this bug and how do I get to the bottom of it?
And I think most, if not all of us are also curious about the user problems we’re solving – how does someone engage with the product we build, what went well for them, what worked better.
I’m describing a different curiosity here – curiosity for the parts of the business which aren’t part of our day-to-day job, but significantly contribute to how the business adds value. For an engineer, where typically our work is enabling internal or external users, this could mean understanding the realities of their work environments and lives in a deeper, more compelling way.
And to learn about this business you need to act like a beginner. When I joined Glovo, (a leading European on-demand delivery company), I jumped at the chance to go out and do actual deliveries – I was consistently one of the most active employees doing so. I would go to the Glovo Center – the place where couriers go to discuss their problems and challenges with ops managers. I was based in Barcelona but went on my own fact-finding trip to Castellon de la Plana to understand how product usage differed there. I spent half a day with the real-time operations team to see how they handled problems like thunderstorms disrupting deliveries or app outages.
Why did I do this? Through these activities, I learned a huge amount about how different parts of a several thousand person business worked and was able to bring all this context back to my team. I heard real-time feedback from users. I developed expertise about the business that very few people in engineering could match. And I got exposed to people from all across the organisation, building strong relationships. For many people outside of engineering, I was the only person they knew personally in engineering management.
Build strong relationships
All jobs and businesses work on relationships. To access more and better strategic conversations, relationships are essential. They’re even more important for engineering because in most organisations, engineering is down-funnel in finding out what’s going on.
Engineers are usually seen as implementers; we’re frequently the last to know. From a sales perspective, you might say that as an engineer, you need to move up-funnel. Opportunities, problems, and challenges usually come in through commercial and support teams, possibly moving to product, before going through rounds with leadership and finally making their way to engineering. By the time things get to engineering, it’s often too late to influence them, and only implementation details remain.
In a more technical organisation, the structure might look more hierarchical, but unless you’re the CTO, you can still benefit from moving up-funnel and finding out about problems earlier.
Relationships will help you change that by getting you to a place where you find out earlier. I can think of countless times in different roles where I was asked to take part in a tech evaluation of a merger, fly to another city to lead a workshop, or start leading a new team in China just because I was the person people knew.
Building relationships doesn’t mean setting up a load of cringey 1-1s to ‘quiz people about their job’. I try to find organic opportunities to learn more about someone’s job when they ask me for help. This might come when I’m intentionally being a beginner and doing something new. It might happen when my team handles a ticket filed by a commercial stakeholder, and I’ll help get it done faster or better than expected, then reach out to them and just be honest: “I want to learn more about our customers”. From that, I’ll try to find another way I can help make their life easier, and the relationship building goes from there.
When you have interactions with people, find ways to help them. One approach I use, when relevant, is giving feedback – or giving their managers feedback, without being asked to. Feedback doesn’t have to be solely positive; more people appreciate constructive feedback than you might realise, and it’s a great way to build an authentic relationship.
At Isometric, we’re really proud of our feedback culture. I was recently seconded onto a project working with our science team, many of whom are PhD world leaders in their field. Afterwards, one of my follow-up tasks was writing feedback about one of the scientists to their manager. This culminated in building a much stronger relationship with their manager, who has now asked me to lead a business-wide pre-mortem on a hugely important science project and work with them on another high-priority initiative.
Craft your internal brand
What is an internal brand? The definition I use is simply the words that jump into people’s minds when they think of your expertise, or conversely, when someone needs a topic expert, the topics where people think of you.
We all have things we know the most about at work – areas where our expertise is appreciated and respected. What are the topics where people would think of you as the expert? Now consider who these things give the greatest value to. Is it a particular team? Is it all the front-end engineers? Is it all engineering’? Is it the whole organisation?
When I joined Isometric about 18 months ago, we had lots of hiring to do (we still do), but my first priorities were learning about our tech, our product, our domain, and building out the team. So my six-month review came along, and I was told: “You’re doing well at what’s in your job description, but for the next six months, you need to focus on going beyond just what’s expected, and maximise your business impact”. My internal brand was something like ‘hiring, management, technical decision-making’ – what’s expected and nothing more.
I knew that a few weeks earlier, Google, Meta, Microsoft, and Salesforce had announced roughly a billion-dollar market commitment towards reforestation, and that Isometric was planning to enter this market. I also knew that measuring reforestation requires a lot of remote sensing and data processing, which wasn’t an area where we had existing expertise. Hiring would take time, so while planning for that, I became the organisation’s internal expert on the tech side of reforestation. I read papers on some of the sophisticated measurement techniques used to measure Reforestation, such as Light Detection and Ranging (LiDAR) and terrestrial laser scanning. I refreshed my knowledge of GIS. I met experts doing above-ground biomass mapping.
By the end of summer, I had worked with our team of PhD scientists to write a reforestation protocol, and today a significant number of reforestation projects are using the technology built on top of it. Reforestation expertise is now definitely part of my internal brand.
Choose the green button (sometimes)
So you’ve figured out what matters, been a beginner, made some relationships, built a brand, and an opportunity presents itself. You don’t know how long it’ll take or whether it will go anywhere. What should you do?
Imagine a hypothetical situation in which you were given a choice between either pressing a red button for a guaranteed 1 million dollars, or pressing a green button for a 50% chance at 50 million, which would you choose? It’s about a 50:50 split in how people respond. Would you press the red button for the sure thing, or the green button for the bigger but uncertain reward?
This is how opportunities can be at work – carrying on doing what we know how to do and do it well, or taking a risk by doing something we may be bad at, or could take a lot of time and go nowhere.
The good news is that work life offers many button-pressing opportunities.
But to get as many button pushes as you can, you will have to say yes… sometimes. The hard part isn’t knowing when to say yes to opportunities. It’s knowing when to say no, or when to say “potentially, tell me more”.
I have my own rubric for evaluating opportunities, which includes several considerations:
First, I try to determine whether what I’m being asked to do forms part of an initiative or is business-as-usual work. By “initiative”, I mean something that is planned, involves multiple people (often from different teams or functions), and has been intentionally prioritised over other initiatives. This could be joining a pre-planning group for a new cross-team feature, working with another principal engineer to evaluate a new technology, or being part of a working group to rewrite the promotion process.
Business-as-usual work might be bug fixes, opportunities to be a rotating chair of a workgroup, or completing an already-scoped team-level technical project that someone else no longer has capacity for.
This is all a guideline – I wouldn’t automatically say yes to all initiatives and no to all BAU work, but it helps me build a picture. I might consider taking on someone else’s BAU work if it’s requested by someone much more senior or someone I’m trying to build a relationship with from scratch.
Next, I evaluate if the opportunity will help me grow. Growth takes many forms: demonstrating new skills (like presenting a webinar), learning about a new part of the business, or working with technologies I haven’t used before, even if my involvement is small.
I try to avoid saying yes to too many things I’m “already good at” – partly because I have limited time, partly because as Head of Engineering my role is to find opportunities for others, and partly because there’s always the temptation to stay in the comfort zone doing what we’re already good at.
I also consider what relationships I’m trying to build. If someone unexpected reaches out, I’m super curious about why. Sometimes this is tactical – I don’t want to become the default “person from engineering who solves problems” for a team trying to bypass their product manager. But generally, I’m excited to build relationships with people in other parts of the company.
I still consider opportunities from people I already have strong relationships with too. It’s a minor factor, but still relevant.
As a leader, I spend a lot of time thinking about precedent-setting. If we allow an engineer to cut corners, what precedent does that set? If I approve an out-of-cycle promotion for one engineering manager, what precedent does that set?
The same applies to opportunities. What precedent is set by saying yes or no? Generally, saying yes makes people more likely to come to me with similar things in the future. Saying no means they’re less likely to.
Finally, I’m usually inclined to say yes to small things I can complete quickly, even if they seem trivial. Even small favours can build strong relationships.
When opportunities arise, it’s not binary. Instead of simply saying yes or no, you can say “potentially”, “keep me in the loop”, or “is there pre-reading I can look at?” or “is there already a Slack channel I can join while I figure this out?” The appropriate response depends on context.
If you’re in leadership, you might say “Sure, although someone else on my team might be better placed to take this forward – give me some time to figure that out”.
As long as the person asking has clear expectations about your answer, that’s okay. There might be a way to invest a small amount of time to determine if this opportunity is right for you.
Remember the green button analogy: if you press it 10 times, you’ll probably get nothing half the time. Opportunities are probabilistic – some will go nowhere and have no impact. That’s okay. Even if something seems like a great opportunity, it can still fizzle out.
I try to be vigilant about this and call time if something isn’t moving forward. But it does happen. Early on at Isometric, I tried introducing Metabase (a BI tool) because I strongly believed data would help us. I invested significant time, but with only a handful of enterprise users in our product at that point, the insights didn’t lead anywhere.
Months later, a new team member with a passion for data reintroduced Metabase, and it’s now gaining significant traction. When I attempted it, the timing just wasn’t right to make that impact.
Bringing it all together: A real-world example
Let me wrap up with a story that illustrates all these principles in action.
I mentioned earlier about acting as a beginner at Glovo by doing deliveries and visiting the courier center. Through these activities, I gained extensive knowledge about courier operations. I would often share my findings on Slack or in presentations, quickly building a reputation as someone with a deep understanding of the courier app (which my teams worked on) and actual couriers’ problems across different locations. I also developed good relationships with our courier operations team – all contributing to my internal brand.
I was asked to lead a couple of low-key, unglamorous projects that others tried to avoid – one involved introducing country-specific features following courier strikes in Italy, and another was revamping our incident management and on-call response system. By saying yes to these opportunities, my relationships with the courier ops team deepened further, and I developed more nuanced knowledge of courier challenges in different countries.
I also served as incident commander on call many times, bringing visibility across the company as I handled production issues during peak times (Friday and Saturday evenings), remaining calm under pressure in calls with senior executives. If you asked an executive to name three people at my level in a multi-thousand person organization, I’d always be one of them.
Soon afterward, a business-critical project emerged. Glovo had been threatened with a massive government fine – potentially over a billion euros – due to allegations that we were disguising employees as self-employed couriers. The same happened to Deliveroo, which chose to simply shut down in Spain to avoid the issue.
However, for Glovo, Spain was our home market – we couldn’t just stop operating there. So we decided to completely redesign our courier app. We had three months to meet the government’s non-negotiable legal deadline.
I was asked to lead the technical side of this multi-team initiative – probably the highest-profile project at the time in a business of almost 3,000 people. We revamped nearly everything and got the fine reduced to €79 million – still significant but affordable – and the project was considered a great success.
It was doing the things listed that meant it was me, and not someone else, that was given the opportunity to lead and succeed on this massively important initiative.
In conclusion
To increase your impact and get invited to strategic conversations, remember these key principles:
- Identify what truly matters in your business
- Become a beginner on topics in areas that interest you
- Build strong relationships and deliver value to others
- Use your opportunities and relationships to craft your internal brand
- When opportunities arise, choose the green button (sometimes)
Remember that this takes time and happens step by step. It’s a virtuous circle that builds on itself. But if you apply these principles consistently, I’m confident you’ll be invited to more important conversations and significantly increase your organizational impact.
Podcast: From Code to Strategy: Drive Organizational Impact Through Strategic Conversations and User Focus
MMS • Mark Allen
Transcript
Shane Hastie: Good day folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today, I’m sitting down with Mark Allen. Mark, welcome. Thanks for taking the time to talk to us.
Mark Allen: Thanks for having me.
Shane Hastie: My normal starting point in these conversations is, who’s Mark?
Introductions [00:55]
Mark Allen: So I’m Mark Allen. I currently work as head of engineering in Isometric, which is a large, fast-growing UK climate tech startup. We’re in the carbon removal space, so we issue carbon removal credits, and have a lot of technology that works on auditing and verifying very complex industrial carbon removals. But going right back to the beginning, I actually started out my career as an econometrician. I think the work I was doing, you’d called data science today, a lot of regressions, things like that and large economic models, but data science wasn’t coined when I started my career.
It was only two years into my career that someone came up with the term data science. So it was econometrics definitely back then. So did that for a number of years and transitioned from data science into data engineering, into software engineering, and did a whole range of different things in small companies, large companies, over about 10 years.
I transitioned into management about seven, eight years ago now, when I was working at Skyscanner. I had a great time there working on a number of different products. Moved to a company called Glovo, it’s like on-demand delivery, like DoorDash delivery but Southern Europe, where I graduated into a manager of managers. And by the time I left, I think about eight different teams were in my groups. I left to cofound a startup, we got VC backing. We built a popular-ish HR tool called Ourspace, workforce planning, that sort of thing. Didn’t quite get enough product market fit to raise Series A. And through the journey of doing that, I realized that I really wanted to work in things that had a meaningful positive impact.
So I joined Isometric and today I lead our engineering teams, coming up to about 20 people now. So that’s software engineering, it’s also data and also just starting on solutions and implementation engineering, although mixed and interesting thoughts to see how that goes, and maybe we’ll touch on that later. Lifelong builder. Before we started, I was just talking about how I was doing a lot of weird Raspberry Pi sprinkler systems at home this morning. So really keen on technology, but also really keen on how you organize companies to make them most effective and how you grow the careers of very senior people.
Shane Hastie: Meaningful, positive impact, as an engineer, what’s that mean to us?
Meaningful positive impact in engineering [03:19]
Mark Allen: It can mean a whole range of things, and I think, broadly, I’m very technology positive. I think in most cases technology has a positive impact, not in all, and I won’t call out any specific examples, but I think there’s also a spectrum, right? So I think about working in Skyscanner and I think liberalizing travel, and helping people find cheap flights and travel, experience of the cultures, largely positive. Some negative impacts over tourism, the environment, but largely, largely positive thing, I think. So I put that on the moderately positive spectrum, and I think it goes all the way to people doing amazing stuff to reduce loneliness through AI and solve deeply personal, serious problems.
At Isometric, we are really focused on the climate crisis, and so for me that would be the area where I’d start if I’m specifically looking at something where there is that positive impact. There’s a huge need for technological solutions in combating and mitigating climate change. So, yes, that’s how I think about meaningful impact. But I think, as I say, largely, most engineers are having a positive impact on people’s lives because ultimately people wouldn’t use and buy products if they weren’t enjoying them or getting some value out of them, in most cases.
Shane Hastie: We came across each other because you gave a talk at QCon London on strategic conversations. For an engineer, what is a strategic conversation?
Being engaged in strategic conversations [04:56]
Mark Allen: I think there’s strategic conversations that engineers, all engineers of every seniority are involved in probably every single day at work. So if you’re in a team, that could be how we decide to approach a refactor or how we’re going to break down a project into a series of tasks. If you are a principal engineer, a director of engineering, a CTO, they’ll probably have a much larger scope, and there’ll be conversations about what are our major technical investments over the next 12 months? Are we going to migrate back to on-prem, or what are we going to do? How are we going to staff all of our teams? Do we need to do a reorg?
There’ll be much broader scope conversations, but these conversations happen all the time. And my talk was how to go from the, I guess, smaller scoped conversations that you’re currently involved in and invited to, and get to seat at the table to participate in these larger ones where impact is likely going to be larger, both on the company and also potentially on the whole world.
Shane Hastie: So as an individual contributor, I might desire to step into those bigger conversations, but I don’t even know where to start. Where do we start? How do we start?
Mark Allen: It’s funny because these aren’t things that we usually get taught as engineers. It’s not why we get into software engineering, usually. We get into it to build stuff and see people use the thing that we’ve built. And so it’s a skills journey that people need to go on, and I think the place to start is even understanding and identifying where and what conversations are actually happening, and what the topics of those conversations are. And I would start by thinking about one level of scope more senior than me.
So if I’m a senior engineer in a team, I’m probably involved in most of the conversations that relate to that team. I want to be involved in the conversations that relate to the group of teams around me, a level above. So I would and I do speak to my manager, speak to peers and understand what’s on their mind, what big difficult strategic choices are coming up for them? What are they thinking about and then how can I contribute to them?
We all get invited to these all-hands-type meetings. It might be for your group of teams. It might be for the whole technology organization. It might be for the whole company, but there will be meetings where we all get invited to hear leaders speak.
Now, as a leader, I put so much time, and thought, and intention into what we actually say in those meetings because I want to signal to people the key strategic things we’re working on so that they then take them back to their work and focus their work around them, but also people who are interested can come forward and contribute to those things. So what I would say to people is, pay attention. Pay attention when leaders are speaking. See what they talk about. See what they focus on and use that to calibrate where you put your thoughts and put your time. So that’s where I would start.
Get out of the building and get to know your users [07:58]
Obviously, once you’ve identified a topic, there’s a lot more to do from there. So for me, the key things that one needs to do are to start building relationships with people currently working in areas you want to work in. I recall when I joined Glovo, I was working in the courier space, the rider space, so these people that do deliveries, the people we see out on the streets, on bikes and motorbikes with food in the back. I was working in this space, and I came in engineering, and I felt like I didn’t really know how the business operated that well.
So I wasn’t really able to input effectively into any strategic decision making. So I spent a couple of days actually doing deliveries myself. I went to the courier center where our operations team worked and where couriers would come every single day with questions about both the application that we were building, but just real life questions, like, can you lend me some money Glovo because I’m struggling to pay my bills and support my family this month?
I would just sit there, and speak to people, and just learn about the users and what their issues were. I went to our LiveOps center where we deal with real-time issues and so you’d have these huge dashboards. I literally went round the company, and went to every adjacent function, and spend time learning what they did.
And through doing that, I obviously got a lot of context about what’s strategically important, but I also built relationships, and that meant that when things came up and somebody needed somebody in engineering, I was just the logical person that people would go to. Yes, we know that guy, let’s bring him in. That’s not how I would like organizations to work, but it is. There is some reality that people knew I had context, people knew that I could input, and so that was very useful and it became my internal brand essentially.
Build your own brand [09:47]
I was the guy in engineering that knew all about this and that’s a really powerful thing that I advise people to think about. Think about your internal brand. How do people who are more senior than you perceive you? How do people in diagonal seniority positions, in other functions that collaborate with yours, how do they think about you and how do they perceive you?
And I actively jot down thoughts on this, words, and I ask people as well, what words they associate with me, what are the first things that come to mind, and really try and make them be things where I would want them to be. Because I think often, I recall when I joined Isometric and I think first six months, we have loads of hiring to do. I was trying to get to know the product, and after six months, if you’d asked anybody in the organization what words they thought of me, I think it would’ve been, hiring, strong, technical manager.
Maybe that would’ve been it. And that’s not super strategic, but first six months, and I think after 12 months it would’ve just been very different because I had very consciously focused on becoming a knowledge domain expert on a couple of really important strategic topics, reforestation being an example. I was one of the authors of our reforestation methodology and identifying these strategic topics, building these relationships and then building an internal brand around them was super helpful.
Obviously, there’s another part of this that once you build a brand, you do have to say, “Yes”, to the opportunities that start to come up, and you also have to say, “No”, to the opportunities that are probably not going to be a good use of your time, and you have to say, “No”, to the day-to-day things that you have previously been praised for.
Time is not free, you can’t create more time to do strategic work. You have to sacrifice something and this is the super hard part. All of us have things that we know we’re good at. It could be like you could be fantastic at just quickly identifying and fixing bugs in a microservice that your team own. You could be a really good at being a team-level manager, a team-level lead and making sure the team have great strategic direction. But if you want to grow, you have to figure out how to delegate those things.
You have to figure out other people to do them and you have to cut back on them. Stay away from the things you’ll get praised for, and go out there and into things you’re less comfortable with, and start taking them on, and saying, “Yes”, to opportunities probabilistically as well. So that’s a run-through of some of the topics that I covered in my talk.
Shane Hastie: These are generally not skills that are covered in any engineering training, and often in our professional development as engineers. How do I build those skills?
Developing strategic skills [12:35]
Mark Allen: I always think of these things as a virtuous circle. Firstly, you start small in and reinforce. There’s no quick path. You can’t just go and sit down with the head of sales for half an hour, and make friends with someone from marketing, and then suddenly you’re invited to a board meeting. That’s not going to happen, right? You have to start small and work on reinforcing these things. I’ve had a couple of really good coaches and mentors in my career, but I’ve been very intentional about saying to them, “This is the thing I want to focus on.” Selecting them because I think you are good at this and you can help me. Here’s the value I’m going to bring you. And really deliberate practice and intentional work on building these skills.
They say a great way of learning is teaching others as well. So once you get to six or seven out of 10, and you look around, and you see that you manage or collaborate with engineers who are maybe a little bit earlier on the journey, then you can also start helping them and working with them, and also learning from them because they’ll have ideas and input as well. Those are a couple of ways. Exposure’s also a way, just trying and learning by trying, which can be tough and can be hard.
I also mentor a number of people in my organization. Some of them report to me, some of them don’t, on this topic, and I’m also happy to give advice to people who also reach out to me as well. It happens from time to time that people message me on LinkedIn, send me an email. And I’m also happy to help people who want to grow in this part of the journey. I honestly have struggled to find really good books on this topic to recommend, which is unfortunate, but maybe a gap in the market, maybe should write something and see how it goes.
Shane Hastie: So coaching and mentoring, it is something that, as you said, it’s good to find somebody who’s maybe a little bit behind you on your journey, and help bring them along. But what does it take to coach and/or mentor somebody?
What it takes to coach and mentor others [14:47]
Mark Allen: I think it’s a reciprocal thing, and I almost think that more emphasis is on the mentee, the person being mentored, to be really intentional about it, what they want to get out of it. Not just go to somebody who is senior and successful and say, “Can you be my mentor and distil my knowledge?” I think you have to be very, this is the skill that I want to work on as the mentee. Do you think you could help me with this? And then as the mentor or the coach, you have to be upfront with yourself and figure out whether you can help the person or not.
I try and hold people to quite high levels of accountability. I try and refrain from just pontificating in sharing advice, and saying, I would share my thoughts and then say, “Do you think by the next time we meet”, one week, two weeks, four weeks, whatever the cadence is, “How do you think you can have practically applied this?” And try and set up a plan for them to actually put things into action.
I don’t find just theoretical mentoring, coaching, that effective or useful. So I think it takes that as well. It also takes resilience and a big heart. You won’t always get good results, and you’ll commit to something sometimes, and the other person won’t always reciprocate with their commitment. And the easy path then is to pull back from that or set up a massive gatekeeping against that. But I try and persist with it and try and commit to any given time having five to 10 people that I’m working with. Maybe not on a weekly cadence, but on specific topics. Yes.
Shane Hastie: Shifting focus a little bit, when we were chatting before the conversation, you mentioned the extreme user focus for an engineering team. What does that mean?
Having an extreme user focus for an engineering team [16:49]
Mark Allen: Yes. Yes, I mean, I think we live in a world now of product engineering in many companies where software engineers are not just asked to write code in a vacuum or according to requirements that are written by somebody else in great detail in a ticket, but are given much more high-level user expectations and then are required to break them down themselves, make decisions or provide recommendations on a lot of the implementation details. And they can only do that based on strong knowledge of the user and alignment with the kind of user value the company’s trying to bring.
So one of the things that we really do at Isometric is try and make sure every engineer has a deep understanding of the problem and a deep understanding of the user. And we see from that the ability to ship things quickly, that are the thing the user, radically increases.
You don’t have this back and forth about, oh, I’m stuck. I don’t know what to do. Engineers can make decisions that are right enough of the time to be worth them not having to have this conversation, stop, pause, go back to the designer, go back to the product manager, set up a new user call in seven days time to ask the user some questions.
Some of the ways we do this, so our engineering team spends a significant amount of time interacting with users. That could be being involved in Slack channels, asynchronously, helping them solve problems directly rather than going through a customer support flow. Engineers join calls with our top customers. In the beginning, all of our engineers were given a group of our top customers and they would be on calls with those customers every week, answering technical questions, going through the product, explaining APIs.
We had four people from our team go and run a series of workshops in San Francisco for San Francisco Climate Week. So engineers actually going to people removing carbon dioxide from the atmosphere, in their facilities, in their offices and sitting down for half a day, and understanding their problems, talking through the product, talking through the roadmap. Yes, we have engineers go on site visits and go to facilities in the UK and around Europe as well. We obviously have the product analytics that many people have, and we have engineers setting up dashboards in Metabase using BI tools to understand user journeys. And we obviously organizationally reward all this as well.
We have a culture when, when people show a huge amount of user focus, it’s recognized and when people are reluctant to engage with users and say, “Look, I’m..”. And this doesn’t really happen, but when people say, “I’m an engineer and it’s just my job to put on my headphones and write code”, we would be very intolerant of that and try and align them with what we’re trying to do as an organization. I think the proof in the pudding.
As we know, it’s incredibly hard to quantify engineering productivity in a meaningful way. But even looking at number of impactful production changes as a proxy metric, our top engineers ship 40 to 50 commits, changes to main every week, which is a number that I’m pretty proud of, particularly because, looking at it qualitatively, these are our substantive and meaningful, impactful changes as well. They’re not just fixing a typo in a README or merging a dependency update.
Shane Hastie: Some real get out of the building and go and meet people where they’re at. Another thing that I know from our conversation before that you have a passion about is on-call incident management and doing it well. What does that look like?
Excellence in on-call incident management [20:43]
Mark Allen: I’ve always been really fascinated by incident management. I remember working at Skyscanner, fantastic team, leading global availability. Principal engineer there, John Paris, fantastic. The team around him, really, really good. At Glovo was lucky enough to lead a lot of the changes we made to our incident management practice and bring it in line with best practices, introducing incident managers on call, that sort of thing.
And at Isometric, we use incident.io, which product I really like, and I’ve been working very hard with our most senior engineers to make sure that we are excellent at on-call. I think it comes back to that user focus. When a user experiences pain, holding yourself to incredibly high standards to both resolve the incident but also be able to speak to them and say, “Look, this isn’t going to happen again. Our standards are so high that we are going to get to the root cause of this and fix it”.
A thing that I’ve been thinking about a lot is that I think in all organizations, the way that you improve incident management is by narrowing the gap between the best and the worst people, like apps doing it. And best and worst are very reductive, but I think we’ve all worked with people that are complete on-call heroes.
They just revel in, there’s an emergency situation, get to the bottom of the problem quickly, fix it, go super deep, think about the root causes, implement the fixes, speak to customer and say, “We had this issue three minutes ago. You’ve not even noticed yet, but by the way, we’ve fixed it already and here’s our assessment of impact on you”. I’ve always met people who, in every organization, who are just really good at that. But I’ve also worked with a lot of people that it’s not their natural thing. It might be the pressure.
It might be that they’re just a bit earlier on in their careers or have lower tenure at the company and maybe don’t have enough of a understanding of the code base or parts of the platform to tackle on-call issues in a confident and fast way. So we do a lot to really focus on lifting those people up and improving their standards. So there’s a culture element, which is about a huge amount of recognition for people that do well on call, and then having them talk through their methodology and what they did.
So we have company awards at Isometric, as many companies do, and one of them is called Do It Right, which is one of our operating principles. Build things to a high standard, be rigorous, be robust. And across the whole company and only a third of the company work in technology, but across the whole company, it’s been great to see that award, which is only given out once every six months, be given out to engineers for doing great jobs in on-call incidents, specific on-call incidents.
So there’s that culture element of reinforcement and then the knowledge sharing, which we do every week. We have an on-call run through in an extensive doc, but then summarized by the engineers who were on call, about specific learnings for people, run throughs of how they solve the thing.
Sometimes supported by a Loom recording of here is what I did replayed, so other people can go and watch it. We have the engineers that we think are the best, working actively with other engineers on improving their own core skills. We obviously have run books and materials to support, great tooling incident.io, really good observability thanks to Datadog and Sentry. And, yes, it’s just something that we talk about a lot. I’m the head of engineering, I manage managers and very senior engineers, and my boss is the CTO, and both of us get stuck into incidents. We get involved, ask questions.
We both know how to figure out what’s going on, looking at logs, looking at traces and spans, then help get to the bottom of things. And I think that kind of leadership commitments as well, not in a micromanage-y way, but in a positive all hands on deck here. This is a super important thing for us to get right as an engineering organization, it’s also a really important thing to emphasize.
So I think a combination of those things, what we try and do on call. And of course the final thing I’d say, and maybe I didn’t say this because it’s obvious is, everyone in our engineering org is on call as well. So we don’t have a specialist SRE team. All the product building teams are also on call. You build it, you run it, that kind of ownership thing, really making people feel like owners of the production system and not just people who write code that somebody else then puts somewhere in the cloud somehow.
Shane Hastie: Mark, a lot of really interesting points and some great advice in here. If people want to continue the conversation, where do they find you?
Mark Allen: I’m on LinkedIn and I’m pretty good at responding. Obviously, a lot of my job is hiring and recruitment, so a lot of people messaging me on LinkedIn about positions. So I have to be quite on top of that. So you can definitely get in touch with me there. Sending over a short message about what I might be able to help with is the way I would go.
And then if I can, we might start talking by email, set up a call, something like that. I feel very privileged that in my career I’ve had people that have helped me on my journey, that didn’t have to and didn’t get paid for it a lot of the time. And so, yes, I really am committed to paying that back for people as well who want to get in touch.
Shane Hastie: Paying it forward. Thank you so much for taking the time to talk to us today.
Mark Allen: It’s been a pleasure. Thank you for inviting me.
Mentioned:
.
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.