From Code to Strategy: Drive Organizational Impact Through Strategic Conversations and User Focus

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: