The hosts ▻
Our guest ▻
Things mentioned ▻
Let's chat some more! ▻
The hosts ▻
Our guest ▻
Things mentioned ▻
Let's chat some more! ▻
To have your developers working on things that produce business value, not struggling because they're waiting for a ticket to be closed or because this is the first time they've tried to do a particular thing and they're having to work it out. You want them to be able to just find a blueprint that they can copy, and the second, so, so there's business reasons for that. And then the second reason is about retention. Because honestly, if it is incredibly painful to do things, people aren't going to. You know, people will move on because of a bad developer experience
Chris:Welcome. You're listening to the DevX podcast, the show where product and engineering leaders share their thoughts and insights on developer experience. I'm Christian Weichel joined by my co-host Pauline Narvas..
Pauline:Hi Sarah. Welcome to DevX Pod. Thank you so much for joining us. We're super excited to have you on board.
Sarah:I'm really excited too. Thank you for inviting me.
Pauline:Can you tell us a bit about yourself and your career journey so far?
Sarah:Sure. I've been working in software development for about 20 years, and the last 11 years of that were at the Financial Times where I started as a tech lead as a software engineer doing Java development on the content platform. I was a principal engineer and then a tech director, and I worked in operations and instant management and engineering enablement as. And Thet is for anyone that doesn't know it's a business and financially focused global news organization. And I joined it just to, some big changes happened. Now there was one that was very business focused where the newsroom made a transition from thinking about the newspaper first to thinking about the website first. And that gave product technology a whole different set of challenges. Cause you need to be able to do really good product technology to make that work. And that came with. The technology organization making some pretty big changes as well. The FT moved to the cloud, we started building systems using microservices, and we had to really adopt a DevOps approach to support that. So it was a really great opportunity to learn a lot in quite a short space of time.
Chris:What was the motivation to build this out as microservices? Once product engineering got more attention?
Sarah:It's interesting. I think that, so we had three massive monolithic systems that were being rebuilt at the same time, and all three of them were rebuilt using M services architecture, which, you know, you could argue that's like a lot of learning happening in parallel. But I think that it all, it came from that idea of how do we move fast? And when I was first working at the ft, we released code for the content publishing and website 12 times. Because it was on a monolith you could only, you had to freeze the website. So people could still read d ft but they couldn't journalists couldn't publish news stories. So you had to do that on a Saturday where there isn't that much business news. You had to, it took a long time. There was a relational database, so 12 releases a year, and that means that you are, you really can't experiment. Because by the time that you've got something live, it's got lots of changes in so you don't really know which of those has moved any kind of metric. And so there was a real desire to be able to release lots of change quickly and to be able to get quick feedback and know whether we were going in the right direction. And that really worked. So we went to maybe 20 or 30,000 releases a year across the ft by the end of this. And for the teams that I worked on, we probably were doing 250 times as many releases as we were before we did that.
Chris:Awesome. If dome were your North Star you hit those for sure. Can you give us an impression on on the size, how many developers were there? How many services? Like how micro under microservices did you go?
Sarah:I'd say the was quite, has a lot of microservices compared to other organizations. For the content publishing platform that I worked on, we had got maybe 20 developers at that point and 150 microservices. So lots. And I'd say that across the whole of the ft there's that's a pretty standard thing, about a hundred to 150 for a system with five or six teams maybe working on it. I think that granular is quite challenging, but it did work for the FT to a large extent. Possibly more challenging for people who are trying to look across the organization as a whole when you've got several thousand services and there's quite a lot of difference between the ways people do things. It's hard to do anything central.
Chris:Yeah. If we look at this from different levels, so you know, you as an engineering manager and director level. And then sort of zooming down, starting from a director level sort of, and you just mentioned harmonization across teams and like not reinventing the wheel 20 times. What did that level of granularity, how did that interplay with also providing good. Perme permeability between the teams, you know, so a developer who move from one team to another wouldn't have to relearn the tools of the trade every time.
Sarah:It's, yeah. So I think I see this as there being a sort of pendulum where at one end you have complete standardization where everyone builds services exactly the same, and at the other end there's complete autonomy. You can choose whatever what you like. I think. The FT was, there was a lot of autonomy. I personally think that we probably, and we have slightly moved over towards more standardization for the reasons you said, you want to be able to move between teams. You want to be able to build tooling that all the teams can use. And if you've got multiple different programming languages, any of your central teams have to build multiple different language toolkits. So, By the time I left the FT there was pretty standard set of programming languages. No JS for anything that, that had a front end go largely for backend services and Python for a lot of infrastructure type services. And that, that helped quite a lot. And we try to, Standardize in other areas as well because you want to be able to build one tool that everyone can use and avoid having eight different teams having to do the same, how to solve the same problem.
Chris:How were those changes embedded in the organization? Who was driving that?
Sarah:Well, to a large extent I was tech director for engineering enablement. And so I was really interested in thinking about how do we support everybody that's doing product development? And I, and there's a constant debate about whether you whether you mandate things or, and how much freedom you give people. I quite like the idea that you. You pave the road and you provide a set of tools that make things easy, and if people choose to go off that paved road, there are certain guarantees that they have to do. So you want to bring something different in because it's not there available for you supported by a central team. Well, you are the one that's gonna have to make sure it's patched and updated, and if something goes wrong, you have to be available. Potentially outside of ours to support it. So you, you want to, because I think you have to allow people to say there's nothing here that solves the problem we have, but you have to have a mechanism for what's the expectation from them and how do you roll that back in at some point you're gonna say, well, yes, you've introduced a graph database because you have a problem where a graph is the sensible thing. How do we then make that into something that other. Can use. And that's not actually a real example because the FT had multiple different places using graph databases, but that kind of thing.
Chris:Yeah. This comes nicely hos back to a, an ongoing theme on this show. That is good developer experience is making it easy to do the right thing. Yes.
Sarah:Yes. So I think alongside that paved road and the idea that you can step off the road is guard rail. You want to make it really obvious to people what it means to do the right thing, and you want to help people not to make a costly mistake. I think that you should provide tools where if people follow your documentation or they or they use your tools, they should be able to easily build something that is secure and that's safe for them to use and doesn't bring them huge amounts of cost that surprises them. So having guardrails and having them built into. Every set of tools that you build so that people don't have to go and read all of the guardrails and do it themselves. I think that's quite important.
Chris:How would guardrails in a tool look like? Do you have an example?
Sarah:So we had a, an engineering checklist, which covered things that weren't just part of standard engineering software life cycle, but there were things that we wanted people to do. So, for example, we had a central system, which we call bi ops, that tracked our estate, tracked our software estate, and we always wanted to have every system. Entered into that, and one way to have, and so that's a guardrail. You should have a bizo entry for your system as soon as you start releasing code to production. But rather than making someone go and read that, you basically make it that you have to tag, if you're using aws, you have to tag the resource with a system. And we'll check that it's a valid system code and you can only get that system code if you have created at least a stub record in Bizos. And that that sort of unique system code is actually was actually just useful. So in so many different places, you just start using it everywhere You put it into your logs, you just find that gives you something that's really you can build on.
Chris:So from a. From a sort of across the organization perspective, hitting that trade off between standardization and freedom of movement. And one way to do that is using guardrails. If we sort of move one step down to say an EM engineering manager perspective, and also specifically looking at like the ratio was 150 services to 20 developers. Right? So there's like five to six services per developer. Roughly. Is that right?
Sarah:Yeah. Yes. I guess, I guess.
Chris:So that's makes four 30 services a team. What does that do to to the engineering manager? How can they provide or help their team be fast and have low, have high safety in what they do? Psychological, low change, failover rate? Well, what should they be optimizing for in such a.
Sarah:So I, I feel that so we didn't really have engineering managers. We had tech leads. And so they're really sort of, they're doing a bit of architecture and design as well as as people management. I think that the important thing actually was that. They, there's an understanding that you own the services that, that your team build. And if you are building 30 services to deliver the functionality that you're doing, you need to make sure that you have them documented in a way that anybody from the team would be able to find information that said, here's how I support it. So Expected there to be in, in this biz op tool that we'd built centrally that's there for you to go and document what is the architecture behind this is what's the failover, is how do you failover, are there troubleshooting steps? And just basically making sure that you have the ability to support it. And actually I think that you build it, you run it. Provide you with that framework as a, as an engineering manager or as a tech lead to understand whether you've given your team the right the right tools because, so, so an example for me would be we were building our first big system out of microservices, and we wanted to go live and we were gonna have to support it. And we talked to the, so I, as the principal engineer said, well, what. Do you, what do you as a team think about doing this? Doing out of our support? And what came up was we are using a data store that we don't really understand. It's too complicated for our need. We wanna swap it out for something else because we don't think that we could fix it at three in the morning. And so we scheduled that work and once we had done that, people felt more confident about their ability to solve a problem that might happen with that. With that. It's
Chris:When we think about developer experience, we usually think about the experience as we're writing code and as developers gain more and more responsibilities, arguably on call as part of experience. How would Onca look like in a five to six person team?
Sarah:This is a thing that was a big challenge. When we first started building microservice systems, we knew that they were complicated enough that we needed the teams that built them to be doing some level of support for them. But we also have a whole set of development teams that have never done out of our support, and I don't think you can run. An out of our support rotor with four or five people. I just, I think that's just not feasible. So there are a couple of things that you can do there. So you can first of all be really conscious of whether your system needs to be fixed out of hours. So we, at the FT we had different service levels and we would basically say, well this is one of our most important business critical brand critical systems. If this breaks we could be featured in some other newspaper, so those ones have to have 24 7 support. But there are others where honestly, it could wait until the development team is available the next day. So trying to make that judgment. So you're not trying to support everything, but you will have some that have to be supported and. Opted in the end for having, we had a first line operations team that could do triage and follow troubleshooting steps and do failovers and use whatever resilience was built in to keep something going out of ours. So, We had that and we, the message to people was if it's okay and you can wait until normal working hours, when there are more people around to help you fix it, that's fine. So failover, leave it till the next morning and then work out why a particular region wasn't working. So it's building it with resilience, so it's across multiple regions and it's having mechanisms that are relatively straightforward to do that failover, and then being okay with leaving that until the next day. So, so that was one aspect. The other thing that we had was that we didn't, A formal on call from those development teams, we did best endeavors. So the people that were happy to be on a list would basically not have to not, they wouldn't have to like change their life. So our first line operations team would go through a spreadsheet and they would call different engineers until they got someone who was. And there's obviously a risk that no one's ever, no one's available. But that didn't happen. We always managed to find someone who was available who could help out, or we managed to follow the troubleshooting steps and get ourselves to a point where we could. Surviving to the next day. So I think it's about being very pragmatic about what should you expect? And being willing to accept a level of risk. Because the alternative is you have to staff up to the point where you can do that support and you have to pay people to be on call. And that's a very different that's a very different thing. And for me personally, I wouldn't have wanted to be spending every fourth or fifth week, you know, basically on call every. I'd much rather that my name is on a list and you call me, and if I can I help.
Chris:How does that align with the specialization of teams? You know, given that a team is reasonably small not everyone's on that list. So you have, say two, three people from a team, none of them is available. How does the neighboring team know what to do? So
Sarah:the major the main systems that are really business critical, you've generally got more than one team working in that. So you say ft.com, you've got six or seven teams there who may all be working on slightly different parts of it, but they understand that system architecture, or at least they can find the documentation and find the logs and be able to work out what's going on. So that was the general approach. There are occasional, there were places where we had teams that built something that was business critical, where we didn't have that many people. You really invested in resilience. For those, and that's a across multiple different levels. So for example, the team that built the, this, that central bi op system, there's only five developers with that. But that's actually pretty crucial because if you, if anything else breaks and you can't get into that and find the information, so we had the, this was based on a graph database but we didn't really want to have a graph database deployed across two. So there were regular exports of the content to S3 files, so you could fall back to something that was probably half a day old that, that was, that give you the critical information. Then after we had a problem with our single sign on, which meant we couldn't access the S3 files, we introduced a third level, which was zipped up and stuck in a Google. Because that's another thing we have. So it's having that redundancy and being okay with it, and knowing that you've got several different places that, that you can go to. So you just build things in a quite resilient way. And I, and actually the other thing is sometimes you accept that there's something happening where you're gonna take a while to work out what's going on.
Pauline:Sarah, one of our favorite questions to ask guests is, what is developer experience to you and how would you define it?
Sarah:I think it's really interesting that I hear lots of terms that feel really like they overlap a bit. So developer experience, developer productivity, engineering enablement., I think developer experience is user experience, but where the users are developers. So can a developer achieve the goal they have in mind with a minimum of friction and in a way that provides them with guardrails so that they don't make unnecessary mistakes. So, you know, making sure that they're not making something, building something that's insecure. And I think there are a couple of reasons why that developer experience really matters. So firstly, you want. To have your developers working on things that produce business value, not struggling because they're waiting for a ticket to be closed or because this is the first time they've tried to do a particular thing and they're having to work it out. You want them to be able to just find a blueprint that they can copy, and the second, so, so there's business reasons for that. And then the second reason is about retention. Because honestly, if it is incredibly painful to do things, people aren't going to. You know, people will move on because of a bad developer experience. So it's good to have something that, that people can make progress. It's good for the company in lots of different ways. I
Pauline:really like how you mentioned retention. I don't think anyone I, we've asked mentioned that, but it is super important. I relate to it from a former team where I saw engineers slowly drop off just because the development experience that they were. Experiencing daily just was too painful and it was just too much manual work, or it just caused a lot of friction. And they were like, you know what? I will find a better place to work
Sarah:So the other thing that happens, either people leave or they find a way to work around it. So the example when I first moved, first worked at the FT was we had a very intricate piece of software for doing builds and deploys, and it was incredibly powerful and it'd be heavily customized. And there were various gates where someone had to sign something off. So what actually happened was pretty much every development team had a box somewhere that was running Jenkins. Because you are motivated to get quick feedback and this is what happens. People either leave or they work around your systems and they find a way to do what they want to do without jumping through your process. So you should work out how you should find the places where people have found a better way to do it and learn from that and think, oh yeah, this is clearly a problem area. We can do better.
Chris:Yeah, I think there are really two two key ways, like two extremes, how you can build. Developer experience and you always have developer experience much like architecture. No matter if you designed for it or not, you have it. Yes. You might not be aware and designing or having developer experience. I think there are two ways to do that. One is it's analogous to designing a park., you know, you start with a green field and you can pour concrete paths and expect people to walk that way and they'll still walk the way they wanna walk. And so you'll get these brown tracks across that nice field of lawn. If instead you started with the green field, you look where people walked and then poured concrete, you'd end up with a much more efficient system and. Guardrails come back into into play here. You know, there might be a sinkhole somewhere and you don't want people to fall in there. So you're gonna put guardrails around. How do you navigate sort of this spectrum of prescription and freedom?
Sarah:It's so, I love, I mean, I love the idea, I think the Japanese call them desire paths. It's like you, the idea is that you let you find where people want to go, and then you turn it into a path. I think that's, you do wanna be doing that, but that means you need to be talking to your users. And actually you need to have a really product, a product mindset about this. And you need to not just build something, you need to build it, watch people use it, and then iterate because there is, there's quite often a sense that people go, here is this tool, and they send out an email and then that's it. You never hit anything more about it. But actually you need to have, you need to assign some time in the follow up, the following months. To go around and make it better, and you need to actually think about, how can I promote this all the time? I always felt at the FT that when I started seeing people who weren't in my team sharing links to one of our tools when someone asked a question, so someone would ask a question and there'd be an answer from a developer from a totally different point of the organi part of the organization saying, here's where the answer is. You know that you've managed to like so socialize that this thing exists and it's. So I do think you need to be thinking about about things from like, you're building a product and you are talking to your users and you are actually paying attention to what people need rather than what they, what you think they need. Or maybe if you have a very open ended thing what could we build for you? You don't necessarily get at the things that are really taking time for people. You should look at what people are doing and where they're getting stuck,
Chris:which is a great segue to continue our journey sort of down the organization or organogram towards developers. What have you found developers need and get stuck with most when it comes to, when they're living in a very distributed microservice world?
Sarah:So I think developers also, there's an element where someone gets frustrated because there isn't a good solution to this thing, so they adopt something else. So they go off the road and then six months, a year later they've moved on and now there are other developers who are stuck there maintaining this thing. So I think spotting where you. As a central team, take something on or build something else is good. Because really, like, so as a developer, I used to hate it when I got stuck waiting for something. And the anything that just removes that sense of, well, I have to wait until someone does this ticket. And even if it only. A short amount of time you move on to something else, and you've totally lost the context of what you were doing. So, oh, years ago at the ft you could I could spin up a new vm, but I needed to get what we had integration engineers. I had to get an integration engineer to set up access so that I could then deploy my code to it. That's just enough friction for me to go off and start doing something else, and then I may just forget that I was in the middle of doing this thing. So I just, I think looking for the points where there's like a kind of friction where you're waiting for someone to do something is a good thing. I always thought that it was worth spending time on things that feel like. Like they're boring, repetitive jobs because it just makes everyone's life a lot nicer if you don't have to do that. So, and you can always do, you can often improve things with a small amount of work. So you feel like you're making continual progress towards a better experience for people. Whereas, you know, other, there are other things you need to build that could take a long time. As
Chris:a central team, how would you go about identifying. Places of big, of leverage.
Sarah:Well, I mean, you do send out, you can send out surveys to people, send out questionnaires. We also tried to attend the developer huddles that other groups had. So if you can go to the engineering huddle and hear the problems people are talking about, you've got a good chance of thinking, would you know what? We actually have a solution for that you just don't know. or, oh, that should go straight onto our back there, our backlog. I would also spend quite a bit of time in various Slack channels, just seeing what are people complaining about. And I've joked in the past that one metric is, you know, are we gonna reduce the number of complaints in Slack about this technology? Because we've, we saw that, we've seen that in, I've seen that in my teams where we've invested in doing something to make it easier to use particular infrastructure. You just get people not spending their time going, oh, I've gotta wait for this thing to happen.
Chris:And how was your product management organized more concretely? You mentioned earlier that you'll wanna look at development experience really as a product. I very much agree with that. How would you involve product management? Literal product management, in developer experience?
Sarah:So we had a lot of conversa. I had a lot of conversation about this with some of my principal engineers, cuz we didn't have product in the engineering enablement team when I was there.. And that was partly a question of resourcing in that did I want to swap a lose a principal engineer to get someone in for product? And it was partly that I feel you want a pretty technical product manager in that role, and I was hoping that I would be recruiting principal engineers who could do that. Hm. Who could, who could really understand their their clients and think with a product view. It. I felt that we didn't need to have separate product. I know that other people felt it would've been a benefit and I know that for example, at gds, they had product managers in the central engineering enablement groups. So I think you go, you can go either way, but what you do need is someone who's going to be able to understand the problems that developers are experiencing, which usually means someone who has been an engineer in the.
Chris:Yeah. Specifically the technical focus really rings close to home here.
Sarah:Well I think I learned this a little bit while working on doing API development, which is that that you, at one point we were defining user stories around building some things into the api and we had a business analyst who would try and convert everything into a very English. English wording, but I feel like a developer understands what returning a 4 0 4 means and actually con converting that into something else is less precise. So I want my user story to say it will return a 4 0 4 or it will return a 400 or a 500, and actually expect that the developers understand what that means and not try and and.
Chris:A good part of the developer experience plays on two main loops. You have the outer loop and you have the inner loop, outer loop being your ability to actually impact product changes and you know, experiment. Exactly. The motivation and how you go towards microservices. In a loop. Making changes and testing them quickly in microservices where you end up with a very large sort of surface of services that need to interplay. How, what have you found are the challenges around in a loop?
Sarah:I, so I think that there is a, yes. I think it's very different. It's very different trying to do that in a loop in microservices. And actually there's a lot. Learning a better way to do it. So one early example for from when I was working on the content platform was we had, we built a set of acceptance tests using b d D. And so we had individual microservices that we do, we'd test at the boundaries. So it would be unit tests, pretty much, and then we'd have acceptance tests. But we were setting up fixtures for them. And what we found is we got to the point. You could make a co change in half an hour and then it could take you a week to fix the acceptance tests and effectively acceptance tests, which had been really good practice in a monolithic system The way we were doing them, because we were setting up fixtures in all of the different data stores they, they turned our system into distributed monolith. It meant you were changing lots of different places at the same time. So we moved away from that and we moved towards. End to end tests that, that treated a lot of things as a black box. It was, and we mostly ran them in production. We did synthetic monitoring. So the example we had was we want to know whether you can publish an article. So what we do is we publish an old article every minute or every five minutes and check that it's updated on the website or it's updated through the api. So you can do that because. Publishing is item potent. You can publish it again and again. And we would just check the time stamp. And that was much easier to maintain and caught the large majority of the issues that the, those acceptance tests would've caught. But it was working out that we were, that the pain, we were feeling meant we should change how we approached it. Rather than that we could do that better. We tried to do it better for ages and then someone said, why don't we just turn them off? Cause. We all hate them. and they take extras.. Chris: Yeah. Building, removing, building back is difficult. Often harder than adding. It's true. And also you just have things, you know, you have things, you know, as a developer and it's really hard when that changes. So don't repeat. The idea of dry, don't repeat yourself. So when we first started building a microservice, we build a microservices architecture. We thought, oh, we'll have we'll have a library that defines what content looks like. So a piece of content has a headline and it has a byline and it has various other things. And we'll use that same model every. What that does is exactly the same problem. It couples everything together. You want to change that model, you've now got to update that library in all the places. So we moved away from that and we did repeat ourselves. We basically had every service would read in some content and expect just the fields. It would only look for the fields it cared about. So you could add new fields, you could remove other fields, and if that service didn't care about them, wouldn't be affected. So, so learning that, don't repeat yourself in a microservices architecture can lead you into the. The wrong approaches, you're better off repeating yourself unless you've got something that's incredibly stable and unlikely to change. So the place where libraries are good is where you've got something that you've pretty much solved the problem. So, for example we need to pass transaction IDs. So we pretty quickly built a library for minting unique transaction ideas if there wasn't one already on the request, or writing and writing into logs, that didn't change in years, and we could just use that library in every service.
Pauline:Awesome. I just wanted to move on actually because Sarah, you're writing an O'Reilly book called Enabling Microservice Success. Could you tell us a bit about that? I'm guessing your inspiration came from all of the things you've been learning at ft when you were there. Could you tell us a bit about that and what we should be looking forward to?
Sarah:Yeah, it's absolutely, I spent a long time building microservices at the fte, so eight years, and that means that I could see what caused problems, we could try a solution, and I. Could see whether that actually worked. So in some cases we drive more than one solution.
Pauline:So I think there's that length of time. And also, you know, you start to get to the point where now the microservices are almost your legacy system. They've been around for a long time and microservices. Can be really effective for speeding up delivery of value. But you have to get the culture right. There are organizational culture changes. It's not just a technical change. You need to get to the point where you really can support autonomous teams. And I wanted to talk about what you have to do to make that work and give practical advice and try and. Show people how they can avoid getting several years in and just finding, they have a lot of accidental complexity where they're spending time on things that aren't providing business value and they're finding it really frustrating.
Sarah:And it's a lot of that comes back to where's the balance between standardization and autonomy and investing in removing that friction. So it does come back to that developer experience you want to build. Things to help everybody that's building microservices that are a joy for developers to use the solve a problem they actually have and where they will totally adopt it.
Pauline:And when is the book coming out? When can we expect
Sarah:this? Oh, well, I'm in the middle of writing it. I think probably. Q2 next year. Oh, it'll be available. It'll be available earlier on the O'Reilly Learning platform. So if anyone's got access to that, there's already a couple of chapters, chapters up, and I think obviously the ebook probably comes out before the paper. The physical. Yeah, I'm kind of in the middle of it at the moment. I just feel like I spent all my time thinking about how I'm gonna approach topics.
Pauline:No, it sounds like super practical and definitely something I'm sure a lot of people need to read and hear from someone who has the experience.
Sarah:Yeah, I hope people will find it useful. I think there's a lot to be said for having con consistent experience at one place of trying to do something that's a, that's something that can be useful. Definitely.
Pauline:Absolutely. Awesome. Well, we're actually at the end of our podcast, Sarah, and that was, that flew by and I feel like I'm still digesting all the discussions that we've had. But what we usually do at the end of our episodes is we ask our guests one thing they'd like to shout out about recently. So this could be like a recent learning, someone who impacted you and can be tech or non-tech related. So over to you, you can use this space to share.
Sarah:Great. So one thing about writing a book is that you end up going back to the source material because you're basically thinking, if I haven't understood what this means, then it's is in writing forever. So that meant that I've been talking about Convoys law for a long time, but I went back and read the original paper. And it's not very long. It's 45 paragraphs. It's over 50 years old and it's still totally relevant and so I really recommend, I recommend reading it. What I really liked is beyond the main point that organizations design systems that mirror the organization's communication structure, you ship your organization. There's another interesting point he makes, which is that we almost never get a system design right first time. So you need an organization. Is flexible and can be changed. You can change your structure as you discover more about the system you're trying to build. And I don't think people necessarily think about that. We talk about reverse, the reverse Conway Maneuver, the inverse Con Conway maneuver, where you build the organization that's gonna let you build the system. Well that's unlikely to work. You're gonna have to change it as you discover more about this system that you're trying to build. So I think that's really interesting I highly re.
Chris:That's super interesting. ARD, when we started to grow, we did exactly that, the inverse Conway maneuver and built our initial organizational structure out of the architecture our system had at the time and have since tried to evolve along. So I think if you make that inverse maneuver and you go, all right, this is set in stone. This will pass the test of time. Your info rough. If you acknowledge that things will change, no conditions are permanent you might be onto something.
Pauline:For my shout out this week is I recently re started rereading one of my favorite books. And it's interesting because it's a book I read a couple of years ago when I was still. Lacking a lot of experience in working in tech. But now I've got a few experience, a few years under my belt. It's been interesting to reread. So the book is called, start With Why, how Greatly does Inspire Everyone to take action by Simon Sin Sinek, I think is how you pronounce his last name. And he basically talks about why some people and organizations are. Innovative and more influential than others. And some of the like the key concepts and it all converges to the fact that they are so, they understand so well their why. And it actually helped me reflect, take a step back and be like, what is my why? What is my team's? Why, what is GI pod's? Why? And it's been really interesting to read and reapply from a different perspective. Cuz I read it a couple of years ago. I didn't really have much experience. So that is my recommendation. This for this episode is such a good book. Really, like, really enjoy it. There's also a TED Talk if you would prefer to listen to him speak. It's a good book. Yeah. That's my recommendation. How about you, Chris. Chris: I'll also plug a book to me by a colleague that is how to measure anything., there's a subtitle Finding the Value in Intangibles in Business. It does away with the notion that there are things that we just can't measure, like developer experience or the value that we produce or that a team produces or that an organization produces. And so it gives you a good intuition for how to quantify things that might otherwise seem intangible.
Sarah:Yeah, I can actually relate
Pauline:to that. Cause I've been thinking from a community standpoint how can we measure community more effectively and what's the metrics of community? But it's very difficult to, because community is. By definition, this isn't a podcast by community. I could talk about that for ages, but the relationships between people. How do you measure that? How do you scale that? And things like that. So that sounds like a super interesting book. Thank you both for your recommendations. I will add that to our show notes for people to look into. And lastly, Sarah, where can people find you if they wanna find out more about your book and keep updated with what you're up?
Sarah:I'm on Twitter still at the moment anyway and I am on LinkedIn and I really should get a website sorted out basically, but you could find me on LinkedIn and probably on Twitter for a while depending on exactly what happens.
Pauline:It's been an amazing conversation. I really enjoyed this episode and can't wait for people to hear it. Thanks for joining!
Sarah:Thank you so much for inviting me. I've really enjoyed it. Yeah.
Chris:Thank you for being with us. This was great fun
Pauline:Thank you for listening to this episode of DevX pod. Want to continue the conversation about developer experience? Head over to our community Discord at gitpod.io/chat. We have a dedicated channel there for us to talk all about DevEx.
Chris:To make sure you don't miss the next episode followers on your favorite podcast platform or subscribe to our newsletter DevEx Digest. You can also find out more about Gitpod on Gitpod.io. Start a new workspace and tell us about your developer experience. See you in the next episode..