Transcript
00:00:01: Welcome to a new conversation about software engineering today with Sarah Wells.
00:00:07: Very nice to have you on the show, hi Sarah!
00:00:11: Hi there thank-you for watching me.
00:00:14: Yeah um Sarah is an independent consultant who used work as technical director right?
00:00:21: For financial times
00:00:23: yes
00:00:25: I worked for the Finanzielle Dachblatt, which is kind of same thing in The Netherlands.
00:00:29: So that's why it was always a bit alert when i saw your talks because you're prolific speaker at high profile conferences... ...I would say Cucon London go to Copenhagen KraftConf in Budapest Liebdev everywhere where its cool You are there.
00:00:52: And also the author of The Book Enabling Microservice Success, where I thought when we talked about it a couple minutes ago yet another book about microservice.
00:01:07: Then I bought it accidentally actually because it was part of humble bundle And for some reason, I had to check something.
00:01:17: It was like maybe it's in the book.
00:01:19: and then you know... ...I read in a book that this is really cool.
00:01:22: so we have to talk.
00:01:24: Excellent!
00:01:27: All right yeah i prepared an outline but last week.. ..i had conversation with Birgitta Bökela who is distinguished engineer at ThoughtWorks.
00:01:39: We talked about Retreat & Utah Future of Software Engineering.
00:01:45: And now you know, I have to address immediately when we talk about... Oh!
00:01:51: ...I didn't say what they did not want us to talk.
00:01:54: We will talk about technology governance and maybe a bit of technology strategy?
00:02:00: It is also part in your book.
00:02:02: so again highly recommended.
00:02:06: buy it.
00:02:09: but one thing When you approach new technologies usually slow We can talk about it, but right now is like a flood of new tools.
00:02:19: So how do you deal with all those new incoming AI tools?
00:02:26: I
00:02:27: think that's the real challenge because there are all these tools and everybody's scared of missing out in companies doing.
00:02:38: we need to get the right tool or using it from the people that are building a i tools so they're getting them out there as quickly as possible.
00:02:46: So I don't think you can rely on the fact that they have really thought deeply about, what is security of this thing?
00:02:53: You know it's not.
00:02:55: a lot of him say he got a couple things where everyone trying to rush and yet these are tools that have access too.
00:03:02: The crown jewels of your data like two work.
00:03:06: they need access to all.
00:03:07: if information at you half.
00:03:09: So if things go wrong, that's absolutely terrifying.
00:03:12: And there was an incident in the last half of last year where a AI tool integrated with Salesforce called Drift got compromised and effectively.
00:03:26: people's Salesforce instances were having lots of data exported.
00:03:31: That is really quite terrifying but it's very valuable tool for people who have a widget on their website to allow them book calls in to talk about buying software.
00:03:44: And I had an impact on people's bottom line, so you've got try and find a way not stop people from getting the advantage.
00:03:56: that might be quite big business advantage?
00:04:07: brought in to the company so that at least you're saying, well here's the data flows.
00:04:11: Here is a data thats gonna be used by this understanding where it fits into your system and say what we can do.
00:04:18: try make sure were protected as possible?
00:04:22: So questions are asked for person people buying from or integrating them with your company.
00:04:34: Looking at development tools.
00:04:37: So right now there
00:04:38: is the same thing with developers, so you still should be thinking of these?
00:04:41: Is this a tool that we should be using?
00:04:43: do We have our contracts With this company?
00:04:45: are they?
00:04:46: are we sending out their data while they're using it for training?
00:04:48: all Of those things as well?
00:04:50: Developers aren't thinking this.
00:04:51: most many developers Are using AI tools.
00:04:55: did not They use in their personal accounts?
00:04:58: So companies don't even know what tools developers are using in their organization.
00:05:06: As an organisation, you probably want to try and work out what's being used by someone in your company?
00:05:14: I recently had a conversation with AI strategist or whatever that means And I was surprised that, i think it was the second thing he was mentioning.
00:05:24: Was the shadow IT problem with AI?
00:05:28: because everyone is building certain tools for themselves or like you say they use it with a private account.
00:05:36: also With one of my customers ,I was really shocked That they cannot even tell what their doing but its reckless.
00:05:46: It's a bit scary.
00:05:48: It's just making easy, much easier to do things that people might have done in the past.
00:05:54: where they're like I've worked at organizations pre AI were developer with a credit card could go and buy tool start using it.
00:06:00: And you had no kind of contract without company or any real knowledge centrally that your organization was using this tool.
00:06:09: we would sometimes how people get in touch with us if he said did you know what?
00:06:13: You got ten people is in the store.
00:06:18: Maybe not.
00:06:21: I think AI tools and the fact that everyone can just be using it, one thing you could do is to be very clear about what your policies are around AI use.
00:06:31: so i have worked with a client who basically said okay we really want some benefit from AI but we're going to... You can use these tools And the mechanisms for adding other tools Is like this And we expect you to only use the tools that have been approved.
00:06:49: Or if you want something else, tell us about it and at least then people kind of gonna pause a bit because they're going think well If I don't follow this policy i'm actually.
00:06:59: This is potentially A serious issue for me.
00:07:04: You know It's like its basically part.
00:07:06: The things you sign up say I will follow these policies.
00:07:09: It's not exciting to say that, but I think for this organization you always want to be clear with governance.
00:07:14: What are you expecting from people?
00:07:16: Like what do you... If you tell people what is fine and what isn't fine then there's no kind of.. There's no ability to say oh i didn't realize I couldn't just start using this tool.
00:07:29: Yeah yeah You know, what I found interesting in your book was you had this tech governance group.
00:07:40: And uh...I was like oh we should try this at the company that i work for and clients with.
00:07:48: but before we talk about this Tech Governance Group how do i come to?
00:07:56: How can a strategically come up with let's say technology selection?
00:08:04: How would I do that?
00:08:05: You mean just as a like in an organization.
00:08:10: Yeah, so for example it's in your book yours i think you was on your book and all you were mentioning what the mapping is.
00:08:22: one thing but there probably also others.
00:08:25: something to start with this problem.
00:08:32: Is this something that we should build or could be buy it?
00:08:36: And where Wardley-Mackin comes in the idea, you really should be investing your time as a technology team building things that are differentiated for business.
00:08:46: Things your customers care about and this is something.
00:08:49: when I was at the FT, It was pretty interesting because everyone's autonomous never all wants to build things themselves.
00:08:58: so we had two teams were building a Kubernetes platform.
00:09:01: Not one, two different.
00:09:02: But it wasn't for everybody.
00:09:04: other people were using different things.
00:09:06: this is great but its not the business of financial times.
00:09:08: that's not a container orchestration company.
00:09:12: so you really should be spending time building these things about your business and differentiates from now might be.
00:09:21: there isn't anything to buy will give particular benefit hosting or something like that.
00:09:29: eventually You get to the point where those things that you're building on top of become products, they became commodities.
00:09:39: So it started out.
00:09:40: everyone built was starting to use Docker and were building their own container orchestration.
00:09:45: then Kubernetes came along than gradually people are doing.
00:09:48: manage Kubernetes is for you?
00:09:50: And so it becomes something where you might still want to build yourself a platform but actually maybe better off getting someone else.
00:09:59: So, focusing on the new things that you build and places where you try innovative technologies are really critical to as a company because there's much more risk when trying something people haven't used before.
00:10:17: I think it is decade old but the idea of boring technology that Dan McKinney wrote about which was such great article in conference talk and so many bits to it, but I love the innovation tokens.
00:10:31: The idea that you can have choose which bits where you use your innovation?
00:10:37: You don't have the ability to innovate in five different places at the same time.
00:10:44: So choose a boring technology...I like if i run...you know..i'm usually running the software at developed credits junior developers who want to use the hottest stuff.
00:11:00: So I would agree, you know we should use boring technology at least if other people have tried it and it works then its great.
00:11:10: but i'm not saying that.
00:11:13: so there is got be space.
00:11:15: try new things.
00:11:17: We're still like I used to write EJBs.
00:11:20: We're not still building Java systems using EJPs.
00:11:24: You move on and so having the ability to say, you know what?
00:11:26: There's this new thing that looks really cool.
00:11:29: it might solve our problem much more quickly.
00:11:31: It is something worth looking at but you just have try find ways for people out without going full scale into some new technology And knowing how its gonna work.
00:11:47: But when we see your want people to go into neutral technology.
00:11:52: I mean, if you want to try out... You don't really know in the beginning how it's going to work do you?
00:11:58: No!
00:11:58: What i think is for the space recognising when somethings starting against playwork could be useful for us.
00:12:06: so maybe its not bleeding edge anymore.
00:12:09: they have to be quite comfortable with leading-edge stuff.
00:12:11: So someone would say hey this sounds good and actually my team used day where you could effectively try the thing that you liked.
00:12:21: And we'd say, well it needs to be something that is relevant for us and can help us and have them present back.
00:12:28: You've just said what your going to investigate.
00:12:29: then they will come up with a new technology which I think was really fantastic when spending time on it.
00:12:36: but sometimes this is good because more often than not Yeah, once I actually tried to do something with it.
00:12:45: It didn't work quite the way that i was hoping and concluded its not gonna be in future.
00:12:52: yeah we have that but very often this tool is so cool.
00:12:57: now the new AI whatever tools right?
00:13:03: The new spec driven thing.
00:13:08: of course if you play arounds it might be cool.
00:13:12: But then the question is also, yeah you are in soothiastic but...
00:13:16: Yeah that's where It was good when you're doing it in a context of real problem.
00:13:22: Something will solve your problem our team is facing right now and there were some nice constraints on this.
00:13:28: we want to see what would fit?
00:13:31: Ah okay.
00:13:33: That helps!
00:13:36: You mentioned innovation tokens by accident one of my co-hosts here, Alex Hoysigfeld.
00:13:43: He also once wrote an article about innovation tokens but maybe not everyone knows what the innovation tokens are?
00:13:50: Yeah so it comes from Dan McKinney.
00:13:56: Let's imagine you've got three tokens that you can spend on innovation.
00:13:59: What're gonna spend them?
00:14:00: like?
00:14:01: You probably want to spend them on things most valuable for your business.
00:14:05: You don't wanna build a time series database for your observability system.
00:14:13: People who are enthusiastic engineers will often suggest things like that, I had a team that wanted to build CI CD using serverless components and it's like well okay you could build something that is amazing but isn't going be so much more amazing than its gonna transform our business in any way?
00:14:30: or is it gonna five percent better then what we can just buy?
00:14:36: So the idea is that you don't try and do very innovative things too many at the same time, because actually it's risky.
00:14:44: It takes a bit more time.
00:14:45: It has a lot of mental capacity.
00:14:52: You just have to not take on too much.
00:14:55: And how do you choose the amount of tokens?
00:14:59: I mean...you said three tokens for one team per year!
00:15:06: time, you really ought to be only really thinking about doing one thing.
00:15:12: Having said that I worked on a team where we switched programming language graph database and hosting platform at the same time And we succeeded!
00:15:20: All of those things were quite new.
00:15:22: so there's always a case for thinking maybe this will work for us but yeah i think and everything else you want to be quite predictable, then you understand it.
00:15:36: And we know how to do this just because It's hard to learn many things at the same time.
00:15:47: Yeah I mean last week with Brigitte We had also a problem.
00:15:52: So many new tools in AI space You have to break and start slowly For a certain amount of time, people were always talking about yeah we just use the best tool for the job.
00:16:11: Right?
00:16:12: And I was also in at a company they said used to Best Tool for The Job and it did sound good... In the beginning but very quickly i thought this is the worst idea ive ever experienced.
00:16:27: So when you say that stills your job are you saying anybody chooses different?
00:16:33: Exactly,
00:16:33: it was just too many technologies.
00:16:38: We had ten teams and eight different pipeline technology something like that.
00:16:46: And the question is how do I balance?
00:16:50: How would you balance this?
00:16:51: You need governance right.
00:16:53: so to in order.
00:16:54: Yeah
00:16:55: definitely i think I've been in that organization.
00:16:59: You know, i've been In a place where we had three of everything and it's costly in A lot Of ways.
00:17:05: you can't for example?
00:17:07: And really build common capabilities if there are Three different programming languages and five different databases.
00:17:13: So I think you just have to be clear about what is the standard set of technologies That you should reach For most cases.
00:17:26: make the decision that you need something different in this particular case.
00:17:30: So there will be cases where we basically go, I need a different kind of database than the ones were using elsewhere and here are the reasons why this is important because... so it's going back a long time.
00:17:42: but at the top- There was point at the FT where every- We're reusing relational databases.
00:17:46: But we would building some thing when wanted to model metadata about articles And its graph.
00:17:53: And it is so much easier to build software about metadata when you use a graph database than it is.
00:18:01: just stick into relational.
00:18:03: It's just, it just fits the problem space.
00:18:07: So I would have said in that case You absolutely do want to choose The best tool for the job there because its gonna make such A big difference.
00:18:16: But i think There are other places where it's not.
00:18:22: It comes back to that business differentiator thing, so at one point I discovered we had a team of FD that were sending their logs too completely different logging stack and i found this out during an incident where I couldn't see the logs from this team because it wasn't in the standard login stack as they decided to send them somewhere else.
00:18:39: So there are generally places you need actually get a lot benefit for being on single type technology.
00:18:50: Yeah,
00:18:54: interesting that you say that because my uh You said you have to think about how many technologies.
00:19:00: You want to support.
00:19:02: so I once was part of a platform team and we provided service templates And the problem is of course if you only have Java for example It's easy but we had four different stacks And then you basically can't, right?
00:19:22: So we just say well... We support Java and we support this and that.
00:19:26: The rest is bad luck!
00:19:28: I thought until you mentioned it Well, it's fine to give people some choices in terms of technology because there was a couple of teams they hated Java.
00:19:42: They wanted to do NodeJS and others hated Java and they want you two go?
00:19:48: And we were like okay if you hate it then I mean whatever.
00:19:53: hating the technology means well three technologies is
00:19:57: fine.".
00:19:58: Then another one who said oh he can only work with Python And we cannot use Kubernetes.
00:20:05: We have to use serverless, which you know... ...we just let it happen but there is basically no business need for it.
00:20:18: It was people like it and that's the reason why they give them more freedom and think well okay!
00:20:28: We don't want force into something.
00:20:32: I think programming language is really difficult to have too many of.
00:20:38: So, people are using Node for front-end and they're using Go or Java back end but once you have both Go and Java... You started thinking why can't we just make things a lot?
00:20:54: It means that your platform team could build tooling, and they can build your libraries.
00:20:59: And then you do all of these things.
00:21:00: that would speed up.
00:21:01: it's one thing is really interesting about AI though.
00:21:06: his platform teams have this idea that you're paving the road in.
00:21:12: people will stick on their common set of things that you've suggested because painful to go off into another way like be I did oh yeah use our paved road and you don't.
00:21:24: You don't have to be doing all the upgrades and you don't know how do we be doing this stuff or.
00:21:29: It's gonna interesting for me when anyone can go away and use useful code to write, right?
00:21:36: The version of a library in their language whatever quite quickly in theory does that does not pain work anymore doesn't keep people on the page.
00:21:44: road would get even more than explosion if I've decided i'm going to write this in ruby because i like Ruby.
00:21:52: yeah not sure.
00:21:58: So I think you don't want to stop people from trying new things, but also put a little bit of friction in the way.
00:22:08: You said earlier we talked about tech governance group and one thing that I liked is this approach where you come up with something like significant technology choices create a two-page document to explain, this is the problem we've got.
00:22:31: Here are other things that were considered.
00:22:33: one of them always had to be doing nothing.
00:22:36: what's the situation if you do nothing?
00:22:38: And it was amazing how often I would say people can try new technology but have come to tech governance group and fill out page.
00:22:45: they'd been like oh!
00:22:47: It just wouldn't happen.
00:22:48: there weren't two-paged documents.
00:22:50: so use the technologies really wanted.
00:22:51: Yeah,
00:22:55: I think you know...I love the idea of the TGG.
00:23:06: But maybe you can dive a little bit deeper into the tech governance group, forum and process.
00:23:14: what's in this document that was described?
00:23:17: because it is interesting for everyone And it's also a bit stolen.
00:23:22: I must make some other, let's say advertisement for books... Some parts are stolen from Andrew Hamill Laws' book?
00:23:31: No because he'd wait before his book!
00:23:33: Oh it was BEFORE HIS
00:23:34: BOOK?!
00:23:35: Okay okay nice yeah
00:23:39: yeah Yeah you also
00:23:41: made the foreword right?
00:23:44: To be honest we did borrow our ideas from other people.
00:23:49: We learned from people who were doing architectural decision records, we learn from people that are using RFCs.
00:23:55: like my colleague Rob Godfrey did a lot of the work in defining this but it basically said...we want to have a useful forum where you can talk about architectural decisions and have a record with all those decisions made.
00:24:07: also make sure everyone understands why they're happening.
00:24:10: so had an RFC style document that you had to fill out, they said okay here's the problem.
00:24:17: Here is why we're choosing this and um.
00:24:21: The important thing was if he were bringing something to a group it would be your job.
00:24:26: go around And get consensus before Um Before the meeting.
00:24:31: so actually all of work happened.
00:24:33: pretty much before the meeting You'd talk with anyone who... This where Andrews book is brilliant.
00:24:38: It says workout whose affected by decision Workout has useful knowledge that can fit into this decision.
00:24:48: So you would go and talk to those people.
00:24:49: naturally, you talked with the people who've got opinions... And by the time we get our meeting in theory everyone has been consulted.
00:25:02: they have looked at the document made comments.
00:25:04: there's been some iterations.
00:25:05: so generally it was a final tidying up on communication of.
00:25:11: one of my principal engineers came came to me for the first time and said, but it just felt like you were just announcing a decision.
00:25:17: It's all work happens beforehand.
00:25:21: that meeting is about communication because once the pandemic started we said any engineer who wants us come along until they meet could come in.
00:25:29: We'd have fifty or sixty people joining the call here talking about architectural decisions
00:25:41: You said previously writing this document which already was a barrier or too much friction for lot of people.
00:25:52: Why is that?
00:25:52: I mean, you see the technology and then think oh yeah!
00:25:59: This sounds cool.
00:26:00: let's do it without even thinking about why we need it.
00:26:04: how does it cost what benefits to bring?
00:26:10: naturally very enthusiastic about new technology.
00:26:13: We all love to learn and there is a little bit of friction than being asked, well what problem it's solving?
00:26:20: And sometimes people just don't even do not want be having make that case.
00:26:25: I think this is good fiction.
00:26:27: go around try in your own time build things with if you wanted but if you're going introduce into the organization where they could then I really want to have a sense that we've thought about it and considered the alternatives.
00:26:50: Every organization's got the equivalent of, this test suite is written in Scala because an engineer who was here five years ago loved Scala!
00:26:59: Yeah but i still think its so hard to control right?
00:27:05: The client I was talking about... We though we had four languages But then it turned out there are many more languages.
00:27:15: For some, like you say testing tools for some tools and I was like why do we have this tool written in in closure?
00:27:24: And Then asked the guy he was exactly like this.
00:27:26: You know i love closure.
00:27:27: It's my favorite to okay.
00:27:30: so who is maintaining This library?
00:27:33: its me.
00:27:34: everyone else doesn't like closure.
00:27:36: I was like, okay but if you leave what are we going to do then?
00:27:42: Precisely and that happened.
00:27:44: It's happened for me when someone wrote a test library in Skala.
00:27:49: once they left the whole set of tests got rewritten into another language.
00:27:52: i can't even remember now.
00:27:53: this is why some thought about big decisions.
00:27:59: programming languages actually quite reasonable decision.
00:28:03: it has impact Anything.
00:28:06: so the things that i would want people to bring to the tech governance group will be anything that has an impact beyond their team.
00:28:13: Anything this does kind of like.
00:28:18: are you trying introduce something we have a pretty standard way doing?
00:28:22: it might affect other teams because maybe don't wanna have, So, oh yeah.
00:28:28: We've got a CDN.
00:28:29: you want to try new cdn?
00:28:31: Okay so we have to have our theory for what happens.
00:28:34: if it's really good are we moving everybody onto it or will be supporting too forever because there is not often lot of thought about that.
00:28:43: as the director of platform engineering team one thing I found interesting was number times.
00:28:49: someone would turn up and say hey could take over this technology cause don't wanna own anymore.
00:28:56: And as a platform team, you're sort of going well.
00:28:59: we already have a thing that does.
00:29:00: That
00:29:03: exactly yeah.
00:29:04: I also experienced that i must say.
00:29:07: unfortunately then people won't help and You say and you Have to Say sorry I Can't Cannot Help You We are Busy With Our Stuff And We Just Cannot Look At This Technology.
00:29:18: Yeah But Then It's Too Late.
00:29:20: I just Want To Avoid The too late Moment.
00:29:23: I think you have to have the conversation.
00:29:25: So, um... I was chatting about this a couple of years ago with Matthew Skelton who wrote Team Apologies and we were talking about The idea that you harvest ideas from within the company And basically saying There's got to be decision as platform team.
00:29:40: That your okay.
00:29:41: take something.
00:29:42: For me there is barrier.
00:29:45: so i would say Is it documented?
00:29:47: Does has tests?
00:29:49: Surprisingly often People want to give you something where there's just nothing.
00:29:53: There is code, there are no tests or documentation.
00:29:56: they're asking you... ...to turn this into a proper thing and I feel like that will take it over if we've already done the work.
00:30:04: but.. You know?
00:30:06: You ask me do your homework!
00:30:08: Yeah yeah okay.
00:30:12: so now take governance group.
00:30:16: you have to bring in those, let's say new ideas.
00:30:21: You think oh this is cool.
00:30:23: I thought about it and talked with everyone else but probably only use my team not the whole organization And i think its good.
00:30:36: just start small.
00:30:40: one question how can keep overview of things we briefly introduced in one team and more.
00:30:47: And then when it spreads, the typical answer is The technology radar to me at least... ...and you also mentioned that I like the idea.
00:31:02: It sounds good but i'm usually overwhelmed by all the proposals I get To manage everything in the technology radar.
00:31:15: So what are your recommendations when it comes to technology radar?
00:31:22: I like the idea.
00:31:23: We didn't use it at the FTRAC, but i liked the idea of it and think is a good way.
00:31:29: we had some tech hub that detailed all core capabilities offered by platform engineering.
00:31:41: So that would talk about the technologies, they're kind of sanctioned and useful for everybody.
00:31:47: We had invested in knowing what we have in our system.
00:31:50: so there was a...So we had this I think all bizops with many, many microservices at the FTLiK thousands.
00:31:59: So we needed to have list of all of them.
00:32:01: All of the microservices were need to know other services than we have but it's not really hard so that we had a chance of going, well okay.
00:32:11: We've got Java and we've gotta go with these logging tools.
00:32:14: here's the technology they're using.
00:32:16: So if you have that central idea like here are commonly used things?
00:32:21: And definitely knew there were some things being used elsewhere or maybe weren't so aware off.
00:32:29: It is I think very difficult to be entirely on top.
00:32:33: everything has been use somewhere in your software state Because there will be some stuff being trialed somewhere by someone.
00:32:42: Exactly, exactly!
00:32:46: But we had something that worked.
00:32:48: so you couldn't go live in our hosting platforms without a unique system code and you could not get it unless you entered the record into this system registry or catalog.
00:33:02: So at least we would know if these things existed when people were building stuff and we know who owned it.
00:33:08: And that becomes quite important, but yeah I do think its extremely hard-and i've been in the other extreme where you only able to choose from a very small set of technology... That was very painful!
00:33:25: It meant there are few cases with using wrong technologies because they're is one thing approved just wasn't right tool for the problem we were trying to solve.
00:33:37: So I feel like rather there was more freedom to introduce new stuff?
00:33:43: Yeah, yeah of course!
00:33:47: We have this all the time very conservative organizations where you are extremely limited in your choice and then you have to talk a lot to get a product choice.
00:33:59: And it's just the other extreme where everything goes.
00:34:04: I immediately thought about one client.
00:34:09: Everything had to be web-scale, so they used Cassandra.
00:34:13: but there were no Cassandra problems.
00:34:16: They had very few users and needed strong consistency.
00:34:23: There was not a way out.
00:34:24: You have to use Cassandra.
00:34:26: That's really something you want to avoid.
00:34:32: Yeah, but yeah probably the right choice is as you said in a beginning.
00:34:35: Right?
00:34:36: Do we have something similar which solves the problem?
00:34:40: no okay then let's take it
00:34:44: and if you do want to try maybe I'll say something similar.
00:34:47: You need explain why its not... Why you think that this isn't the right thing for you?
00:34:52: And often people are right.
00:34:56: It is actually correct that there's a better solution for your particular case.
00:35:00: That it slightly different, but you do have to understand what will happen in five years time?
00:35:05: Is this going exist and we'll also something else?
00:35:14: Yeah probably its way too.
00:35:16: control To control the amount of technologies.
00:35:21: I still think to radar or this.
00:35:22: what would you say that you said technology lock was a name
00:35:27: system catalog.
00:35:28: is it's
00:35:29: quite catalog.
00:35:29: yes backstage.
00:35:34: was homegrown because we were doing it full.
00:35:35: backstage existed.
00:35:39: Honestly, you can use a spreadsheet and just need to have something that says here's what we've got in here who owns each part of it?
00:35:44: And there is the technology being used... ...and you've got chance at working out what exists
00:35:51: now.
00:35:51: Yes I think okay.
00:35:53: so if i use a spread sheet tomorrow then We will have technologies using it.
00:36:00: What business problem does this solve?
00:36:03: We have something similar, yes no.
00:36:05: Yeah I think it's okay to have a lot of things in parallel.
00:36:09: right because some technologies are older but you cannot just get rid off them all the time and... It is
00:36:16: true!
00:36:16: But you do need to have plan at some point cause there will be period where you've got multiple technologies running in parallel.
00:36:33: What's your plan?
00:36:34: How is this going to change.
00:36:35: You're using two different technologies, are you all gonna move on to technology A?
00:36:42: it like what happens in a migration Is interesting and introducing new technology.
00:36:47: presumably you'll migrate away from the old technology at some point.
00:36:50: What's the decision for that?
00:36:54: but I think That's a hard question right.
00:36:57: so if i'm fully into cool ball.
00:37:03: I mean, that's an extreme case right?
00:37:05: But if i have some older web framework and it is very expensive to move away from a new web framework.
00:37:17: probably
00:37:19: Yeah!
00:37:19: So the important thing was having conversation early.
00:37:26: Someone says they want introduce this new web frame work.
00:37:29: You need not talk about If it is successful, what's the plan?
00:37:34: Are we planning to move everyone into it or are you trying to keep everything else.
00:37:38: Like I like one of the advantages and micro services as you don't have to migrate everything.
00:37:43: We moved to using go at the FT in my team And we left all other Java Services that were already working.
00:37:49: fine Because who needs to go and rebuild twenty services that are effectively complete.
00:37:57: But at some point, there'll need be a decision about.
00:38:00: do you want to be supporting these Java services when You don't have any developers in your organization Who write Java anymore because everything has been written In the last five years is written in Go.
00:38:11: Maybe we need To think About.
00:38:13: Are We Going to Rebuild Those?
00:38:14: Are We going to port them over?
00:38:20: No one wants to do this stuff, though.
00:38:21: You don't want be the team that has spend six months doing migrations because it just means no-one is talking about you in a positive way and not delivering new features or new products?
00:38:31: Exactly!
00:38:34: Yeah... Or maybe when I think of ThoughtWorks Technology Radar idea That your own hold was not very clear You know, everyone had a different opinion about it.
00:38:51: Does that mean we want to get rid of it?
00:38:53: Or like in your example... We just don't continue with the technology?
00:39:01: Yeah well I think it probably covers both and actually knowing which one is really important you're not building new things using this versus we have our plan for running on this technology by a set date.
00:39:16: They are very different.
00:39:21: Yeah, it was actually fun.
00:39:24: A fun idea of a colleague of mine.
00:39:25: he introduced the website WorstOfPreet.
00:39:30: so worstofpreet I don't know if you ever looked at it?
00:39:34: You shut the link and I'll do it right!
00:39:37: So the idea is we kind of anonymize like really bad decisions technology to decisions architectural decisions.
00:39:49: But there is one thing in it.
00:39:50: It's the tech horror radar, which is kind of fun You know?
00:39:54: It has something like you have to remove immediately if its too late full disaster resignation we need to live with.
00:40:05: but I find that quite useful because sometimes you really cannot get rid off old technology and you have a way to deal the old stuff nobody wants anymore and also to categorize it, we have this Java staff.
00:40:27: We don't continue.
00:40:28: but we also have this technology
00:40:47: this technology there, we're not easy building new things on it.
00:40:52: Are you looking at your people and hiring to make sure that you can still do?
00:41:00: I have been in an organisation doing consultancy where they've made a decision when moving away from a particular technology but services written in the previous technology but no one could touch them because i didn't understand.
00:41:14: they have been hiring for a different language.
00:41:16: No one really understood.
00:41:17: it is a real risk and i think in a sense inner well run organization you ought to be saying okay we're gonna build everything now node, Twenty people who can write that code and we need to work on it because I think its a big risk.
00:41:39: At the Financial Times, there was almost no one in the organization We at some point said, well we can get rid of the services.
00:42:00: It's time it doesn't do a great deal and we started looking into it discovered that he brought in a lot of money.
00:42:05: so At that point we hired team to rewrite it in our language that we could support Because we had decided there were business reasons to maintain it.
00:42:14: having MP was a risk And it was worth doing that.
00:42:18: migration, but its only when you have those conversations.
00:42:21: honestly no one's excited about having a conversation with this
00:42:24: stuff.
00:42:26: But I used to do operations like in charge of operations and platform engineering at the FT.
00:42:31: so what are things we should be thinking is how can support system where nobody knows?
00:42:42: Yeah, one final question and I should have asked this in the beginning but somehow We took a few turns.
00:42:53: One colleague of mine he says well you know.
00:42:56: The major or the biggest task that most important tasks over CTO or principal engineer He is also principle engineer Is to select technology?
00:43:09: And i was like Yeah, when you say so it's true.
00:43:15: I think that the CTO probably have to think about technology is in your name but if use the HIFE like you described everyone can propose technologies That´s better!
00:43:32: It depends on the organization.
00:43:33: So i've not worked with the kind of organisation where the CTI was making me big technology Decisions or rather they're not coming up with the options that you making a call, but there expecting someone else to come in their and say here are the hero.
00:43:48: The options into thinking I think everyone's.
00:43:51: You want to harness everybody?
00:43:53: Everybody's ideas And experience and I'm looking for the CTO to be make it really big strategic decisions about we.
00:44:05: Are we moving into the cloud?
00:44:06: It's quite a while ago, but someone was going to make that decision.
00:44:09: Now maybe are we moving out of the cloud?
00:44:14: Are you concerned that we're using technology doesn't seem very actively maintained anymore or is there risk for those kinds of things?
00:44:24: where I'm thinking CTO should be saying this seems like a risk to us as an organization and so what options... There are different CTOs.
00:44:34: If you're in a smaller organization, they probably do have that focus on understanding the whole of your estate and where you're trying to go strategically?
00:44:45: Probably now it's... I know some companies who say you're not allowed to touch code anymore.
00:44:55: It's I mean people are scared like new hires.
00:44:58: Oh, I have to.
00:45:00: I Have two riots prompts and I don't know that.
00:45:03: the code base.
00:45:04: yeah well big strategic decision All right.
00:45:12: so you have to go unfortunately.
00:45:17: Yeah, definitely thank you very much for the conversation.
00:45:24: For everyone else and all of our listeners by the book watch your talks!
00:45:29: And yeah hope to see you soon at some go-to conference.
00:45:36: Definitely will be a pleasure.
00:45:38: I really loved speaking in Go To The Copenhagen last year.
00:45:41: it was great All
00:45:42: right.
00:45:43: Thank
00:45:43: You!
00:45:44: Cheers!