Ashby Winch
Moving from an architect role to a product-oriented one might seem like a big leap, but there are overlaps between the two roles. Today’s guest, Ashby Winch, has recently made this transition, and in today’s episode, they share what this has been like. Up until recently, Ashby was an architect, with their most senior role at a large logistics operation in the U.K. Now, they have shifted to a product management job, and they are using the skills from the previous role for this new position. We hear about Ashby’s diverse experience, how they came to work as an architect, and what inspired a career pivot. Ashby talks about the challenges they have had with having a loosely defined role and how they have made the best of this situation. Our conversation also touches on the relationship between architects and product managers, the importance of communicating context to developers, and advice Ashby wishes they knew earlier in their career. Tune in to hear it all!
Links
Listen#
Transcript#
Note: This transcript was generated using automated transcription and may contain errors.
David: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We’re interested in the areas of work that set staff plus level engineers apart from other individual contributors. Things like setting technical direction, mentorship and sponsorship, providing engineering perspective to the org, etc. My name is David Noel Romos and I’m joined by my co host, Alex Kessinger. We’re both staffplus engineers who have been working in software for over a decade. Alex, please tell us a bit about today’s guest.
Alex: Sure. Today’s guest is Ashby Winch. Ashby, until recently was an architect and the most senior technical representative at a large logistics operation in the uk. Recently they transitioned into a product oriented role. I had a blast talking with Ashby, so let’s get into it.
David: Well, Ashby, thank you so much for taking the time to join us today. Can we start by having you tell us, I guess, who you are and what you do?
Ashby: Hi. So my name is Ashby Winch and I’ve been in software engineering related kind of roles for about 20 years now. I started off just as a software developer, but I’ve had a sort of procession of roles that have been kind of unusually poorly defined, where I’ve had to make it up a little bit as I go along and figure out for myself what I should be doing, and ended up working as an application architect in a big kind of a FTSE 100 sized retail company for about five years. And I’ve just two weeks ago left that role to go and work as a sort of technical product manager in another retailer. Cool.
David: I’m actually like kind of really thrilled to hear that because one of the things that I’ve always been curious about, that I’ve always wanted to probe in this podcast but haven’t had a chance to do, is sort of like what should the relationship between staff plus engineers and product managers look like and, or what is the overlap, if any, between the responsibilities of a staff engineer and a product manager? So I think we’ll get a chance to dig into that quite a bit. But I think before we do, another sort of another question that I have is what are some concrete examples of things that you’ve worked on recently? I mean, I understand if you can’t give like specific details, but just sort of like to situate the listener in sort of like the type of work that you’ve been involved in over the past recent years.
Ashby: So one of the things that happened then while I was working for Big Retailer was that they announced that they were building an enormous big new warehouse and they were going to invest a substantial amount then into their software capability that went behind their warehousing and their logistics. So at that point point, one of the things that I did with some of the rest of the management team there was spend a bit of time talking to the business. Really this business being warehousing and logistics for us, that was the part of the organization I was working in and asking them things like, you know, if our systems, if we could magically rewrite them all and give you anything that you wanted in n years time, when this whole new system comes live, you know, what would that look like for you? If we could give you the moon on a stick, what would that look like? And they were really engaged by that and gave us loads and loads of material, which was brilliant because until that moment, if someone said to me, how would you go about architecting some new warehouse system? I don’t really have answers. I’m like, to do what? Actually, what does that really mean? And the existing systems were so vast and so complex because it’s a very big business with a very complex distribution network that it’s very hard to know how to get into that. You know, where do you start? There’s too much. The level of complexity is completely astonishing. The amount of legacy is astonishing because it’s a very old company. So those people from the business gave us lots and lots of answers. And there was a very key kind of a theme around data. They wanted more information about was what was happening in their distribution network. And among many other things, I was kind of in a position to do something about that. So I sort of skunk worked some people into a lot of different departments into helping me out, building a more new style kind of data telemetry ingestion system that slotted in neatly with the kind of data architecture around their emerging warehouse management system, so that the application architecture and the data architecture could kind of fit together neatly. So we started producing some really interesting analytics, both analytic capability, actual analytics, business outcomes, and the data capability that fit together with the underlying application architecture, which had really not been the case before. I think that’s really commonly the case when you have a centralized business information department that’s not working for the same people as the people who are generating the data.
Alex: I’m curious, in this process, were you the most senior engineering representative in this sort of development process?
Ashby: Yeah.
Alex: Wow. So when you were doing that, like, how are you figuring out what your role was? Did you have a manager who was helping you figure that out? Were you sort of like just organically figuring out, you know, what was your process?
Ashby: I always have figured it out for myself. It’s been most of those 20 years since I’ve ever had someone who could clearly say to me, this is what your role are. This is what outcomes we want you to achieve. These are the things we think you should be doing, which is a double edged sword in some ways. Like, I really like being able to shape my own role a lot, but at the same time it makes it harder in some ways to get buy in from the 60 million stakeholders if you don’t have a way to say to them, you know, this is, this is my space, this is my role, this is what I do. But I spent a lot of time both talking with people from the business about what they wanted from their future and talking with people in engineering then about what they needed and what the shortcomings were of their processes and kind of tried to build my own mental roadmap of where this could go and try to advocate for the kind of resources and investment that might be needed to get there, which was kind of not my business, but almost had to be my business. You know, you can’t be effective without some input into those things. And so it’s a lot of managing up and sometimes like managing up through multiple levels, which is astonishingly difficult. And I still haven’t figured it out.
Alex: Yeah, so when you’re sort of defining this for yourself, when you’re seems like you’re really going in there and figuring out what you need to do, how do you know that you’re successful? You know, what are you using as signals to make sure that you’re, you know, you’re doing your role in a way that’s valuable to the organization.
Ashby: A lot of the time I don’t, Some of the time I see things sort of three years down the line from when I did something and I think, aha, you know, that happened kind of indirectly off the back of these things that I was trying to set into motion back then. It’s often really difficult to draw the line, especially if it’s been achieved by a lot of advocacy and a lot of tiny conversations. Would it have happened if I hadn’t been there? Maybe, I don’t know. I can’t tell with the analytics piece of work because it was more directly business facing that felt successful because I had a lot of happy, satisfied customers who said nice things about it. But that’s not the entirety of success. Right. I guess if I Talk to people from there. Three years down the line and that thing is still alive and delivering value, then I’ll feel happier about that. But in some ways, I really will never know.
David: That is one of the challenges about sort of trying to drive bigger initiatives is that oftentimes the trajectory sort of takes a while to materialize, and that can be daunting, I guess. I’m curious about the shape of your work until that point. Like, what got you to the point where you’re sort of architecting this entire system for retail warehouses. Especially from the perspective of someone who’s listening, who’s maybe sort of like working as a senior engineer and really interested in some of these sort of bigger picture projects, but doesn’t really know what the path would look like.
Ashby: So I think my path was kind of wandering in a way. I think having shaped my own path in some of my previous roles definitely helped a lot. One of my previous roles was in a. I’m not going to say a startup, but in a very small company where the. The two owners of the company were very open with us all. Like, we all fit in one meeting room, so it was kind of easier for them to tell us everything that was happening. They were very open about their commercial decisions. They were making their strategic decision, making how they were thinking. You know, we always knew how much Runway there was. Everybody knew. The most junior person in the company knew all these things. It was very easy to get involved in some of the more commercial and strategic aspects of it. You were right there and you could make commentary on it and they could take it or leave it. So I think that’s where I learned a lot of the art of not thinking like you own the business exactly, but thinking from that perspective. Like it’s your responsibility to achieve some outcome. Like when you’re in charge of the business, you don’t get to say, oh, well, we’ve gone bust, but it wasn’t my fault. It was all these other things, like, it’s on you. There is no one else.
David: Yeah, I think that that’s a pretty interesting experience and it resonates with the pattern that Alex and I have seen repeatedly as we’ve been doing these interviews, which is basically sort of like gaining that owner mentality at one point. And some of the other ways that we’ve seen people do it is either they, you know, are an early employee at a small startup, or they’re a founder of a early stage startup, or they, you know, lead an open source project that has lots of different contributors, but in all those cases, there’s sort of this. To go back to what you said, like sort of a mentality where you can’t just assume someone else is going to do it.
Alex: Right.
David: You have. You have to treat the problems as your own and you have to assume that you. You have the agency to solve them and that. And that you’re actually expected to sol of them.
Ashby: Yeah, there were a couple of other things I did that were relevant as well. So for a lot of my career, I’ve had like a succession of random side gigs going on, one of which was selling my own time to teach younger employees of manufacturing companies how to code. So I would go into their company for a week in my vacation time and deliver them some training course, which was. It was amazing because these people were always really, really hungry to learn. They’d been trying it on their own for so long and getting frustrated. And you just gave them a little bit of help and they weren’t stratospheric. It was brilliant.
David: That’s really neat. Sorry to interrupt, but what was sort of the impetus for that? What drove you to do that?
Ashby: Just completely random. I think I was on some mailing list where someone posted going, does anyone know who could teach a training course in such a. And I thought, well, I could actually. So I tried it and I really enjoyed it. But because it was effectively me running that as a really tiny business and I had to sell the training courses then because I kept doing it, that really made me think about what value I was providing to the customers. Why would they pay me to come in? Because I was more expensive than an off the shelf C sharp training course where you might be one of 10 people on the course. Why would you get me in rather than someone else? So that was a lot of thinking about value to customers. And then I would get to work really directly with those customers for an entire week. So I got to find out quite a lot about them and what really did constitute value to them. And sometimes I saw them more than once because at least one lot of people came back for another course. So I got to learn what worked well about the first one. And that was really, really useful. Just as a life lesson.
David: I imagine that the teaching aspect would sort of be valuable as well. I find at least that there’s a fair amount of that in our work of sort of trying to bring up the folks around us. And I think I can imagine I have not done what you’re describing, but I can imagine that it would sort of build up your ability to identify, you know, higher leverage ways of bringing people along.
Ashby: Yeah. For some part of my life I was also a ski instructor. And in order to qualify as a ski instructor, because there’s quite, you know, there’s. There’s a. There’s a ticket, you have to have it, you have to do quite a bit of teacher training. Not only, you know, they teach you to ski really tidily, but they also do a lot of the very association. It’s a British association of, I can’t remember. That’s not very helpful, is it? Something like that. Let’s say that in a more tidy way, the association that gives out these qualifications are very deeply into the art of teaching and training and how to do it well. They’re very reflective about that and it shows in the way they teach instructors. So I learned a huge amount of kind of teaching theory from that. I absolutely have reused just time and again in terms of not only teaching, but in terms of influencing people and thinking about the way I practice.
David: That sounds like a really fun way to become a better teacher.
Ashby: It was.
Alex: Yeah. That sounds amazing. So I asked this question earlier a little bit, but I want to try and dig a little bit deeper about, like, when you do the job or do work, you know, how do you make sure that you’re sort of implementing something that the organization wants? How do you work with your business partners to understand sort of the value that you’re delivering? You know, is there anything. Anything specific that you do?
Ashby: I think a lot of this is just about talking to people. That’s it. And when I say talking to people, I mean listening to people, which is not the same thing. You know, you have customers, whoever they are, and of course they don’t all think the same things and they don’t all agree with each other about anything. Sometimes they think opposite things, but listening to them is just hugely, hugely important. And not just once, but, you know, again and again. So I’ve always tried to have just regular meetings in the calendar with whoever I’m thinking is kind of the crucial stakeholders at any point in time. And I definitely think when I’ve done things that I think haven’t worked out well or where I’ve. Like, at least once I’ve done something where I stopped in the middle, I thought, this is not working. I should just stop doing this. It’s not a goer. And one of the mistakes I had made then was not spending enough time listening to the people who would have been the customers, because they would have told me that earlier.
Alex: Yeah, have you ever been in a situation where based upon your experience, you sort of, it seems like you have that understanding of like, we have to sell something of value that people want. Have you been in a situation where you feel like the organization is maybe pushing you away from delivering value or like there’s someone in the chain who may not have understood that and like, how do you help bring that sort of customer focus in, you know, back into alignment with the organization?
Ashby: That is a really interesting question that I can’t answer in a tactful way in a way that the public can hear. Sorry, I don’t think you can put that story in anything. Yeah, you’re not wrong. Leave and go join a different company. Don’t. No.
Alex: I think there’s a difference between sort of being at places where that’s a minority of people versus the majority. And it can be a teachable moment, I think. But it is hard to talk about, that’s for sure. Maybe you could talk a little bit about the transition in roles that you’re making right now. It’s really curious to hear and maybe you could explain a little bit more about what’s going on.
Ashby: So with this analytics piece of work that I’ve been doing, it was kind of increasingly noticeable that a lot of what I was doing in my day to day was product work. It really was. There was a lot of kind of roadmap thinking going on, a lot of analysis of what the customers really needed and what was a pragmatic way to get from it and how to make sure that I had enough buy in from everyone to keep delivering it. And I was mixing that up with technical work because we were a really tiny team and there was not any space for full time product work there. And I found it incredibly difficult to do both of those things. My brain does not switch fast enough. I find it hard to task switch anyway. But task switching between deep, technical. Basically it was data engineering at that point and thinking about products and talking to people and having a nice conversation with my chatty face on and not my. I’m thinking about something like face on. It was really difficult and I thought now is the point in my career where I kind of need to choose which of those things I would rather be doing. And it was an easy decision because I really like the strategic side of it very much, the kind of direction finding side of it. But I didn’t want to leave the technical world altogether. So I ended up in a product management position within a data organization. So it’s kind of the Same job, really awesome.
Alex: So you went from something very technical to something squarely in product. Right. Like you’re not going to. Are you going to be in your job role? Will you be writing code at all?
Ashby: No, no code. But it still feels technical because ultimately a data product is technical. The customers are analysts. Utterly not the same as a B2C or even B2B product. It’s very internal and quite technical. I think my technical background brings a big advantage working in that space compared to someone coming from outside.
David: So is the product that you’re working on internal to the organization or are you just saying that the customers are quite technical but they’re outside the organization?
Ashby: No, it’s an internal data product. So it’s. The customers are data analyst within that company and the data product is kind of focused around the finance part of their organization.
David: Yeah, that makes a lot of sense. Something that I’ve sort of observed is that I think a lot of times, you know, traditional product orgs are sort of externally focused, at least in the organizations that I’ve been sort of involved with. And that sort of leaves a gap for these internal internal products. And product organizations would be sort of well served by hiring people like you to work on the internal facing products. But absent that, I have found that oftentimes that ends up falling into the purview of technical leaders like staff plus engineers, where there’s a fair amount of sort of requirement gathering that happens. And the best way to do that is to be talking to customers. And some of that work ends up looking pretty similar to product management work inside an org. First of all, does that sort of resonate with you? Does that sound similar to the experience that you’ve had?
Ashby: Yeah, hugely. So, yeah, yeah. I mean it does feel like this job is kind of the identical job in a sense, except without the expectation I have to down tools and do half the data engineering myself.
David: Right, right. It’s like it’s, it’s sort of clearly defined, you know, one section of the work that you’re already doing and making that its own, its own role.
Ashby: I think the one difference and part of the reason that I made the move then is that certainly in this product org, and I assume this is reasonably common, there’s a really clear, like a grid and there’s responsibilities, there’s a clear understanding of what outcomes you’re responsible for and there’s a much more in depth thinking about what it really means to work in product, what kind of activities that might involve what you might be doing. And there’s a mandate to do it. It’s not a question whether it is or isn’t my responsibility to make the roadmap for this thing that the team is working on. And if I don’t do it, someone will probably bring it up in my review. Whereas as staff plus or architect as I was, it was always, always a big question what the role should really be. Was I doing the right things? Not everyone in the organization would even have the same opinions about whether I was or wasn’t doing the right things. And there’s kind of politics around that in a sense. Inevitably, you know, if you have a role that’s ill defined like that, I’m not sure that means it’s a mistake to have a role that’s that ill defined, but I’m not sorry to be moving to one that has slightly more structure around it and expectations.
David: As a product manager, surely you expect to be collaborating with quite senior engineers and perhaps architects. How would you hope that, given your experience as an architect, how would you hope that the relationship or the interaction between product managers and architects or senior engineers or staff plus engineers should work?
Ashby: That is a really interesting question. I would love to be in a situation where I’m able to say, okay, well this is the business context. Here is the kind of business roadmap where we might like to be and someone else is in a position to sort of bounce off that and say, right, well these are the, this is the sort of technical roadmaps that I think we would need to build to do this. And here are some trade offs and we could kind of bounce that back and forwards. And I can say, okay, well maybe this thing here doesn’t work in the light of that thing. So let’s work together then to build these two kind of parallel roadmaps that really fit together. I guess there’s a kind of engineering management resourcing roadmap that maybe goes with that. That’s very much like a three legged stool, isn’t it? Of engineering. And I never worked in a place that made that really explicit, but it’d be very, very interesting to try that out.
Alex: Something that’s interesting to me is in a number of organizations that I’ve worked in, there’s this very common theme where engineering is like we need to invest in this thing to make it easier to build product. And that oftentimes what you’ll hear is sort of engineers to cry like, ah, but product just wants new features, right? I don’t think that’s the case all the time. I’ve worked with plenty of product that don’t do that. But like that is a common theme. And I’m curious now that you’re going to have sort of experience on both sides of the fence, how do you hope to sort of navigate that sort of like investment feature balance going forward?
Ashby: So what I have, I have been trying to kind of build this balance in a tiny sense in the, in the analytics sphere where it was previously where I had a really strong technical lead working with me and we were trying to kind of figure out between us what’s a reasonable proportion just within the tiny squad of kind of customer facing work versus kind of platform investing work, like at this stage in the life cycle of our product, what is a good balance in that sense? How does that change as we progress through it? And what would be lovely to see is a company where that happens not just on the kind of micro level within a squad, but then that happens at the higher level in terms of investment, then budgets and in headcounts and like a really thoughtful approach to what are our business priorities and what does that mean for the level of investment that we need to be making in the business facing work in the, in the various different kinds of not so business facing work. I think Mick Kirsten talks about this a bit in the, in the book Project to Product, talking about kind of networks of value and how the value flows through and what kinds of value there are and how you can take a thoughtful approach to varied investment in these different kinds of things.
Alex: Interesting. So when I’m sure you did this as a senior engineer, you know, when it comes time to sort of help explain the business value of work to your team, do you have an approach that you take to that?
Ashby: I always found the engineers seemed really kind of thirsty to know more about why they were doing what they’re doing. I talked to, I just had a random conversation over coffee with an engineer from a completely different team who said, oh, I’ve been assigned to do something, but I don’t really know why. And I knew why. So I gave him that kind of canned explanation of why from the 40,000ft, you know, in terms of what the business really needed. And he said to me, that’s the most useful thing that anyone has told me in the entire time I’ve worked here. Like people really want to know. And some of it’s about being able to tell the story, I think. So I kind of kind of cast around for not quite sound bites, but like coherent short ways to tell a story. Like a really Short thing that you can say about logistics is that a smaller company or historically speaking a company might have a distribution network that’s kind of a small straight line and you can build software around that. But in a more modern company, you’d expect to see quite a more complex and a more fast moving distribution network that changes its shape quite regularly. I can say that quite quickly. Someone who works in logistics goes, oh yes, that makes complete sense. And it explains a lot of engineering decisions that you might make then and it explains why you might want to change a lot of the engineering decisions that were made in the past in a world of a smaller distribution network. Stories.
Alex: I’m curious if maybe you could explain a little bit more in detail. I think it was at the top of our, earlier in our conversation you talked about how because of the warehouse development, you were building a project where the business wanted more data and so you put together a team to sort of build this product that allowed them to build more data. And I’m wondering, so like, was there a point in time where you were like, oh, you need this and I’m going to go build the team and I’m going to explain to them exactly what they need to do, you know, or was it more like of an organic process? And how would, how did you sort of maintain that as a, you know, you know, which kind of process was it?
Ashby: I guess I think I was growing a capability in a sense. Like I had quite a good long range vision about what they needed because we had asked them this really kind of powerful question, you know, like if we gave you the moon on a stick, what would it look like? And that seems really good as a question. Getting people to kind of lift their eyes up from their feet and look into the distance and go, this is where we need to go. Not just what I’m concerned about today or yesterday. So I always had this kind of long range thing in mind, but very much I was building a data capability. So we knew that we wanted the analysts and the business customers to as much as possible to have access to their own data. So the sound bite around that was something like it’s, you know, it’s their data, it’s their warehouse equipment, they bought it, you know, they are operating it, their data, we should give them it back rather than hoarding it inside of SQL databases that they can’t have access to because it’s production. So I always, it felt a bit like gardening, a bit like I knew where I wanted the garden to end up roughly. But I was always Planting seeds and watering and taking advantage of what interesting situations cropped up rather than having an enormous kind of a structure around what he was doing. Like, I wasn’t in a position to have a massively detailed long range plan.
David: I think gardening is an interesting analogy. I think we all kind of find ourselves like maybe with a long range vision, but not so much a detailed path toward getting there. And I think trying to, trying to plan too many steps ahead is a recipe for disaster. I’m curious to dig into sort of something else, go back to something else that we were talking about. You touched on sort of your experience teaching and sort of your, the time that you’ve dedicated toward becoming a better teacher. I’m curious, sort of along the same vein how you think about mentorship and maybe also sponsorship. Like you mentioned, sort of that you worked with a, you know, a very talented tech lead. And you’ve also sort of alluded to the fact that you’ve brought up other people in the organization to take on bigger roles. And, and so I guess how do you think about, about growing the people around you?
Ashby: Sort of broadly speaking, one of the things that’s always important to me, but also that comes naturally to me, like I find it hard not to do this, is sharing context. And that’s something that I don’t see a lot of. Like, across my career, it’s been relatively unusual that the people senior to me or, you know, in different positions than me have felt that that was important or that’s something they’ve done. But it’s really important for me that the people around me understand the broader context. And I universally find that when you explain to them what that is, or when you show them, or you put them in a room with people who are on the coal face and can tell them they level up, everyone can do better work once they understand better what the space is that they’re operating in. What are the considerations? What, what is your boss thinking? What is your boss’s boss thinking? What’s the CEO thinking? Like, I noticed this pattern where you’d see engineers being really frustrated at something and they would often say something like, you know, the people who are driving these decisions keep changing their minds. They don’t know what they want. Or these changes come really, really suddenly. And that makes it hard for us to do good work and hard for us to plan. But from the outside looking in, and because I’ve often seen more of the context of those decisions than they have, it’s not a surprise. It never was a surprise. It was often a sort of strategic inevitability that this thing would happen based on the things that happened before. And had people been more open about that context and spent more time explaining things that you think engineers don’t need to know, like a little bit about how the financing works behind a new warehouse or something, they wouldn’t have been surprised. And that would have made them potentially make better decisions, but also be less frustrated and annoyed just in their day to day.
David: Yeah, it’s a really interesting insight. It resonates with me, but I’ve never really thought about it quite that way before. I’m curious, sort of tactically, what does it look like to make sure that the engineers have enough context? And also, you know, I think one of the, one of the reasons why the business is often sort of not great at sharing that context is because they’re worried about sort of overloading the context. Right. Like, I think it’s, it’s easy to share too much. You can easily just share all the information that the business has and then that’s not helpful for the engineers either. And so sort of, what do you, what sort of approach do you take to filtering that context for the individuals?
Ashby: I think so when I’m doing it, I’m often doing it. I’m going to say face to face. I don’t mean literally these days face to face, but in just a conversation that’s quite casual and that’s about something coherent. So I’m usually not kind of info dumping. It’s not just a random thing that I’ve decided to share everything I know about capital investment in warehouses or something, which isn’t a great deal as a context. There’s things that are actually happening on the ground. And I’m thinking, well, we’ll be able to understand this better if we’re all on the same page about why we are doing this. So then it kind of fits together more. It’s not, I think you have to connect the dots quite tightly actually, because it does take a significant level of seniority, I think, to take this kind of very disparate information about finance this and technical that and strategy the other, and actually connect it up and understand the relations between the things. Like you have to over explain how the things connect together quite a bit.
Alex: Okay, I had a question. So, Ashley, you said that you were doing this for like 20 years, which feels like you’ve probably gained a lot of experience. And I’m curious if you went back to when you started, if you could sort of like give your beginning Self, some advice, what would you, what would you give them?
Ashby: That’s really hard. One of the things that I would definitely say, and I have said to other engineers since is you really have to be the person to look after your own career. I think people can get the impression because there are all these nice grids and people to tell you what the responsibilities are of different roles and all the rest of that. Easy to get the impression that it’s someone else’s responsibility then to make sure that your career goes in this nice tidy upwards trajectory that at that stage you can see mapped out on this grid thing. But of course that’s not true at all. And I think I would have done a lot better if I had really internalized that and not just thought about what really upwards might look like in a career, but also about what different industries you can be in. What different kind of roles exist that are not straight up software engineer, like where can my talents best add value? Which is something I feel like I really didn’t discover until quite late on. Partly maybe because the industry has changed so much right. In those 20 years, it’s completely unrecognizable. But I should have changed job a little more often. I should have not said, well, this job is a good enough job. Hey, they pay me, nobody shouts at me, that’s fine, then, you know, I should have been looking onwards and upwards more consistently.
David: Yeah, I think that’s good advice and I think you’re right. It can feel, it can feel very soothing to have a grid like you described and regular performance reviews and sort of like, oh, everything, everything is actually going fine. But the idea to be more proactive about sort of where you want things to go, I think is, is a good one and a challenge too. I’m curious if there are any resources that you would point folks toward, whether that’s, you know, people that they should be paying attention to or blogs, books, etc. You know, especially things that you found helpful along the way that you would recommend to other, other people.
Ashby: So I think I don’t want to recommend specific things because it changes too quickly and it so much depends what you’re interested in as a person. I think that the trick is to be interested, you know, as a person and to think, you know, what excites me, what interests me, how do I learn more about that, what do other people think about that? And then after you’ve read all these things, to kind of almost throw them away a little bit. Okay, these people said these things, but they said that in their context, they live in a different world, all of them. So what does that mean for my world? Like, you can’t just take the thing that you read in the book and transplant it just like Shazam. Into an alternative place or a different culture and expect it to work. So you have to figure it out for yourself in some way. You can’t read it in a book, but you should still read all the books.
Alex: So we have our last question and answer this however you want. I know that you’re sort of transitioning roles right now, but the question we like to ask folks is like, how much time do you spend coding nowadays?
Ashby: Up until I left the previous job, I had been doing quite an unusual, for me, amount of code. I’ve spent years at a time doing almost none. I really enjoyed that. It was lovely to get into some properly crunchy data engineering jobs and just crank out the code for a bit. In the upcoming job, I fully expect there to be no coding. Also, no being called out in the middle of the night. I’m looking forward to that one. And that’s good too. You know, if I spend all my day having nice chats with people and figuring out what they need and how to get it to them, that’s just equally satisfying, but in a different kind of a way.
David: Absolutely cool. Well, Ashby, thank you so much for taking the time to chat with us today. It’s really been a pleasure.
Ashby: Thank you for having me. That’s it.
David: Thanks so much for listening to staff Eng. If you enjoyed today’s show, please consider adding a review on itunes, Spotify, or your podcaster of choice. It helps others find the show and is a really useful signal to us that folks are finding value in this so that we keep doing it.
Alex: You can find the notes from today’s episode at our website podcast.staffenge.com the website also has our contact info. Please don’t be shy. Sam.