And what happens when you share what you know is that whether you're trying to or not, you become kind of the go-to person for that topic. So, I think, Pedro, I'd really like to kick off with what you just said about coming from an area of Portugal where you're quite prolific. That's something that I find... I don't want to stereotype here, but maybe British people aren't always the best at handling.
where some people in Europe seem to be more direct and seems to be a bit of a cultural difference. What's been your experience and how have you found that work as you've worked around Europe as a software engineer? Yeah, that's a good question, John, because I think in large numbers, there might be some truth to the stereotypes. But when you're dealing with individuals, every person is unique.
So I've definitely seen people from, I don't know, the Netherlands who are very direct and they will say, I'm very Dutch, I'm so sorry. But I've also met people that...
have nothing to do with the stereotype that you might have about them. So the main thing that I've learned is that it's mostly about individuals and not so much about cultures or or or stereotypes okay to the following though have you found that you've needed to change your behavior a little bit how people might see you as direct or not see you as direct and how people respond to that yeah i think so
I think so. The thing is when you're a person who's trying to exert any kind of influence, and for me that was a little bit just... accidental, just trying to get things to happen as an IC before having any kind of formal leadership role. I found that it was useful to try to understand who I'm talking to. and how they respond to things so that I can communicate not just at a level, but in a way that connects better with them.
And what I find is that I do have to be very conscious of how I'm coming across to do that more effectively. So did you start off like that immediately as an IC, or was that something you learned through making mistakes? The one above mistakes. Definitely I learned this through mistakes. I used to be actually very abrasive, I think. I was very, very punchy, very fighty. I thought I knew best.
or when I felt really confident in something, I would die on the most ridiculous hill. Yeah, it was kind of embarrassing, actually, for how long I was like that. I think I was in my 30s when I finally realized, oh, crap. It doesn't matter if I'm right or wrong, if people don't like me, you know? So, yeah. Yeah, I'm grinning away because I feel the same.
I started off fairly much going into a professional environment. People are professional, grown-ups. We're talking about ideas. I can be blunt because I'm a blunt person. I can be direct and straight to the point. Not rude to people, not... you know calls me to deal stupid but i can say this is bad we should obviously do this also and it took me again far too long longer than i really like to admit to realize that actually
People can take offense at it. People can find it difficult. We do have to tread lightly and think about other people's feelings, and it's not just about presenting the best idea. It's about how you present it and how you come across it. That's why I've...
The last couple of years, I've learned quite a lot about soft skills on LinkedIn. And I try to encourage engineers to develop them because I think I realized that later in life, then I would now like in hindsight. So I think if I can share that with other people and get this change.
Isn't that positive? Yeah, I think that's very insightful. And I do like how much you talk about it. You have this interesting profile on LinkedIn because you do have your coding challenges. You are very, very clearly... very accomplished on the technical level. But one of your strongest messages is about soft skills. And that's so on point because without them, you're not going to develop yourself so much in your career.
You're going to plateau at a certain point. And I don't think it's a coincidence that my progression to management came at around the same time that I started being a lot more mindful. about how I'm engaging with others. Yeah, I think that's why I push the message so much. I'm almost trying to shout back into history and get that message to me when I was 21, rather than maybe at 31.
or later and again it's a message i'm trying to share with my kids and i hope you know if i can get a few other software engineers to pick up on it and smooth that transition make it easier for them to communicate with managers or leaders or even other software engineers At the end of the day, we are people. We are subject to our emotions and subject to our biases. Yeah. I would say, even especially to other software engineers, you know, as a manager, I'm often...
you know, looking at conflict situations and I'm trying to do what I can to mediate them. And I often deal with developers that maybe are not really thinking about how they're coming across when they're talking to me. But if you're talking to me, I've been there. I understand. I can empathize. I don't mind. I can work through the roughness. But it's a shame that a lot of the time there are people who are ICs and they get into this kind of...
very sad and kind of pointless conflicts because they're not thinking about how they're coming across to each other, right? And it's a shame. Yeah, especially when you can stand back from some of it and think, actually...
The two of you are arguing for the same thing, but you've got so emotional about it. You're talking across each other now, and you're just getting more stressed from each other instead of actually realizing that you're both on the same side. You're both trying to chase almost the same things. It's a great gym. Yeah. So we talked about soft skills and how that's led as you move from IC to management, but you've had a not quite a straight line career path from what I saw.
What's been your career journey? How did you go from IC to management? What were the steps in between? Yeah, I think even as an IC, my path was a little bit unconventional because I just wanted to... be very independent and build my own thing basically as soon as i learned how to program you know i wanted to start a make a startup and and and follow that dream but this was early 2000s uh in portugal in the north of portugal where
the tech community didn't really exist so much, or at least I wasn't really in it. So that would not be very difficult, but that's why my early career was very, you know, kind of freelancing projects here. building my own products and trying to sell them there. The main thing that came out of that was I learned how to be independent or rather autonomous.
You know, like when you're going to a client as a freelancer proposing to build an entire app, you know, database to front end. And most of my career was in web. So a lot of what I say is in that context. But when you're the one who is selling and building and maintaining and supporting and designing and doing everything, there's no one else. There's no one else to fall back to. And it turns out that that.
Ability to do that translates really well to leadership roles at companies and also translates really well into management roles as well. So that early part of my career, I think. prepared me for for management um in that way um yeah but then specifically the transition from ic to manager this happened at hellofresh right almost 10 years ago hellofresh was not as big as it is now
And I basically gained a lot of credibility from doing what I said I was going to do, right? Calling your shots and then actually taking them is very important in anyone, but especially in somebody who wants to be a lead. um and and the company was growing a lot and i was helping others a lot and by helping i mean i just i just shared what i knew and i was lucky because the things that i knew the things that i shared the most happens to be things that um
the team needed. For example, we needed a new API and I had a lot of practice building APIs kind of very recently. We needed our new PI to be very well tested. And I happened to be going through a huge testing kick. And so I just brought all these things. And at HelloFresh, we had these geek talks every Friday or every other Friday.
and i was always signing up i was always like oh i have this thing that i want to talk about and what happens when you share what you know is that whether you're trying to or not you become kind of the go-to person for that topic. So that was, I think, the thing that opened up the path. And then we were looking for a head of engineering for the longest time.
And we couldn't find the person who did all the things that we needed. We needed somebody who knew PI, front-end, back-end, infrastructure, mobile. And we wanted a unicorn. And then one day we were at the housewarming party for my flat that I was moving into. And of course, kind of a small team, everybody kind of ended up tagging along, including Nunu, the CTO. And at some point we're talking about how hard it is to find a head of engineering.
And I just, and then we go, hang on a minute. Why don't you have four heads of engineering instead of just one? Because you have all these different things, right? All these different contexts. Why don't you just take one of us? for each of those and try that out and see if we can make that work. You know, the team already knows us or someone else. I wasn't actually trying to get the role. I was just saying, hey, we've been looking for a long time and we need a solution, right?
because we're kind of bottlenecked here with you honestly known as a great guy great cto um but you know the team was growing and and he took that advice um and then well I ended up becoming the one for platform and then some other guys went with the other areas. And that's how the promotion happens. Sometimes you make your own opportunity. Yeah, absolutely. And that ties into it.
LinkedIn posts I mentioned about becoming a CTO. Several other ways to become a CTO really are about creating your own opportunity. Getting into an early stage startup as founding engineer. As you say, speaking up, being the expert.
Being the one that does what you say you do is a great way to progress and getting to the role. Equals much. Founding your own business is a way that many people become a CTO. Certainly the way I've done it twice. Okay, so there was something else I wanted to pick up. In between though... being an IC and making it to head of engineering for platform, you still got a little bit of a detail in a biz dev role by the looks of it. Yeah.
Yeah, that's true. You know, that story starts as it often does with a breakup. I broke up with my longtime girlfriend and decided to move from Porto to Lisbon in Portugal. without any plant so i just uh just moved i stayed with some friends and then i decided to start looking for work there and um and it just so happens that there was a a role
that was kind of mislabeled. It looked like a developer role, but then I got there, and it was a role where you needed to be able to program, but mainly you were a biz dev. So you were some kind of cross between a... biz dev and a solution engineer something like that so you need us to um do integrations uh of their of their tooling with customers but the thing is i really like the guys
It was a really interesting team. They were in internet marketing, which was interesting for me as well. And I decided to stick with it. And that's how I ended up in a kind of biz dev slash solution engineer. hybrid kind of role which was not what i had expected but it was cool it was fun cool it does sound fun and i've got a similar story in it slightly different but
I ended up customer-facing and doing business, in fact, because I tired of my own business, and fairly quickly realized that you can't just build it and everyone show up. You have to go out there and sell. It's true. As a software engineer that didn't want to deal with people,
that it is on the phone. Gotta go out there and sell. Funny you should mention that because this role involved the thing that I dread the most, which is picking up the phone. I have a phobia of phones. I don't know what somebody calls. I don't want to pick up. Unless it's my wife, I don't want to pick it up. And in this role, I had to research websites in Portugal that met certain criteria. And then I would have to find out who owns them.
get to talk to them and sometimes that was an email sometimes there was an actual phone call and um and it it pushed me so hard outside of my comfort zone um that i'm very grateful for that to this day because i think that that i found out that i can do it and that helped me to understand even better that software is not just about code it's about you know
relationships and being able to talk to other people to make things happen and again that was a great preparation for a leadership role later yeah in many ways it's creating that t-shaped developer that spotify made famous when they blog about it start to have broader skills we have a technical depth but you learn a bit more about sales and customer facing and also as you say but pushing you outside of your comfort zone it's so valuable because if we just stay in our areas and
Don't try new things. We won't learn. And to learn, we've got to go outside a comfort zone. We've got to fail. We've got to mess up. And that really brings me back to a slightly different topic that I thought would be interesting to talk about. Personal branding. Because... Personal branding has a lot these days with people blogging, writing on LinkedIn, sharing on Twitter or another social media platform about what they do. And a lot of people feel that fear of publishing.
But as you say, going and doing your geek talks at HelloFresh, all of that stuff, as soon as you start sharing, you start becoming recognized, whether you intended it or not, as an expert. and this was true even before we blogged into social media go back 30 years ago and you published a book you were the expert now you had a book about it so all these times when you've gone out there and you share something
You start building a personal mind, you start building a reputation, you create that. Is that why you're lying on LinkedIn? Is that where you're going now with this? Yeah, I think it is. i made several attempts at at linkedin and um what stuck was something that i started doing actually just last year which is just to write about whatever i'm thinking about and not plan it too much
It's interesting because a lot of people recommend you should plan your content. You should have your content maps and all those things. I'm sure that's really productive. But for me, it's more about being spontaneous.
and i do like to share what i know or i do like to share what i'm thinking about and sometimes that's helpful to others sometimes it's helpful to me because people come out come out and they say hey pedro you're wrong or i disagree or i mean i think that our first interactions on linkedin you just came in really hard on a post of mine and i was like wow i'm i'm completely wrong about this um which of course feels very like
I shouldn't have posted that. But when you move past that feeling of almost like embarrassment, there's a learning there, right? And that's actually as good as if people are agreeing with you. Because you grow that way. So, you know, thanks, John. Actually, I don't remember what it was, but I remember feeling that it was like, oh, this guy knows much better what he's talking about than me. So that was a good learning. And in a way, LinkedIn is a meetup that never ends.
Every post is one of those little huddles, one of those little conversations, and you're... I've met so many people through LinkedIn that I would have not met without it. So it's about... Sharing, learning, opening myself up to opportunities that I hadn't even thought possible. And it's the meetup that never ends yet. Well, I hope it wasn't too hard. My apologies, it was. Do try and avoid that.
But I think, yeah, you're absolutely right. Even if no one else leads it, by writing it down, we start to structure our thoughts. We start to arrange them. We start to evaluate them. I've forgotten who, but somebody put it as lighting is thinking. It is. And yet, it's so useful even if nobody leads it. But if it does, we start playing that. We save that network and we also get feedback on it.
Again, particularly for those of us that work in, say, small companies, and there are a lot of software engineers that do, if you're working on your own or on a two or three person team and you don't have people of that kind of experience,
Sharing on LinkedIn might be a great way to kind of get some feedback. Some of it might make you feel a bit, oh, I'm doing this long. I don't know what I'm doing. But that's growth. That's an opportunity for you to step back and go, well, mostly it's a strange on the internet i don't need to worry about really what they think but it is an opportunity to learn it's an opportunity to and some of the feedback you'll get is wrong some of it will be right
long for you because the context is different. But it's all a chance to grow, isn't it? And maybe become aware of something you didn't know. Yeah, exactly. And leadership is also lonely.
especially in small companies. If you're head of engineering of a very small company and you're like you're reporting maybe to direct to the ceo or to a cpto who's more product based um than than technical uh oriented you might be the person that everybody goes to and and and who do you go to and of course i have my network of friends and i have my my my signal and whatsapp groups where i just uh do the very raw very unfiltered calls for help like this is happening what the hell do i do
But LinkedIn fulfills a similar role, more filtered. I'm not going to name any names on LinkedIn and I'm not going to be abrasive on LinkedIn, but definitely some of the things that I put there are things that I'm... either considering in the moment or have considered recently and i just am curious to see what the group thinks yeah it can be a very useful sounding ball for that can't it because we can yeah so i think there's a billion people that certainly leaked it now
an amazing chance to reach people that have different knowledges different experience different views on it and maybe one of them will tell you long and correct you maybe one of them will ask a question that makes you Just take a different perspective on it, all of which could be very useful. A little bit of a pivot now. You mentioned moving to platform engineering before and solution architecture.
I still find a lot of software engineers don't know what both of those are. So kicking off first, what is platform engineering? good question and i think you'll get different answers from different people um but at hellofresh platform started from the api team so we had a we had a a team that was developing this new API that powered all of the consumer experiences. And that was actually the anchor.
for all of platform uh we we also had our first structure team in there and then we had payments and we had a few other more like short-lived teams as well but the the the concept that we had platform and the concept that kind of stuck with me was that platform is anything that someone else is building on top of so for me platform is not just the infrastructure
platform is going to be what i guess some companies call core engineering like these are this is your core domain model is going to be in this and you're going to be supplying uh you know this product this platform product to help others build things way faster than if they're you know building their whole vertical slice of functionality from the ground up and in fact
The jump to Contentful, which is where I was a solution architect, kind of built on that a little bit too, because Contentful is a headless CMS, so it's API first, and in effect, the company sells an API. And it's exactly the same idea. So this API provides you with your kind of primitives, which are, you know, content entries, content types.
assets you know all these things and then it's up to the developers at the customers to weave all of those things into the custom functionality that they need but they don't have to worry about everything that's you know already supplied by this platform they can get up to speed really quickly so that that is how i see platform but i but i know that many people see it as just kind of more low level yeah i get the impression of some places that it's
Kind of a mixture of SLE and DevOps. I hate to use the term DevOps there because what DevOps has become, not what I think it was intended to be, So, yeah, it's kind of ops with automation and dealing with the infrastructure. Okay. On that note, there's a lot of debate at the moment about whether we should be in the cloud, whether we should be self-hosting, whether we should be serverless.
or server-based. And I saw a post today, for example, saying that one of the alternatives to chess.com is all hosted on one big server. That seemed a bit odd to me because they talked about a half million dollar server. I had a quick look and it appears to be spread out more like 30 servers, but there was this ongoing debate about should we be cloud, should we not be? And 37 signals propagated this when they moved out of the cloud.
What are your thoughts now? What's been your experience, Pedro? I have thoughts about this. First of all, I think the cloud is amazing. The cloud revolutionized things. When AWS became popular, it changed the way that we think about hosting. So huge props to Amazon for that. But what I think has happened is that, you know how the number of developers doubles every five years or five to 10 years, something like that.
So it stands to reason that half of us who are active now started 10 years ago or more recently. And this has been a time when the cloud is the only way. to host software it became that way by virtue of its initial success by virtue of the immense marketing efforts of the hyperscalers It just became, I think people are now kind of afraid of not being on the cloud because then they have to do everything themselves. And I think that's a shame because the cloud is not inherently better than
I don't know, co-location or something else. The most important thing is looking at your situation, looking at your scenario and making an informed decision, not just go with... whatever the zeitgeist is telling you like the cloud gives you huge flexibility that's amazing that's very valuable but once you get to a point where you know your base load for example
It can be more economical to have that load served by machines that are, you know, co-located or something, or you rent the machines or whatever, and then you use the cloud to deal with spikes. serverless, likewise. Great technology. I actually do think that things like Supabase are going in the right direction. In this day and age, you shouldn't need to build too much low-level
code just to get an application up and running. But again, if you're dealing with a million requests per second, maybe you should think about having your own infrastructure. My take is it's highly situational, but I also feel a little bit like I want to fight people because I think most people default to cloud.
without thinking about it and i want to challenge that that's a good way of putting it when i started my career people always seem to think far more about the total cost of ownership we evaluated do we buy a server or do we buy a desktop or do we rent it do we build by this software solution by the total cost of ownership and we look at things and say well it's not just the cost of this server for x thousand pounds or dollars or whatever
It's not just the cost of the Windows license. We've got to pay so many to install updates. We've got to expect it to fail. It's got a lifetime of this. What's our total cost of ownership?
and if we lent it a thousand dollars a year versus it costs us two thousand to buy but then five hundred dollars a year for a license five dollars a year to serve which is cheaper and we seem to have forgotten a lot of that as you say we just crowd by default rather than thinking well what is the crowd good for and that's good for our unpredictable on-demand loads what is owning our own hardware for and optimum price wise it's for
if we know we need a big powerful computer 24 hours a day it's always a lot cheaper to buy that rather than rent it because if we rent it you've got somebody else's profit margin in so by definition it's always going to have to be more expensive They want to return on their capital. And again, let's forget that assessment as well, that it's also, you know, if we need a $50,000 server, do we have the cash to buy that? Again.
If we don't have the cash to buy that, we haven't got funding at the startup, then yeah, the cloud is a great way because you can pay $50 a month or $100 a month. And that will grow as your cash flow grows. If you are a big multi-billion dollar business.
go and buy the 50 grand server because it'll be tax efficient that way and you can offset it and you're not going to have a cash flow issue. Absolutely. One thing that I think people forget all the time too is that um the cloud is no longer um hands-free one big selling point 10 years ago was that you didn't need to know how to manage a database right rds was just available for you
So you saved on personnel. You didn't need a database expert just to run a database. It was just available. But over time, as the cloud providers provide more and more and more services, you do have this role of the cloud engineer who starts to arrive. And you do need the system engineers who are now specialized in making the cloud work. And it gets to a point where
Well, that's a cost too. And if you have to pay people to help you run your cloud, would it also not be a possibility to just not have the cloud and then they're just running you know your services on on bare metal or or rented um computers uh and and sometimes the answer is actually you need the same people but some number of people but uh your your costs um
of the infrastructure would be lower. So as you say, the total cost of ownership, I think, is not always calculated in the way that it should be these days. Yeah, Eli, when I started building web applications, 25, 30 years ago, we had engineers that would come in, rack up the servers, rack up a couple of Cisco leaders or switches, rack up
a firewall doing the same thing now, except it's all virtual. It's all done through config, but they're still doing the same config. They're still building all this. It's just in the cloud and you're renting off somebody else. Now it's Terraform files. Yeah.
Although somehow I managed to avoid doing terraform ever. It's always been cloud formation. Seems to be one of the few people who managed to avoid terraform for my entire clearing the cloud. Well done. I don't know if that's a good or bad thing. entirely done cloud formation. So we touched a little bit as well on solution architecture and solution engineering then. Again, another phrase that I think a lot of software engineers come across.
So could you explain what it is, Petra, for the people that don't know? Happy to. So there are two kinds of solution architects, but roughly what they're doing is they are people who are experienced enough to know like the tools and the practices that exist and they know um a lot about of course software architecture but uh what they really do is they they they help teams arrive at um
good designs for their systems especially when these systems have to integrate with other systems third-party tools or other internal systems of any kind So it's like software architecture, but it's very focused on solving a specific problem. And internally, these roles exist, but they're very common in B2B SaaS products that provide developer tools.
So Contentful was that, like this API, this headless CMS, this API-first CMS needed to be integrated with the systems at our customers. And so I was the external-facing solution architect who would... help them do that so basically i knew a lot about our product i knew a lot about the the typical use cases and integration um approaches for our product and a bunch of different other products and stacks and so i just had
a bunch of answers that i could give to to them and help them think through how to best make use of this product that was the more tactical aspect of the role but these um people in this role also have the ability to be more strategic and actually engage with leadership and even C-levels at these customers to kind of evangelize the business benefits of the product and how they can
help them achieve their goals of going to market faster and increasing revenue and all the usual things. So it's a very, like, it's like a business-oriented software architect. It's a very flexible role. Every day could be doing different things. And I think that's what makes it quite an interesting role. And at times when I've touched on doing elements of that, I find it quite enjoyable because I find the elements of running a business and being strategic very interesting, which is why I...
progressed to being an executive in a startup because I wanted to be part of that. I didn't. I enjoy the technical side. You said it's something I do a lot of with coding challenges. I also enjoy figuring out what's the business strategy. How do we go to market? How do we figure out these things?
I like the elements of solution architecture that touch on that. And I like being involved in customs that ultimately what we're building solutions for. What do you think, or how would you explain the difference to a software engineer that Maybe heard of a developer advocate or seen a advert for a field CTO. What in your mind is the difference between those three roles or are they largely?
That's a good question. And I have to admit that I'm not super sure what a field CTO is. I can't really answer that with any certainty. You got to admit when you don't know something. Yeah, absolutely. So again, I think it's one of these things, there is no clear definition, but the job adverts I've seen for it have focused on that strategic and that element you talked about of talking to senior leadership in a company.
And again, I think it's a bit like banks where everybody's the vice president because it sounds impressive. I think the field CTO is, again, it's giving you that C-level title because it's more of a strategic level solution architecture where your customers are going to be. C-level execs in a medium to large enterprise. So you need that credibility and you need that level of seniority. But to me, it always seems it's the same sort of thing. What are you trying to achieve with a business?
what is the business problem you've got and how do we talk about the strategic investment you're going to make here and how's this going to integrate over the next five years to to the field business strategy makes sense okay so that definitely is part of the role that at least i had at contentful but i also know the contentful was it stood a little bit apart from other sas uh b2b sas vendors at the time
We took the need to engage our champions and their bosses quite seriously at the time, which I think from feedback that we got from these customers, not every vendor was doing.
But we didn't do it alone. I would usually travel with a customer success manager. And we could go and be, you know, in the morning talking to the developers, trying to unblock them and try to... help them do the architecture and in the afternoon be talking to them to them whatever stakeholder was actually driving the initiative and always trying to get to the sea levels to evangelize
So it sounds like from your description that Field CTO would be doing a little bit of that, but with a nicer title that lends more credibility. And titles matter as much as we like to pretend that they don't.
Yeah, absolutely. As I say, that's why banks have gone giving everybody the VP title. You know, in a bank, you might only be vice president of your desk, but you'll have a vice president title fairly quickly. You mentioned something else there that I think a lot of software engineers won't necessarily recognise the term. You said...
you deal with your champions what do you mean by that oh well the champion is typically in the vendor relationship the champion is the person who brought you in and who is telling everybody about how great your product is. Cool. Because I know there are a lot of software engineers that want to start their own business and a lot of them will want to sell to other companies. So understanding some of this will be quite useful for them. And you like those champions can be so powerful.
was one startup i worked for several years ago where five of the customers we had of all large enterprises you know multi-billion dollar businesses all came from one person this guy He loved the product. And every 18 months or so, he moved to different companies that needed this kind of solution. And every single one, he went to another. Why aren't you using these guys? So he was the best salesperson the company had.
I never worked for this. And it always comes down to relationships, doesn't it? It has soft skills. And I think that's the answer for your question about developer advocates or developer relations. These are people who focus more on the developers themselves. They go to meetups. They sponsor events. They go to hackathons. They're on the ground connecting to people who might actually benefit day to day from the product and listen to them, hear them out.
get their feedback to improve the product. And through this building, through this growing relationship, that's where these champions start to form. And then, yeah, they go to their day. jobs that affect everybody with enthusiasm for this great new thing that they found out. Yeah, absolutely. So talking of great new things, years ago, my wife came back with this great new thing she'd heard about.
Bugs. Food delivered every week or so with some new recipes in. We could try different things and it was called Hello Flesh. Quickly became known by my kids as Hello Blockly. because every single recipe seemed to involve broccoli, and they were not impressed. I still haven't convinced them to like broccoli, but they have fairly diverse tastes of food.
Bring us back to HelloFresh, though, because there's a lot of talk about the difference in startup culture between, say, Silicon Valley and Europe. So you've been working at a fairly successful startup in Europe. What's been your experience of European startup culture? Well, John, HelloFresh is a better example because I think one of the things that helped it be successful was that it was such a mix of people from all over the world.
that it's really difficult to say that it has a classic European philosophy or way of working. But can I challenge that? Go ahead. That's one of the things I've liked about working with companies in Europe is that we had the European Union. We have freedom of movement. So the companies I've worked for in Europe haven't just been, you know, all British people or all British people.
german people we've had that different set of cultures and there's been that mix of different people so in a way that's what i thought of as european but maybe i have it wrong so Just interject that different point of view and kind of ask a question. Yeah, you know, that's a good observation. And I definitely agree. I mean, most companies that I worked for here in Berlin,
uh, at least on the, in the engineering side, uh, were, were very diverse people from, from, from very different origins, uh, and very different, you know, ways of working and of thinking. Um, And yet there's something, there's something when it comes to the expectations that are placed on the developers and the proactivity that is expected from developers and that is allowed to the developers.
that I find tends to be, and I know that I'm generalizing, slightly different in Europe and, for example, in the US. And definitely it's different here. and in you know portugal 10 years ago like when i was in portugal 10 years 10 years ago um it was very much impossible to find a company where engineers had any power we were basically just told what to do and that was it
Then I came here and it was an improvement. Again, I had a lot of ownership. I had the ability to kind of decide how I was going to solve the problems. But I do notice that when I was a solution architect and I was visiting a team, and you know here in berlin or stockholm um or paris i would usually talk to product managers first and then kind of have to fight to get to the engineers and if i went to new york or la
typically I would be talking to some senior engineer who's just leading the project. And there are product people involved usually, but it's more of a symbiosis and less of a kind of passive relationship. And I know that I'm generalizing, but this is where this perception comes from. And I can't explain it. I don't know exactly what's underneath it. It's just what I've observed. So on that basis, I've noticed similar in the UK.
a lot of british startups i've dealt with and particularly ones that have should we say older founders um we still have this very much focus that The valuable skills are being a manager at a big company or being a salesperson. So a couple of startups I dealt with, the salespeople were hoarded, and would think absolutely nothing of dropping six figures in salary for a sales guy.
Even if they didn't have expense in the domain Whereas when I wanted to recruit a software engineer, I'd be like, well, we'll get one for 20,000 No Yeah, that's pretty low to recruit a student that's just graduated. So yeah, I've definitely seen that as different. And then in contrast, when you go to Silicon Valley and I was dealing with companies there.
Engineers are paid very, very highly. I don't worry now about the salespeople over there, but certainly when we went over there and talked to them, our customers were engineers. They didn't want to talk to our salespeople. They wanted to talk to... me as vp engineering or they wanted to talk to the solution architect they wanted to talk to the engineers not a salesperson and again we went and pitched to a silicon valley vc and they were the same they had no interest in talking to the sales guy
They wanted to talk to the people behind the technology. We don't seem to have that approach, at least here in the UK, where very, you know, the sales guys of the kingdom, they generate 11 units. It's not a case of that either. is better than ever. We need every part of the team to succeed in the business. We do. And I think that this kind of segregation doesn't do European startups any good.
And again, maybe I'm wrong. Maybe it's just my perception. I certainly haven't worked at every single company in Europe. But for example, this is also why I say that HelloFresh was atypical. Yeah, like the business area was typically pretty far away from what we call the pit. which is where all the developers sat, which was appropriately down a small flight of stairs. It was like we were literally under everything else. But my CTO never came to me and said,
Pedro, I need an API that does this, this, this, and that. The brief was we need to launch a mobile app. Our current API is trash. We need something better. that is going to power not just the mobile app but also our new customer experiences on the web and that isn't extensible enough that allows for future use cases that we haven't thought about um In fact, he didn't even come to me. He was like, okay, who wants to look at this? Who wants to be on this project?
And me and a couple of other guys just kind of jumped on that and we self-organized and we were the ones gathering requirements. We were the ones talking to the mobile developers and the chefs and the marketing people and test driving the app on our own phones.
um we had product managers of course to to to explore the the problem space and dallas hey these are the things we want the app to be able to do and then we were left with complete freedom to um to design and implement solutions to that but if you ask who was the lead on the api project it wasn't a technical product program manager it wasn't a product manager it was me in that case right an engineer
And it was the same thing for data. It was the same thing for mobile. It was the same thing for almost everything. The product managers were, we had like two or three for the whole engineering group. And they were... asking questions finding out about the customers figuring out what we could do for the customer then we were collaborating we didn't have like a jira board that the pms were managing the tickets
So you mentioned Jira, everybody's favourite software tool. Oh, yes. What's your take on, and Jira almost always comes with Scrum or some other agile approach, what are your thoughts on... Agile coaches, Scrum, Kanban, whatever. Where does that take you of a lantle in favor of? You're trying to start a world war in tech there, John? No, look, in all reality, I think that...
All these things have a place and a role, kind of like the cloud, but much like the cloud, I think they are typically misused. Again, I've worked with great product managers and I have worked with great agile coaches who have actually helped teams to improve their practice.
but i think what made all of these experiences successful was when people were aware of the of the specifics of each situation i think what typically happens is you know you you start a software project and you just flap on the same jira board that is configured exactly the same for as for every other team in every other project with the same sprint durations and with the same ceremonies and with everything the same even though each team is going to be unique
So I think you need process, but it's a little bit like there's a quote that says that process is like food. You need it, but not too much, right? And mainly veggies, which I don't know how to fit into the whole process allegory. But yeah, I think process is usually there to fill a gap.
that exists in how people would normally self-organize and very mature teams typically need less process than less mature teams it's training wheels in a way and i think agile is not what it was supposed to be in the beginning agile has become a whole thing and it was just a set of principles they follow these principles you can be agile talk to customers now you're agile you don't have to have a 10 000 stand-ups per day
I think that's my big disappointment with it all because I remember doing a little waterfall software development. I was delighted when that child started becoming popular because we were recognizing the reality that
In a waterfall, we have all the requirements up front and nothing's going to change. Who are we kidding? That doesn't happen. And it's not going to happen. So AgileSite recognising that we're not going to get the requirements up front. The requirements are going to come in. So instead of trying to... plan six years in advance let's plan six weeks in advance or four weeks in advance do what we know deliver something and iterate on it and change it and that included let's iterate on the process
We'll have just enough process. We'll have a self-organized team. We have smart people and we'll do this process. And if it doesn't work, we'll change it. And that's still my biggest frustration with Scrum or whatever approach people apply.
we have these retrospectives and people play games in them forgetting that the point of the retrospective and the point of the game is to have that discussion go what was good what was bad what do we want to change how do we change what process sucks and gets in our way so let's stop doing it what process we're missing let's start doing it yeah don't get me wrong process is important uh because it gives people in and outside of the team
a protocol like you know you it's important for example to know how things are going jira or any other issue tracker is is useful to automate reporting you know people can look at it and see the progress of things and there's value in that um especially when you when you have like a very large company
No, a small startup, you can just ask around and you know how things are going in five minutes. But, you know, if you have a thousand developers, um, like, like, like what we had, uh, at, at Gatir a couple of years ago, um, You can't make the rounds in five minutes. So it is actually useful to have some kind of standardization on how you report things. Totally true. But it's a bit like interfaces. That's the interface. Everybody respects that.
how you report, but inside of that boundary, teams should be able to work in the way that makes the most sense for each one. Yes, absolutely. Couldn't agree more. Cool. We've touched on a lot of things. Anything else that you'd like to talk about and mention? Well, one thing about HelloFresh and I think most of the roles that I had here was that it was always about growing teams. We went through this very growth.
centered phase in the last 10 years. And I guess we could talk a little bit about that. But maybe it's more interesting to talk about shrinking teams, maybe a little bit more controversial.
I've got some painful memories of that. Yeah, but I feel like one thing that's changed is that in the last 10 years it was very easy to to grow i think as a professional because there was a lot of capital and as long as you stayed in the same place and did a good job you were going to get promoted because the company was growing it was almost inevitable and i think that now we are at a stage where
There are different opinions about what's going to happen. There are people who are adamant that by the end of the year, the mid-level engineer is gone because of Devin and such. And I know you have thoughts about that. I also have.
some thoughts about that and there are others who say no no no uh ai is going to create new opportunities there will be different kinds of work so there might actually be an explosion again in how many developers are needed and in how much capital is injected into into the tech industry so we don't know which way things are going to go but one thing that i do like about the current situation as frustrating as it can be sometimes is that the focus of
on efficiency is back and i think that we lost sight of the need to be efficient the need to be also just effective in how we work i think we went through a very long time where If you looked at the job ads, they had more space talking about the benefits that you had rather than what you actually had to do there.
and i think that not in everybody but i think that some people allow themselves to create the expectation that work was a place where you came to play almost right to play with new tech to have fun And there are certainly, fortunately, there are some people who are struggling now that I know because I've managed some of them because they feel almost betrayed, you know?
The relentless focus on efficiency and productivity is not what they signed up for when they became a developer six, seven years ago. I wonder what you think about this. I know you have thoughts. You've made some posts, but I would like to... to ask you. Okay, that wasn't why I thought you were going with shrinking teams. It's one aspect of efficiency, but then... No, I was more thinking of times I've had to make people who didn't, and I have painful memories of that.
I'm happy not to live those. So, yeah, I have mixed feelings about some of this. I have... I've been writing code and programming since I was nine. And I... got into software engineering around that time because i heard about ai and i i was ridiculously optimistic as a nine-year-old to think i could do anything that but the first programs i started to like were around ai
Yeah, Eliza was fairly recent perhaps at the time, or maybe started being mentioned in a few magazines. So that was my interest. And a few years after that, As I was quite a buzzword at the time, people started saying to me, why are you playing with computers, John? There won't be a career for you in that. By the time you get to university and graduate, you won't need software people. AI is going to like it all.
you know that was in the mid 1980s and university in the mid 90s there's still this talk that ai is coming it's going to replace software engineers but now there's 4gl as well we're going to need less software engineers because 4gl It's a fourth generation of languages for people that don't know. And that just has been the curling theme. And if we go back and look at it, people have talked about AI since the 60s. It's going to come, going to put all these people out of jobs and change it.
And we have made huge leaps forward, but it's never been as fast as people claim. And I don't think we're as far along as people claim. I mean, the kind of nine-year-old boy in me is really disappointed in that because... I wanted to see AI when I was in my 20s. I wanted to be part of doing it. I was excited by it. The slightly older boy in me is like, well, we've seen all this before. It takes a lot longer, but there are some massive challenges in all this still to come.
And these things always take longer than we expect. When they finally happen, they seem to happen quickly, but they generally have taken quite a long time to come. the focus at the moment seems to be that ai can produce code faster than software which keeps missing the point that a small part of software engineering is producing code
It's all the stuff we talk about with people. It's all the stuff of what do you want? And again, there's that old thing from sales where they say in order sales, but people make the mistake of If you're working a hardware store in sales, somebody comes in and says, I want to buy a drill. Here's a drill. No, they don't want to buy a drill. They have a problem they want to solve. They want to put a shelf up. They want to.
build something that requires them to make a hole in something so if you actually get to the bottom of the requirements they might not need to buy a trill they might not need a lecture they might need a hand trill but you could also sell them you know
drill bits to go through steel or wood or masonry depending on what they need they might also need an extension kit so in sales you broaden it and there's a bigger problem to solve and there's a different set of things they need and you offer them a different solution That is software engineering to me. It's like, well, again, take it back to what we talked about with the cloud. Are you going to service two users or 200 users? Are they all consistent at the same time?
Or is it a very spiky load? If it's consistent, the same 200 people every day, buy your own server. It's going to be efficient and cheap and effective. If they're very spiky, then the cloud might be the perfect solution. So that engineering is... asking those questions understanding that figuring that out being aware of the bigger context and solving those the coding bit is a little bit at the end and the hard bit of software engineering has always been
asking those questions getting requirements and many software engineers skip that because it's hard it's dealing with people it's vague we rush to coding a solution that's what we sometimes go wrong in it we rush to put the code out
So I think the people that still wish to put the code out are going to struggle because they are just glorified typists in a way, if you will, because they're focused on that typing. And that's the bit that we can automate. That's the bit that we can get higher leverage. but it's not software engineering. It's a small part of it. How do you feel about that, Pedro? Well, I couldn't agree more. I would say that LLMs are...
good also at like synthesizing things. For example, they're good at things that could help the process of defining a specification. For example, I think that they can play a role in that area. But LLMs are, by virtue of how they're made, they are incapable of reasoning and therefore incapable of creativity. They're trying to guess what you're trying to get at based on what they've seen before, essentially.
And that means that if you want to configure a WordPress plugin, they might be able to actually automate that entire thing very, very well. But most software is not that.
most softer is not predictable most softer is novel in the sense that you're doing something in a context in which it might have not been made before or rather the combination of small things you're doing is novel I can't see a startup being completely specified, implemented, figured out first, a month later, by AI at this point.
So I agree with you. I don't think that ultimately the improvement is as big as people claim it is. And where it is, it's in areas where, well, that wasn't consequential anyway. Yeah. So I think you make a great point about using an LLM to help with those requirements, help shape that. I see it probably making less difference there because that's the task nobody wants to do. Whenever I've...
come into an organization that's struggling with software development, immediately one of the first things they say is like, what are we trying to build? And it's like, well, there's a ticket over there and the ticket says build thing. Well, what are the details? Oh, I don't want to do that. Can't just build it.
Nobody wants to sit down and figure out requirements. Nobody wants to put it. So the LLM, yeah, you're right. I think they could really help there. But it still needs a human to sit down and go, I'm going to do this. And nobody likes writing requirements. Nobody really wants to do that.
So I think people will keep avoiding it. They do. They do. A small secret. Back when I was a solution architect, my party trick was I would... this didn't really work so well remotely over zoom but in person it worked great so whenever we traveled to see a customer we would say hey special occasion we're all traveling so why don't we get together
you know somebody from development somebody from product somebody from copywriting somebody from marketing you know let's get together a bunch of people who are involved in this project not just the technical people and then we arrived a bunch of people in the room usually kind of bored
Like, why are we here? Why am I sitting across from a developer that I never see? And me and my colleagues, we would start by saying, all right, let's do a small exercise. And then we would write on the whiteboard. Who, what, why? So we start, what are we doing? And typically people can answer that. What are we doing? All right, great. Who are we doing it for? And there you see the first kind of puzzled looks. What do you mean? It's our customers. Okay, which customers?
What segments? Who's interested in this? Who's sponsoring this? Not just who's using the thing, but also who's sponsoring it. All right. Then the conversation starts. And then at some point you go, okay, so why are we doing this? And there you would get the widest spread of opinions. Developers think it's for one reason. Market people think it's for another. The copywriters, a third option.
everyone comes with a different view and when you sum it all up even though people might agree on the what and even there you have some spread um typically you have all this all these different ideas of why we're there in the first place. And getting that harmonized was typically a huge unblocker for that project, even if we never talked about Contentful.
Just getting answers for those three things that everybody agrees on is huge. And LLM is not going to do that. Yeah, absolutely. And this trend trying to get rid of managers and get rid of engineering managers. That's something that a good manager can do. They can start making sure you have those conversations. And you look at that big picture then. That's why we don't just want people getting code and we don't just want people.
voting on delivery we do need that time when you step back and think about it are we building the right thing for the right people for the right reasons to solve the right problem cool did i answer all your questions about ai I'm sure I might have missed a part of that. No, I think you did. I think you did. Yeah, that was cool. Thanks. The other thing I was going to mention there is, you know, I totally agree by the nature of the way that our homes are built.
They can't lease them. They can only reproduce stuff that they've been trained on. So that's another problem that faces them replacing software engineers. How will they tackle novel challenges? I mean, set aside that actually most of what we do is novel, because if it wasn't novel, hopefully you'd buy an off-the-shelf solution. So most of what we do is novel, but not necessarily technically novel.
And again, that's something that we forget is people are very dismissive. You just build another CRUD app. Pretty much most of the things we build our CRUD. We're pushing data down in computers. What that data represents and the business process it represents or how we're using that is where all the novelty is. It's very rare that we're building some genuinely novel technology. Mostly we're getting data in, doing something to transform it.
sending out. Yeah, definitely. Again, I think an LLM will not be able to model data for problems that it hasn't seen before. It can save you some time if you're on... cursor and you're saying hey i want a product entity all right it's going to give me a product entity with skew and name and stock and all those things but then maybe i'm actually building um a way to to manage stock that's more efficient than than
what already exists, and then it's going to completely choke because it doesn't know what to do. So I have to commit. So I do like cursor, by the way, I do use it a lot. I think it's really great for like exploring things, for exploring new approaches. It's almost like a search engine that's plugged into your code. in that way, and it automates some of the most boilerplate-y sides of things, which is nice. But I can't tell Cursor, hey, build me...
I don't know. I can't tell cursor, build me Terramate, which is the company where I'm right now. And it's not going to do that, right? Not at all. Yeah, absolutely. I've been using JetBrains' IDEs recently and their AI solution. It's noticeable. I'm having a lot of fun revisiting university days and building compilers and interpreters at the moment. It's noticeable when I go through some of the recent books I've got examples in, and I reproduce their code.
It's seen those before, so it produces the exact code, automatically. When I build something that's mine, that's different, it's still trying to produce the same code. It's trying to produce what it's seen before. And when you've got something that literally has come out of a book, it's got it word for word or line for line for the code. So it's really just doing quite comprehensive and powerful pattern matching, but ultimately matching.
yeah and you can build those you can use those things as building blocks for something that is novel i mean like i i am i'm working on this kind of side project for fun at night which is like a back end that does a million requests per second on a single computer. And it's not magic. All it's doing is just not talking to the database. That's all. It just keeps everything in memory. That's the secret. But for example, I kind of know the things that go into that.
But I'm using Go and I know Go well enough, but I don't know every little detail about Go. So for example, if I need to journal everything that's happening to the hard drive. I'm like, okay, I'm actually not super familiar with all the details and all the flags and all the things that you pass into the function calls so I can prompt it and say, hey, I have this data. I need to stream this to the hard drive.
and i need it to be like as fast as possible and then i can have like a dialogue where it's giving me some options and i say not fast enough okay optimize this not fast enough optimize that and that's productive that's that's cool that's like having a little assistant that can't understand the whole thing but can help you a little bit with the details that is productive i find especially when you're not super familiar with the language but if you are well also
The trouble there is that if you're not familiar with the language, then you're kind of trusting what it's telling you. And that is also its own problem because you do have to stop and go and say, okay, I'm getting the result that I want, but.
In what ways is this having some side effect that I'm not thinking about? So now I actually have to stop and review my own code or review the LLM's code, which at the end of the day, if you think about the total cost of ownership of an llm powered uh development workflow that has to factor in as well so it helps you to prototype stuff but i don't know that it helps you so much with getting stuff to production that is reliable and well designed then we're kind of back to that meme aren't we where
I can't quite remember how it goes, but something like, I copied a load of stuff off Stack Overflow until it worked. Don't know what the code does, but I've got all these things, I'll Stack Overflow. And I think that was a meme like 10 or 15 years ago before we started. Having the equivalent for AI. Cool. So we've gone well over an hour, Pedro, so I've taken up a lot of your time.
Any final thoughts? Anything else you want to share? I think we went through so many different topics. I think the main thing is that I think you and I agree that to be successful, to have an impact, invest in your soft skills, right? If you want to give the audience some advice, because you can always, you can always learn the technical stuff, right? Like when I'm hiring people, I want them to be at a certain level and there are technical tests that you can do for that.
which is its own topic. Let's not get into that one. But you can examine somebody's skills. But even if they don't have everything, that's fine because they can learn. What I really... pay attention to is the soft skills. Are you clear in your thinking? Are you communicating with me proactively? Can I understand you? Can you understand me? Can you give examples of situations where you were taught somebody
or, you know, a good citizen of the team, not just a coding machine. So soft skills, extremely important also to get promoted. I'm sure you've seen me say it, but I think hard skills are a hygiene factor and soft skills are what. take you beyond senior level and the other thing about that is again a lot of the technical skills if you have good fundamental knowledge you can pick up most technical skills to a reasonable level quite quickly
Soft skills can take years to pivot, and I don't know about you, but I'm still learning. I'm still working on this. Oh, same, same. Cool. Thank you very much, Pedro. Thank you, John. It's been a pleasure to be here. Thanks for having me.