Software Engineers are Paid to Solve Problems, Not Write Code! | John Crickett

Summary

Scrum Master Toolbox Podcast: Agile Storytelling from the Trenches

Episode: Software Engineers are Paid to Solve Problems, Not Write Code! | John Crickett
Release Date: May 6, 2025
Host: Vasco Duarte
Guest: John Crickett, Software Engineer and Leader

---

Introduction

In this insightful episode of the Scrum Master Toolbox Podcast, Vasco Duarte engages in a profound conversation with John Crickett, a passionate software engineer and leader dedicated to empowering one million engineers and managers. John shares his experiences, challenges, and philosophies on the true role of software engineers beyond mere coding.

---

Empowering Engineers and Managers

John begins by discussing his initiative, Coding Challenges, a platform he developed to help engineers learn new programming languages through real-world projects. He emphasizes the importance of hands-on experience over traditional coding exercises.

[01:58] John Crickett: "You learn it by building real-world software."

Additionally, John runs a newsletter titled Developing Skills, focusing on soft skills and leadership, highlighting his commitment to holistic professional growth.

---

Solving Problems Over Writing Code

A central theme of the episode is the fundamental misconception that software engineers are primarily paid to write code. John argues that their true purpose is to solve real-world problems for users.

[03:56] John Crickett: "We're not building software because they want to look at the code... we're solving a problem."

He notes that many engineers derive excitement from building and creating, often overlooking the broader impact of their work on users and businesses.

---

Historical Context: Engineers and Customer Interaction

John reflects on the traditional isolation of engineers from customers, a practice rooted in stereotypes of engineers as unapproachable or overly technical individuals. He shares his transformative experience with Extreme Programming (XP), which advocates for close customer collaboration.

[06:17] John Crickett: "The software team were in the basement... kept out of sight."

Through XP practices, such as having customers "in the room," John experienced firsthand the benefits of immediate feedback and rapid iterations, significantly enhancing project outcomes.

---

Extreme Programming and Customer Collaboration

John elaborates on the XP principle of having the customer as an integral part of the team. This approach fosters real-time communication, ensuring that the developed software aligns closely with customer needs.

[10:05] John Crickett: "Having the customer as part of the team... you can have that conversation and iterate."

This methodology contrasts sharply with traditional approaches where requirements are static and often misaligned with actual user needs.

---

The Impact of AI on Software Engineering

Addressing the rise of AI in coding, John expresses skepticism about AI replacing software engineers. He acknowledges AI's ability to handle straightforward coding tasks but emphasizes that understanding and solving complex problems remain irreplaceable human skills.

[13:44] John Crickett: "I don't believe AI will ever replace software engineers... because we still have to tell it what to do."

He argues that AI lacks the nuanced understanding required to capture and address the intricacies of real-world problems fully.

---

Shifting Focus: From Coding to Problem Solving

John advocates for a paradigm shift where engineers prioritize understanding the problem and the business context over merely writing code. He draws parallels to carpentry, where the focus is on the final product rather than the tools used.

[19:31] John Crickett: "It's about solving those problems. The value is in the solution."

This approach ensures that the software developed delivers genuine value to users, aligning with business objectives.

---

Hiring Practices: Valuing Domain Knowledge and Soft Skills

John critiques current hiring practices that prioritize technical skills over domain knowledge and soft skills. He argues that leadership roles, such as CTOs, should focus on strategic understanding and customer engagement rather than specific programming languages.

[25:50] John Crickett: "CTO is a strategic call that involves talking to the customers, understanding the strategy..."

He emphasizes that organizational values and effective problem-solving stem from leadership that values these attributes.

---

Encouraging Curiosity and Cross-Functional Interaction

To foster a problem-solving mindset, John encourages engineers to cultivate curiosity and engage with various departments within their organizations. Building relationships with sales, marketing, and executive teams enhances understanding and collaboration.

[29:48] John Crickett: "Go and talk to the head of sales... they're very happy that a software engineer is interested."

This interdisciplinary interaction builds trust and facilitates better alignment between engineering and business goals.

---

Overcoming Introversion in Professional Settings

Being an introvert himself, John shares strategies to engage effectively without overwhelming social interactions. He highlights the effectiveness of one-on-one conversations and genuine interest in colleagues' roles and challenges.

[32:03] John Crickett: "I'm still very happy to go and talk to anyone... I'm fascinated by people."

This approach not only aids personal growth but also strengthens team dynamics and mutual understanding.

---

Recommended Resources

When asked about resources to aid the transition from coder to problem solver, John recommends a Harvard Business Review article titled "The Surprising Power of Questions." He underscores the significance of asking insightful questions and genuine listening as foundational skills for effective problem-solving.

[35:23] John Crickett: "Be curious and ask more questions."

---

Conclusion

The episode underscores the vital role of software engineers as problem solvers rather than mere coders. John Crickett's experiences and insights advocate for a more integrated, customer-focused approach to software development, emphasizing the importance of understanding the problem domain, fostering cross-functional collaboration, and valuing soft skills in technical roles.

---

Notable Quotes:

• John Crickett [03:56]: "We're not building software because they want to look at the code... we're solving a problem."
• John Crickett [10:05]: "Having the customer as part of the team... you can have that conversation and iterate."
• John Crickett [13:44]: "I don't believe AI will ever replace software engineers... because we still have to tell it what to do."
• John Crickett [19:31]: "It's about solving those problems. The value is in the solution."
• John Crickett [25:50]: "CTO is a strategic call that involves talking to the customers, understanding the strategy..."
• John Crickett [32:03]: "I'm still very happy to go and talk to anyone... I'm fascinated by people."

---

Connect with John Crickett:

• LinkedIn: John Crickett
• Coding Challenges: codingchallenges.fyi
• Developing Skills Newsletter: developingskills.fyi

---

This summary captures the essence of the episode, highlighting the key discussions and insights shared by John Crickett. By emphasizing problem-solving, customer collaboration, and the importance of soft skills, the episode provides valuable guidance for software engineers and managers aiming to enhance their roles within their organizations.

Transcript

[Vasco]

Have you ever wondered what it really takes to make Agile work well? At the Global Agile Summit, we're bringing you real life first person stories of Agile succeeding out there in the real world that will inspire you to take action. Whether you're a leader, a product innovator, a developer, you'll hear practical insights from those who've done it. They'll be telling their own stories from the stage. I'll tell you more about this at the end of this episode. So stay back and listen to the full detailed description of what we have in store for you at the Global Agile Summit. But if you can't wait, you can go right now to globalagilesummit.com and check out our full schedule for now onto the episode. But I'll see you at the end of this episode with more details on the Global Agile Summit. Talk to you soon.

[Host]

Hello everybody. Welcome to this very special bonus episode. And joining us today is John Cricket. Hey John, welcome to the show.

[John Cricket]

Hi Vasco, thanks for having me on.

[Host]

So, a little bit about John. He's a passionate software engineer and leader on a mission to empower, as he says, one million engineers and manager. He'll tell us a bit more about that in a second. With extensive expertise in distributed systems, full stack development and evolving tech stacks from C to Rust, John creates innovative coding challenges, insightful articles and newsletters to help teams level up their skills. Today we're going to explore a message that John shared on LinkedIn that I think needs more attention. But before we do that, John, tell us a little bit more. How are you empowering 1 million engineers and managers?

[John Cricket]

Cool. So I am doing that with a new site I started called Coding Challenges. Terrible name that I chose thinking I was being clever with alliteration. But it's confusing because it's not coding challenges, it is real world projects that you can use to learn a programming language. These are 20 and I've used them to learn C, Visual Basic, Perl, Python, Go Lust, and all sorts. I'm terrible at coming up with ideas to learn new languages. I picked projects I could do. I have created compression algorithms, I have created a clone of Redis, I created a clone of memcached. So picking real world applications, reading the specs, building something that's compatible with it as a way of having a project to actually learn a programming language. Because I don't think you can really learn it by just writing a function or doing a leetcode style thing. You learn it by building a real world software. The other side of that is I have another newsletter which is focused on soft skills and leadership. So I coach and mentor people in those areas as well as I've led software teams for many years too.

[Host]

How's that second newsletter called?

[John Cricket]

It's called Developing Skills.

[Host]

Developing Skills. All right, we'll put the link to coding challenges and Developing skills on the show Notes. Make sure everyone can easily find it. But John, in your post you hit on something fundamental that so many software engineers and I would even care to venture. Also engineering managers seem to miss is that we are not paid to write code. We are paid to solve real world problems for people that care about having those problems solved, of course. So let's start there. Unpack this idea. Why do you think this is a basic truth that is still misunderstood or even missed completely by engineers and managers alike?

[John Cricket]

I think it's missed by so many people because we, a lot of us come to software engineering because we like building things, we like creating stuff. That appears to be the fun bit. So it's where we perceive some of the value, is where we get the excitement. And a lot of managers have come from that technical background and a lot of people have misunderstood a lot of Agile, shall we say. And maybe GEO is partly to blame for this in that we suddenly have all these tickets and progress is closing a ticket. So it looks, it's almost gamifying in a way. It seems like we're making progress if we close those tickets and we've misunderstood the point that it was we are solving a problem, we're working with a customer to take away a pain point for them. So maybe that pain point isn't a huge pain and maybe it's they want to invoice a customer for something. Maybe it's they want to automate a process because it'll be smooth when they can do a higher value activity. But in every single case, we're not building software because they want to look at the code and they're going to go, hey cool, you wrote me some code. This is exciting. It's hey cool, I can now do something higher value. I can address this issue. In the business, a lot of us forget that we focus on the code, which is what we wanted to do and build. Forget that somebody's going to use it and it's there to solve their problem.

[Host]

Yeah, absolutely. One of the, I think consequences we can take from that is that once we realize that we're actually there to solve a problem, we need to start by understanding the problem first. So what are these maybe beliefs, assumptions, expectations that you think hold engineers back from seeing their roles and of course, then taking action on this problem solving, first problem understanding, then problem solving aspect of software development.

[John Cricket]

I think part of it is that we have, we have over the years, insulated people from dealing with customers. So when I first started nearly 30 years ago, there was this stereotype of engineers as being uncouth, nerdy people that you locked in a cupboard and didn't let them talk to customers because they'd scare them. They talk about scaly things, about bits of.

[Host]

They were famously in the basement.

[John Cricket]

I mean, literally the first company I worked for, that's where the software team were, in the basement.

[Host]

I know.

[John Cricket]

So, yeah, absolutely. It's like that there are people you kept out of sight. You didn't have to talk to customers because they'd be grumpy and grizzly and unfriendly and they talked to customers about things that didn't matter. So there was this perception that they weren't safe to do that. And I think it's very stereotypical and it's unfortunate. And one of the things I loved when I first learned Kent Beck's extreme programming explained was it like, hey, we need to talk to customers. And coincidentally, at the same time, the project I was working on then, and for one, just before I'd started to be involved in talking to customers, I was working at a software consultancy and I'd ended up working closely with one of the sales guys, mainly because I was just off charge at the time and they want a dog's body. I ended up being helpful and I'm curious, I asked questions. So I said to the sales guy, why are we doing this? What is this OJ notice thing you're doing? And I asked questions about it and he was quite surprised. Software engineer was taking interest in it. So he started taking the sales meetings. He got me involved in making bids and proposals. And then some of those projects I then worked on and delivered the software for. So started to get me exposure, that. And see, there's a bigger picture. And a lot of times we're abstracted from that because no one else around me was taking that kind of interest. So that opened up to it. There's that perception that we're not safe to be. And then there's the fact that, as I said, many of us are builders. We want to build a code. Again, being perfectly honest here, I don't want to stereotype. I mean, perfectly honest. I became a software engineer because I didn't want to talk to people. I'm an Introvert. I enjoyed building things. I've been writing code since I was nine years old. I wanted to sit in front of a computer and build cool stuff. A lot of us are like that. We don't want to until we express that curiosity, until we realize that there's a bigger world out there and there's a context. And like I say, when I came across Extreme Programming explained, I'd had a bit of this experience talking to the customer. So Extreme programming explain really resonated with me. And I think, hey, yeah, we need the customer on board, we need to be involved in that. We need to start understanding that domain. And I was then on a bigger project, I had a customer involved and there was no way we could build that software system, which was a layerway signaling system, without the customer involved. I mean, there are not many software engineers know how their way signaling systems work and even fewer that will know that specific one. So we had to talk to the customer, ask them questions and really get to know it. And again, I'm curious, I started to find that fascinating And I see a lot of us again, we're focused on the frameworks, we're focused on the technology instead of that.

[Host]

Yeah. And when you say frameworks, you mean technology and process frameworks?

[John Cricket]

To some extent, yes. Some extent. So for Flint and people, it may be they get real interest in React. For backend people, it might be they get particularly interested in say Flask or Fast API and some of those things if they're Python developer. For some of us we might get really interested in Extreme programming or Scrum or Kanban or some kind of process that you're using there. And we, we can then get quite easily. And again, with technical people, we like building things, we like structure. It's very easy to get obsessed by that and focus on that.

[Host]

Yeah, one of the things that, I mean, you mentioned XP or Extreme programming and XP had kind of a concept in its original description which was customer in the room. Right. And for those of us who haven't perhaps read the book, explain that to us. What was that concept from xp Customer in the room.

[John Cricket]

So I haven't learned the book for a few years. So my apologies to Kent Beck if I misrepresent this and get this wrong. The concept of as I've understood it and I will applied it is literally having the customer as part of the team. Say the project I was on at the time, a couple of customers, it was a foreign company we're dealing with, a couple of customers had flown over and moved to the UK for six months and were coming to our office every day and being part of the team. So for a period of time when I was working on stuff that needed their input, I literally sat next to the customer and asked them about their job and talked to them and showed them the work we're doing when we collaborate. And that was so powerful because you get that rapid feedback, you get that immediate response from them. If you have requirements that weren't clear, and let's face it, requirements are never perfectly clear. It's really, really hard to write down your requirements perfectly. So if you can write them down as a, you know, we need it to do this, we need to better set these points in a signaling system. When you then go and go, well, what does that mean? What are points? What do you mean by set them? When the customer's right there next to you, you can turn around, have a conversation, draw on a whiteboard, have that discussion and it's so, so powerful because you've got the rapid iteration. And part of that project I worked on the signaling control room software. I actually sat with the customers and mocked up the GUI and built parts of it with them and had the chance to play with it. So that customer in the room is so powerful, you get the understanding what they do, they can look at it and give that immediate feedback and you can iterate on those designs, you can iterate on what it's doing. And then it became all about the problem. They didn't care about the code, they didn't care about what we're doing, but they cared about the result. And they could immediately see that and they could feedback on. Actually now we've seen that it's not going to work. And that's so different from previous projects where this was early in my career. So I can't say for years I've been. But I've spent a few projects where we spent six months building it. You went to the customer and ta da, that's not what I meant exactly. And then that's great.

[Host]

Not what I need.

[John Cricket]

Yeah, there's that immediate disconnect and disappointment where because they were there next to you as you were doing it, you say huh, so like that. No, no, no, no. And move this over there, do that over here. Actually, now that I've seen that. No, that's not what I meant. Well, that's what I said I wanted, but now I've seen it, I don't want it. So you could have that fast feedback and iteration. And again, that was everything I Loved about XP from the test, first development, the iterations and keeping it short, having the customer room, it was that fast feedback. So you never went too far off track. You didn't, as I say, get to that six month point where you show the customer and they're immediately disappointed. Because if you show the customer and disappointed, you'd done 20 minutes work and they went, oh, that's not quite. And you corrected it and you adjusted so you didn't have that disconnect. So I think it's so powerful and I would love a work with a customer in the room.

[Host]

Yeah, absolutely. And it's powerful, of course, because of the quick feedback, but also because the customer has a perspective on what needs to be delivered that we can never have if we just read, you know, used stories or, or requirements or something like that. But there's another aspect which I think is interesting to explore. You also claim something else in your post. You claim that engineers who see themselves only as coders will quickly and easily be replaced with AI. So what does that mean? Like, what do you mean when you say that engineers who see themselves only as coders risk being replaced by AI?

[John Cricket]

So everyone is talking at the moment about vibe coding, about AI's ability to generate code. I'm more skeptical than most about that. But sure, if you say give me a search routine or wipe this function and you give that to an LLM, it will produce some code for you. As we've seen from some of the vive coders, that code sort of works. People will take it. If all you're doing is taking a ticket that's fairly simple that somebody else has done all the analysis on, boiled it down and boiled it down to. These are the three steps. Check this out at the end then. Yeah, you can feed that into now and get some code that will sort of work. If that's all you're doing, AI at some point will become good enough to replace you. I don't believe AI will ever replace software engineers, no matter how good it gets in a way because we still have to tell it what to do at the moment. All the people are pushing that will type English or some other natural language into the AI and it will produce the code. I do not know anyone, I've not met anyone in 30 years of software engineer that can sit down and write the perfect requirements document that covers all the nuances given. We still haven't mastered that. And people have been trying for, I don't know, 40, 50 years to work out how to write good requirements. I Can't see that ever being that AI can do it all because, say, it's very, very difficult in English or any other natural language to specify precisely what you want the software to do and to cover all the.

[Host]

And if you could do that, it could probably just be compiled, right?

[John Cricket]

Exactly. So we have invented computing languages to be more precise. And I point out that again, in mathematics or in science, they have specific notations because they can't use English for mathematics. It's too imprecise. We have specific scientific notation which has a very specific, clear and unambiguous meaning. The only way we get that is by having our own specific notation and language. So maybe one day we could all evolve to a one programming language that the LLMs can produce that can be compiled. But I think we're a long way off from being able to either, as humans, clearly specify in a natural language to the LLM what we want, or have the LLM in any way understand. Because LLMs, again, they're not reasoning, they don't understand, they're producing the statistically likely next tokens from that. So we're not going to get to that point for the simple challenges that it's very, very difficult being unambiguous in a natural language.

[Host]

But it does. I mean, your statement about the if the only thing you're doing is processing tickets that have been fully specked out, it also gets to the point, or at least I think as I read it, what comes to my mind is that, okay, we need to think of, as we started this conversation, we need to think of software as a tool to build solutions, but where the value is not in the use of the tool is in what leads before the use of the tool. Right. Like understanding the business problem, understanding what the customer is trying to do, build that feedback cycle, get that iteration like XP suggests we do with the customer in the room. So that's, if I understand your point, and at least that's my perspective, the value moves to that aspect of the work, the value moves to the customer interaction, problem, understanding part of the work. And there's still value in the coding. But a lot of the coding can be done by LLMs if we have been able to understand the problem and so on. So if we can put those two together, so understanding the problem and writing the code, then we can also use AI. I mean, any programmer can use AI to help speed up the process, but the value is in understanding the problem and being able to validate that the solution really tackles that problem.

[John Cricket]

Is that what you mean? Absolutely. I think the value has always been in understanding the problem. And it has always amazed me throughout the years when I've worked with engineers in different organizations that they haven't taken more of an interest in the domain they're working in. They haven't seen the value of that. And it still amazes me that on the flip side, companies don't recruit for it. Now, about 15 years ago I worked for a couple of finance companies in the City of London and it amazed me to go into that domain and find that people working in financial pricing, for example, that had no idea what an option was, that barely knew what FX was and this is the basic domain knowledge. But it meant that they were stuck at a mid senior level because they couldn't progress in their careers. Again, not understanding the domain because to move forward and to start adding value to organization, they had to have that domain knowledge. They had to be able to understand what problem we were solving because producing the code was relatively low value. Again, you take a different example. If you hire a carpenter, say to come and fit a new door in your house, you're not going to watch and care about how they use a chisel or hammer or screwdriver. You want the result, you want the door, you want be able to go in and out of room and close the door and have some privacy or whatever you're trying to achieve for that goal. You care about the solution to the problem. You are not interested in the wood shavings he does and how he planes or chisels it and so on. So it's about solving those problems. And that's where the value is.

[Host]

Yeah, absolutely. That's where the value is. That's very well said. Now let's take that challenge of understanding the, the domain or the context forward. And when you, when you work with engineers specifically, but also their managers, what steps do you go through with them to help them get ready for that? Right, like get ready to understand the business context, get ready to understand the customer problem, get ready to understand the domain they're part of.

[John Cricket]

So I've always tried to encourage people to be curious and to think about. We are, we're not here to produce code, we're here to produce a solution to a problem. We may do that with code, we may not. This may be times when we actually turn and say, why do you need to do this? You can use Excel for this or you can use some other tool for this. Go away and do that. Let's spend our limited ability to produce software on something that you can't just pick up off the shelf. So there are times when we've gone there and pushed back and said, we don't need to build this, you can go and buy it. Let's spend our limited ability to build software on building something that adds more value. Again, stepping back from things, we're going to look at things in a different perspective and say, well, what actually is the problem we wish to solve? What would a solution look like? How would we approach that? Again, sometimes it means that we build code, sometimes it means we integrate an off the shelf system. Sometimes it means we say, actually that's not necessarily what we want to achieve. We could do something different. Again, one of the things you have missing if you just take requirements off people and you just fill in tickets, is that you will get somebody that comes along to you and says, I wanted to do this, but they're telling you what to build. Well, if you go and talk to them afterwards, you find out that actually they were trying to solve this problem and they've tried to design a solution, but because they don't necessarily how to, they've told you this wrong solution to build. Whereas if you go and talk to them and ask questions, say, okay, what is the problem? Why are you trying to solve this? What would a good outcome look like that then might drive you to saying, well, your problem doesn't need that. You know, Again, Henley Ford allegedly put this differently, that if he asked his customers what they want, they'd have told him a faster horse.

[Host]

A faster horse.

[John Cricket]

Yeah, that's not really what we're looking for. We're looking for people wanting the ability to move more stuff or to move it faster. Again, if you start looking at that, that's a completely different issue. And again, I started my own business in 2001. Unlike many software engineers, I'm an introvert. I have no interest in sales. So I, being a bookworm as well, I went on Amazon, bought a whole bunch of books about sales and started to learn how to do it. One thing that really struck me there is there's an example in a lot of sales books, somebody working in a hardware store. And so if somebody comes in and says, I want to buy a drill, that's not true, they are doing something. And if you talk to them and say, well, okay, cool, why do you want to drill? Oh, I'm putting up some shelves. Awesome. This is the kind of drill you want. And what are you putting the shelves up? Are they going into wooden wall? Are they going to dry wall? Are they going into brick. Okay, so you need these drill bits. Okay. And then this shelf. How are you going to hang it? All right, okay. So you might need these things. So instead of just selling them an electric drill perhaps, which might be the long thing, might be underpowered, might be overpowered, what they want, you turn the sale into. Actually, you want to drill, you want these drill bits, you want these things to hang your wall. And again, that was all about sales. But it's a great lesson for this that you, instead of being somebody that takes orders, is your drill. You turn into a consultant, you turn into an expert that's helping somebody. We could even say, yeah, exactly. And next time they've got a problem, they're going to come back to you and say, hey, my shelves are awesome. Thanks so much for the help. I'm now doing this project. How do I do it? This is what I'm trying to achieve. What do I need to buy? And in the sales concept, you're now able to sell them more and be a better salesman. And you're not being a sleazy salesman, you're being a consultative salesman. You're helping them solve their problem. And I really like that analogy because I think that's exactly what we should be doing as software engineers. We should be talking to that customer and saying, well, what are you trying to do? Okay, cool. Here are some of the tools we've got. This is how you could solve that. This is something. Which one of those would look good and how many users have you got with your software, how concurrent you need it to be? What's the.

[Host]

How is it going to affect your business if this works?

[John Cricket]

Well, yeah, absolutely. And we can start identifying that. But it all starts from being curious and being interested in the customer and looking to understand that domain. And I think a lot of software engineers, we miss out the value of that domain knowledge and a lot of engineering managers, because they haven't been through it, miss it out in hiring it. One of my big pet peeves and rants that I've posted about again in the last couple ofdays on LinkedIn. So I keep seeing CTO job adverts and keeping sent them by recruiters that start off with a list of skills, saying this CTO needs to know php, lala bell and blah this beat. I even saw one the other day, which is a go cto. I'm sorry, but CTO is a strategic call that involves talking to the customers, understanding the strategy, talking to the executive and understanding what the business is trying to achieve. And what the customer is trying to achieve. That requires domain knowledge. It requires the ability to talk to the cfo, talk to coo, talk to the cmo. It doesn't require expertise in php. If you want someone that's a PHP expert or golang expert or C expert, you hire a senior software engineer or lead software engineer, whatever level you want. And that's great. Maybe they'll grow into the CTI in the future. But they're very, very different roles. And when we keep recruiting for people, a shopping list of technical skills and we miss out soft skills, we miss out the domain knowledge, we miss out the commercial skills and the awareness we create, stacking up problems, and then we keep perpetuating this problem.

[Host]

And that's actually the question I was going to ask you next. Because of course, engineers that have the perspective that they are only there to code are hired by someone, right? Typically the hiring manager, engineering manager, maybe some cto. So how do we help people that are in this position? So CTO, head of R&D, VP of engineering, to hire the right people. So what is the advice you give these people when you're talking to them about, you know, phrasing, shaping the interview so that we actually end up hiring software engineers that want to solve problems, that want to be curious about the customer problem and the domain they're part of?

[John Cricket]

If I'm honest, I think that really actually starts with the CEO and whoever hires the cto. Start hiring people that understand that the job of a software engineer is not to write code, because code is always a liability, sometimes it's an asset. Start hiring people. Understand that your job is to minimize your liabilities and maximize the assets. We do that, as we said, by understanding the customer, by producing the minimum liability we can, and by ensuring that what we are producing is creating value, adding to the outcome. If you get the CTO that understands that and can communicate with the rest of the board with their first team, which is the executive team, they will then be able to talk to everyone beneath them about what is valuable, why are we producing it, they will then be able to bring that domain knowledge and pass that down through the organization. Because it all starts at the top. It all starts with the leaders. And if you hire that CTO for a bunch of technical skills and not the domain knowledge, not the strategic knowledge, not the ability to speak the language of the business, then they will shape the organization around them and beneath them to reflect them and their values. It starts at the top and you get the team that reflects your values, so you need to make sure your executive team starts and has the right values. If you're not at that level and you're just an engineering manager, then you can start working up and being curiosity, manage up list. Try and understand what are the values that the organization has. Try and reach your. You don't just talk to say your senior engineer manager, your director or your vp. Try and talk to people that are adjacent to you. So if you have a good team, talk to your product owner, try and talk perhaps to their manager, try and reach out, maybe talk to somebody in marketing, talk to somebody in sales. And again, so many of these people are amazingly happy to talk to software engineers. Again, in my first role, as I mentioned, I worked directly for that senior sales champ. I also knew all the directors of that business by name and I talked to them and I had a very good understanding of what the business was doing, what it was not because I meant it think special, just because I drink a lot of coffee. We were in the office in those days the office was relatively small, couple hundred people. So there was one kitchen. When I went to the kitchen and I saw the managing director or I saw one of the founders of the business, I said hello, I said good morning, I said what's new? And I asked questions and I was curious. Very often those executives were happy to sit and talk to a 21 year old junior software engineer and were delighted that somebody was interested in how the business was doing and what we're doing and why we're doing it. I literally had multitude of coffee chats with these people because I just bumped into the kitchen and asked questions and they taught me so much in that first organization and I just carried on doing that in other companies. Go and talk to the head of sales more often than not they're very, very happy that a software engineer is interested because they want to achieve their sales targets. They can do that better if they understand what we do. They can do that better if somebody in the software team can talk their language and understands them.

[Host]

Yeah, absolutely. And that's a very good point, that the curiosity is not just for our own purpose, but because it also helps others to share what they need to share. Right, like because of course leaders and managers, they need to share that vision, that goal, that overall business setup that we are there to enable and they are happy to do so. Of course, if we do it politely and with curiosity.

[John Cricket]

And it builds trust. And it builds trust, some interest. So in a couple of the organizations, as I did this, I found that salespeople started Coming to me and asking about features and we've all, I'm sure, experienced a cliche where you guys sales have told them that we can do it next week and it's going to take a year to build this feature. Well, again, a lot of the time it's because there's a disconnect. The sales can't talk to engineers. They feel a bit frustrated. So in a few of those organizations, by being interested, by being talked to them, I built a level of trust so they would come and ask me some questions. So it gave a chance for me and my team to actually be involved in that dialogue earlier and avoid some of those disasters, provide some feedback. Not saying it was perfect and that we didn't have disasters because salespeople are still enthusiastic and also they want to make a sale. That's what they're motivated by. But at least we had a better dialogue and we avoided some of the worst scenarios. Or we got bought into it earlier so again we could be involved. Or I got taken to the customer and I could sit there and understand the customer better. And if the sales guy wanted to promise it in a month, I could talk to the customer engagement and say, well, that's really hard. What's the kind of 20% that would give you the 8% value that we could do in a month and we can iterate. So it's moved out a lot of those things again by being curious, by talking to people. And it really is that simple. Go and talk to people, learn their language.

[Host]

And this can be, I think a little bit threatening, especially for introverts like you and like you were and like many others of us are. So what got you off the bump? Like what, what was the trigger that helped you understand that? Actually you know this, yes, I'm still an introvert and I recognize it. But actually there's so much value and there's so much trust created in these interactions that I want to continue with it.

[John Cricket]

So I, I still am an introvert, but to me, and I don't know what the official definition of this, but my understanding is a lot of people's correct definition. A more correct scientific definition of introvert I believe is it's how your energy is affected. So I am still very happy to go and talk to anyone and I always have been, I'm not shy, never have been, go and happily talk to anyone one to one for hours. And I will enjoy talking to anyone and everyone for hours because I'm fascinated by people. You know, I don't care whether that was a janitor somewhere or CEO of a company. I will find something interesting to talk to them about and get to know them and understand them. And I've always enjoyed doing that. So that's never been a problem. One to one, but take me to a conference, walk into a room where there's 100 people, I can't stand it, I'm exhausted after five minutes I just really want to leave the room and don't want to be there. I find it very difficult to walk into a group and talk to, you know, five or six people and jump into that small talk where one to one, I'm absolutely fine. So again, the kitchen works perfectly for me there because you could walk in, there'd be one person making coffee or one person that sat on their own and so we could just very easily walk and talk one to one and have that human interaction. And again, it helped the that I've never particularly been intimidated by title, so I just regarded them as humans. And I have met very few people in life that weren't. In that case, if you went and expressed a genuine interest in them, they're delighted to talk to you. Yeah, sometimes people are busy so sometimes you know you're going to go and talk to somebody, say, hey, how are you doing? And I really saw it, I've got a call in two minutes, I've got a rush. You know, they're not being rude, it's just sometimes genuinely we do have meetings and stuff, so that's fine. You see them the next time and they might be free, but every single time. But just by being genuine, authentically interested in people, asking them questions, asking them again, if I'd seen them a couple of days ago, asking them a follow up, it's like, hey, you were going to talk to Custom Works last week about this project. How did it go? What was their feedback?

[Host]

Follow up is so important in.

[John Cricket]

Yeah, and it's showing that you've been listening, that you've been interested in what they said and you've been curious and that you weren't just going through the motions, that you listened to their point, you listened to their concerns, you listened to what was bothering them and you followed up.

[Host]

It's interesting. Like this conversation brings me to this reflection that has been there for a long time, that software development ends up being always a question about dealing with humans and dealing with other humans and also being a human with other humans. Right. It's about people working together and collaborating. Now if you would have one resource, John, to the people who want to understand more about how to make this shift from what we talked about from coder to problem solver, from being interested only in the solution to also being interested in the problem and the domain and the business that they are serving. What's one resource you would recommend?

[John Cricket]

I've thought about that and I I wasn't really sure to come up with so there is a HBR article. Let me give you the full title the Surprising Power of Questions. So doesn't quite feel that that's quite enough. I just want to say be curious and ask more questions but that HPI article might just give people enough the surprise and power questions just going asking good questions of people being interested and genuine listening and I don't know that you can teach that. It's not necessarily exhaust you want but just keep in mind be curious.

[Host]

Absolutely. We'll put the link to that article in the show notes so that people can easily find it. And how about you John? Where could people go to find out more about you and the work that you're doing?

[John Cricket]

So I'm easy to find on LinkedIn. John Cricket codingchallenges.FYI for the coding challenges and developing skills. FYI or lead.deverpingskills. fYI for developing skills. Again, they're all linked off LinkedIn.

[Host]

Absolutely. And we'll put the link to those also in the show notes and everybody reach out, ask a few follow up questions. I'm sure John would want to engage and give his answers and maybe other thoughts that he hasn't shared yet that relate to this challenge. John, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.

[John Cricket]

Cool. Thank you for inviting me on Vaska. It's been a pleasure.

[Vasco]

Hey friend, thank you for staying here is all you need to know about the Global Agile Summit. If you've ever suffered or know people who are suffering from agile fatigue, this event is for you. Agile fatigue is that feeling that settles in when we can't really see a light at the end of the tunnel. We get discouraged. Especially when conversations revolve around the same old frameworks, the same old buzzwords and theories. We don't feel that energy anymore. Well, the Global Agile Summit is a different kind of event. We're bringing you real life first person stories of Agile succeeding out there in the real world that will inspire you to take action and transform the way you work. The Global Agile Summit will happen In Tallinn, Estonia, May 18th. That's the workshop day. Then 19th and 20th the conference day And Tallin Estonia is one of the most innovative tech hubs in Europe. The Global Agile Summit is hosted together with Latitude 59, which, which is kind of a citywide celebration of software startups and groundbreaking ideas. And we'll have a shared ticket for you to attend those events as well. So who will be speaking? Well, we've got an incredible lineup of thought leaders in software and agile. For example, Clinton Keith, the person who wrote literally wrote the book on game development with Scrum and is busy bringing Agile to the world of game development. You must check his session. The very famous and well known Jurgen Apelo, author of Management 3.0, will be talking and exploring about AI's impact on leadership. We also have Goiko Adsic, who's taking an unconventional look at product growth with his Lizard Optimization keynote. Other speakers include, for example, Sixven Dietz, who's challenging everything we know about software development by ditching, literally ditching contracts and estimates. Can you imagine his teams deliver software before their competitors are even done with the contract negotiation? How agile is that? But there's more. We'll cover engineering practices in our developer track with talks on, for example, AI assisted test driven development, developing products in minutes with a different approach to how we develop, configure, deploy platforms, and much more. We also have a product track where we cover cutting edge ideas around product discovery, delighting customers with product delight frameworks. We'll have a talk about that. And we also have an Agile business track where we will talk about, for example, open strategy, a very agile approach to managing organizations, and delivering software faster to clients faster than you can even write a contract.

[Host]

Literally.

[Vasco]

I mean, I already told you about Svendeet's story is amazing. It definitely is a must see. I'm sure you'll be inspired and get a lot of ideas for your own software projects and software delivery. Now, whether you're a business leader, a product innovator or a developer, you'll definitely find value in our three focused tracks. That's Agile Business for those working with businesses and organizations, Agile Product for product managers, product owners and innovators, and Agile developer for the builders making Agile work in practice. The coders, the testers, the designers, the producers, the Scrum masters, you name it. If you join, you will meet over 200 agile professionals from all over the world. People who just like you, want to grow, want to share and want to learn by challenging the ideas that don't work anymore. At the Global Agile Summit, you'll get new connections, fresh ideas and the energy to take your own Agile to the next level. And who knows, maybe even find your next career opportunity. So don't miss out. Check out the full program and grab your ticket [e-mail] I'm really looking forward to seeing you all in Tallinn, Estonia in May. I'll see you there.