Kind vs Nice With Damien Ryan

Summary

Podcast Summary: The Godel Pod – Kind vs Nice With Damien Ryan

Podcast: The Godel Pod
Host: Michael Hammond (Godel Technologies)
Guest: Damien Ryan (Managing Director, Comore/Kova)
Date: July 5, 2023
Main Theme:
A candid conversation about the psychology of software development—exploring career progression, team dynamics, remote work, and the crucial difference between being “kind” and “nice” in building impactful teams.

---

Episode Overview

In this episode, Michael Hammond sits down with Damien Ryan to dive deep into the psychology of software development. Drawing on Damien’s wide-ranging career—from the “Stone Ages” of software through the rise of Agile, DevOps, and modern team structures—this discussion unpacks the persistent role of psychology in team and individual success. Central to the conversation is the distinction between being "kind" and being "nice," the impact of remote work on psychological safety, and practical advice for fostering healthier, more productive tech cultures.

---

Key Discussion Points & Insights

1. Damien’s Entry into Software Development

• Early Passion: Damien’s journey began with a love for science and video games. He originally envisioned a career in science, but was drawn to computer science due to its practical, tangible feedback.
  • “I could actually, you know, sit down at a machine, type something in and it did exactly what I wanted, whether it was right or not.” (02:52)
• First Jobs: Launched his career during the internet “bubble” in the late 90s, writing database queries before moving into more complex distributed systems work at Iona.

2. Changes in Development Practices Over Decades

• Technical Evolution:
  • Early days: “We built it on a single machine, zipped the files up, and emailed those files over to a customer who had to unzip them on their end…” (05:22)
  • Agile and XP: Encountered Kent Beck and the concept of “Extreme Programming” (XP)—a revelation that development should center on what customers want.
  • Rise of Automation: Shift from manual builds/installers to automated tools and DevOps, seeing software move from a “personal” to a “team sport.” (06:29–12:19)
• Team Dynamics:
  • “You’re never taught soft skills growing up... What’s really hard to learn is how do you have a conversation without knowing someone or how do you foster a sense of collaboration and safety in a team?” (13:56)

3. The "Kind vs Nice" Framework

• Defining the Terms:
  • Nice: Suppressing conflict to keep the peace, being superficially agreeable.
  • Kind: Actively helping colleagues be their best, including giving tough feedback for their benefit but in a humane, constructive way.
  • “Nice is kind of pushing things down just to get along. You might feel conflict…but you don't want to be mean.” (16:30)
  • “It's kinder to have a difficult conversation and, you know, get that out in the open…” (17:19)
• Why it Matters:
  • Kindness creates growth and trust; niceness can stifle progress and hinder improvement.

4. The Impact of Remote and Hybrid Work

• Personal Reflection:
  • “Lockdown absolutely broke me... I thought I would love being locked in the house... It took two weeks before I was almost screaming wanting to go back into an office.” (19:09)
  • Discovery of extroversion and the hard limits of virtual communication.
• Remote Work Realities:
  • Loss of “three-dimensional” interactions led to a “desert of empathy” and affected team safety and trust.
  • “While the productivity of individuals went up... the effectiveness of a team went down because we lost that psychological safety.” (21:52)

5. Essential Psychological Traits for Developers

• Curiosity: The single most important trait for knowledge work; being curious about customer problems, system integration, and broader impacts.
  • “Curiosity is your biggest friend. Because... you need to be curious about the customer problem, what they actually want to be fixed... think wider about the issues…” (26:38)
• Empathy and Communication:
  • True listening, open communication, and the willingness to say “I don’t understand”—critical for collaboration.
  • “None of us actually really listens when I’m talking… you’re sitting thinking, ‘What’s the next question?’... Which means that we’re either waiting to knock down a point or… we’re just not present.” (51:34)

6. Leadership, Growth, and Scaling Teams

• Managing at Scale:
  • Insights from working at Motorola, where understanding organizational psychology became crucial (“400 people... very hard for any one person to know what any one other person does.”). (32:04)
  • The importance of steering clear of process-for-process-sake, especially with methodologies like Scrum.
• Team Topologies:
  • How structuring teams around clear boundaries (with “Team APIs”) fosters trust, communication, and healthy “silos.”
  • “Empowerment on its own can create chaos… boundaries are super, super empowering.” (46:14)

7. Spreading Psychological Understanding in Tech

• Empathy in the Workplace:
  • “There’s nothing actually special about software developers as people. You understand psychology of the individual…” (48:04)
• Avoiding Stereotypes:
  • Developers are like anyone: motivated by problem-solving but susceptible to over-fixation, burnout, and imposter syndrome.
• Practical Advice:
  • Foster environments where asking questions is encouraged and rewarded.
  • Balance technical excellence with strong communication and collaboration skills.

---

Notable Quotes & Memorable Moments

• “It's kinder to have a difficult conversation and, you know, get that out in the open or kind of difficult feedback, but… it's not cruel to be kind. It's doing it in this human manner.” (17:19, Damien Ryan)
• “Meetings were very much literally 2D… we switched into that mode without knowing it. So… there was a, almost like a desert of empathy at the time where, yeah, we were all a little bit more ratty with each other.” (20:16 & 21:52, Damien)
• “Curiosity is your biggest friend. Because... the more curious you are at the start, the less likely that wrong is going to be.” (26:38 & 27:48, Damien)
• “If you think about the scales of people… trying to get that entire system in your head is very hard. And… learning about development as actually as a psychology game as opposed to building.” (32:04 & 32:36, Damien)
• “Boundaries are super, super empowering. Because the constraints are what allow you then to go off and do whatever you need to do within those boundaries.” (46:14, Damien)
• “There's nothing actually special about software developers as people. You understand psychology of the individual…” (48:04, Damien)

---

Timestamps for Important Segments

• Damien’s Early Career and Education – 01:40–04:19
• First Encounters with Agile/XP – 06:45–07:46
• Transition to DevOps and Automation – 10:10–12:19
• Team Psychology: Kind vs Nice – 15:46–18:02
• Remote Work and its Psychological Impacts – 19:09–24:55
• Key Traits for Developers (Curiosity, Empathy) – 26:13–28:27
• Scaling Teams and Team Topologies – 42:41–46:45
• The Role of Empathy in Tech Leadership – 54:56–56:08

---

Conclusion

Damien’s Final Words:
“This world is very tough, particularly now… The important thing is… being kind to each other. It's difficult. And when times are difficult, you need to remember that there is only kindness… being kind to myself is also just as important.” (57:20)

---

Takeaway

• True team effectiveness is rooted in psychological safety, honest feedback, and fostering curiosity.
• Choose kindness—not just politeness—especially in challenging times.
• Structure and boundaries empower rather than restrict teams.
• Great software is built by humans first—understanding, honest, and collaborative ones.

---

For more on team psychology and practical leadership in software development, Damien encourages listeners to reach out or explore resources like “Team Topologies.”

---

Transcript

[A]

Hi, everyone, welcome back to the Godell pod. I'm Michael Hammond, client director here at Godel and today I'm joined by Damian Ryan and currently managing director at Comore. Thanks very much for joining us, Damien, how are you?

[B]

I'm doing really good apart from this heat.

[A]

Yes.

[B]

Taking about seven hours from complaining about the cold to complaining about the heat.

[A]

It wouldn't be, wouldn't be very British of us if we didn't mention the weather straight away and the fact that it's warm. Yeah. So great. Yeah, it's nice to have a bit of sunshine, but it's been a little bit too warm of late. Obviously we're not here to talk about the weather, Damian, but basically I think the best way for us to go today we're going to do a bit of a talk about the psychology of development, Obviously a very broad subject, but your experience of this and you've got a very illustrious history in the software development, lots of different roles, but I think what we'd love to do is start at the beginning and if you could tell us where you initially got into the world of computer science and software development, where your love came from and where it all started, I think that'd be a good place for us to kick it off.

[B]

Right, so we're going back to the Stone Ages then. When I was thinking about university, about where I wanted to go, what I actually wanted to be was a scientist.

[A]

Right, okay.

[B]

So I went to the Dublin Institute Technology, which was. It started off as a technical college years ago, but then gradually, you know, built up degree programs and it was a place where someone from working class background who could actually go and get an affordable education in tertiary education. And they had, they ran this course in conjunction with Trinity College Dublin called Applied Science. Really what that course was is trying to develop scientists who were purely theoretical. They knew how the real world worked and how, you know, the sorts of shapes of people that companies wanted as part of this. They did physics, chemistry, all the other things. Then they had computer science and software engineering as options. Played video games all my life, you know, the computers.

[A]

Oh, something we've got in common already.

[B]

Shock. I know for, for someone of my shape, the computer science as part of that. And that's where my brain kind of went. Oh. Because I didn't have to do the really, really hard maths that physics needed. And don't even get me started in double integrations, I still don't understand it, but I could actually, you know, sit down at a machine, type something in and it did exactly what I wanted, whether it was right or not, but it did that.

[A]

I mean, everyone's got to understand the level of satisfaction there from that. I mean, I, I remember it from a young age, starting at a computer and just making a machine go 5 meters forward, turn left. You know that, that very basic stuff that you did. Yeah, that's it. Yeah. So that's that. That was. I mean, if that didn't excite you as a young, a young lad, then I didn't know what did.

[B]

Then graduated from there. 1998, which. Yes, the last entry. I know. And at the time around then, just before that, there's just at the, the pit, kind of the edge of when the Internet bubble and the web bubble was starting to come up. So I thought coming out, get a job in a manufacturing, planned writing database queries. The rest of my life would be nice. No, easy job.

[A]

Yeah.

[B]

Things exploded. So I went to work for a company called Iona, which, okay, very few people will remember, but they, they were an Irish company who floated on the NASDAQ stock exchange, and they were a huge success story at the time. And what they built was a Corba object request broker and framework for building distributed applications, which everyone does now. But at the time, there was no other way of doing this. Let's go back to that. I remember talking to a colleague a few years ago, talking about this and where I started. The guy turned around to me and said, yeah, I remember Corba from History of Computing class.

[A]

Wow.

[B]

And that's when I thought that's where

[A]

the name came from. Is this. So is this early 2000s then, Damian?

[B]

So this is. Yeah, late 90s, early 2000s.

[A]

Okay.

[B]

So development at the time was really. We had version control, but it was way before Git. That was even before subversion and all those things called clearcase. It was very complicated to get code into a big code base and it took a lot of work to get the right patches out to customers. We actually, you think about DevOps now, where you can deploy hundreds of times a day to get a patch out to a customer. We built it on a single machine, zipped the files up and emailed those files over to a customer who had to unzip them on their end and hopefully.

[A]

Yeah, it's. It's when you, when you paint it like that, you realize really how far we have come. I mean, I know there's obvious things that we look at around just your house to see how far we've come. But you know, when, when you think about the actual Developers behind the scenes who actually work on all these things, what they, how differently they had to do, do it. Goodness me.

[B]

So it was then, it was that as well. I mean there's none of this agile stuff. It was all. Everything was either waterfall or it was.

[A]

Yeah.

[B]

A bunch of developers hoping for the best to get some software out in the door.

[A]

Yeah.

[B]

Towards the end of my, my tour there then we're getting into the early 2000s. Still a baby developer, not really understanding a lot of how everything works. But Iona brought this fellow over from the US called Kent Beck. None of us have ever heard of them names probably familiar to yourself. But he came over and told us about this thing called XP where you actually ask the customers what they want and do what the customers want, which set up fireworks in my head. That's why we're here. Right, okay,

[A]

I like that.

[B]

So then around. Yeah, around the start of the 21st century. Yikes. The dot com bubble burst and a whole lot of companies, especially the ones who are reliant on us money went bust. There's going to be a theme here. Whereas I was one of the people laid off from my own at the time.

[A]

Right.

[B]

And then I did what most Irish people do is look to England and I'll come over to, to Cambridge for six months, see how it goes. So I got a job in a company called Acceleras and they did scientific modeling software on. On desktop with commission servers. Kind of fit in.

[A]

Well,

[B]

that was 20 years ago. So there's something about Cambridge and the ecosystem around Cambridge that just really holds on to you. It's a really nice place to live.

[A]

Yeah, yeah, yeah, absolutely.

[B]

Doorstep as around that time where I realized that I'm not the sort of person who likes to go in and tinker on the very edges of something and really get no good at one specific thing.

[A]

Yeah.

[B]

And it's more about the. How we make software and how we help developers actually be effective at what they do rather than having to work through heroics. We're already.

[A]

Yeah, we're already seeing a sort of a change in your psychology as a developer, aren't we? As you, as you've moved around. So yeah, you can it would you say from. Well, you've had a few sort of penny drop moments already in your first two places. Is that a constant thing that you've found through psychology in development that you're always learning, you're always having these. Obviously at the start of your career you're going to have a lot more. But would you say there's that spike at the start of your career where you, you seem to be taking on a lot and having a lot of changes in how you see it and what. I mean, you mentioned it why you're actually doing it in the first place.

[B]

Yeah, yeah. I mean it's. If you. I'm going to try. I don't have a whiteboard here, so it's going to be difficult. But if you can try and imagine like a graph and you think about learning, it always feels like it's a linear graph going up once you've learned everything and then tapers off. But what it really is kind of a series of bursts. So like you said, you've got that really fast ramp up in uni where you try to learn what the hell this programming thing is and then that tapers off where you think you've got it. And then you go into a job with real people having to learn to work together and learn soft skills and there's another big ramp up of learning happens again.

[A]

Yeah.

[B]

We start tapering off and then discover, well, it's all about customer value. There's a whole nother bunch of things to learn and it's got this step thing that keeps happening.

[A]

Yeah.

[B]

All the way through the career. And even, even now there's no. You'll never know everything but something that will grab you and say, right, this is where I want to, to learn that.

[A]

I'm with you. Are we, are we mid. Mid 2000s, is that right?

[B]

Yeah. So now we're early to late 2000s.

[A]

Okay.

[B]

2001, 2008. That sort of time frame. Things are still fairly old fashioned but instead of sending zip files with libraries and executables.

[A]

Yeah.

[B]

We have installer programs. You can double click installer. It will do all of the work for you. And this is where like thinking about automation and thinking about doing the taking the tile out of work, which is what fired me up then it feels like sometimes dichotomies I know are usually false, but feels like they're kind of two types of developers here or developer psychologies. There's the developer who wants to make new features, who wants to explore new tech and all that. And then there's the type developer who wants to make the process of getting stuff to customers out the door as easy as possible.

[A]

Yeah.

[B]

At the time was build teams and build engineering or tools engineering which has slowly become DevOps over the last what, 20 years now.

[A]

Yeah, yeah, it is, it's interesting. Is it how that that mindset shapes. It shapes your career in software development, what, what angle software engineering? What, whether what you go into, whether you're that proactive person that wants to create new things or whether you like fixing things. It's, it's. How do you think that's something that is decided early on or does it change often?

[B]

I'm not sure how, how stable it is so I use stable. It's got a psychological term which means, you know, whether a trait lasts for a lifetime or it does change. But I have noticed that there are kind of the people who want to work on new fancy features and tech kind of complain quite a lot when you ask them to do some bug fixing or you know, some deep refactoring or changes to code that aren't going to make it at the door to customers. So automation around build frameworks. But that has changed quite a lot with the advent of DevOps. So putting these kind of skills together and the advent of no agile ways of forming teams so cross functional teams where gradually we're getting developed to see that it's not a personal sport, it's a team sport and it's about what the team can do.

[A]

Yeah, no, I. In team. Right. No, that's, that's, that's, that's a really good point. I mean it. And that's in all walks of life really. I think with any organization or anything you're trying to do. How, how does the psychology of development affect developers work as individuals and as a team? So you know, is there that, that fear to fail, fear to share with the team success as a team as opposed to an individual? How, how does that differ?

[B]

Oh, if you're going from. So back to kind of the story, I kind of started going from older style companies like you could almost say, you know, Free Agile Manifesto to later stage companies which came after that. And then DevOps similarly following along, seeing developers are either, you know, they, they want to work in a team and they need to work in a team which that's the prevailing wisdom. That's what we have to do now there are still some developers who never want to do that and think we shouldn't talk to each other and that's a really hard thing as well because we're never taught soft skills growing up. We're taught languages, we're taught design patterns, but those things are easy to learn. What's really hard to learn is the how do you have a conversation without knowing someone or how do you foster a sense of collaboration and safety in a team? Yeah, and that's, that's the Important thing, because you can have the best programmers in the world if they're not talking to each other or if they feel that their ideas will get knocked down if there's lots of competition. You just have to look at Twitter at the moment. Yeah. They're not going to be as effective as possible.

[A]

Yeah, that's a really, really, really good point. I mean, communication. Absolutely on point and working in teams and things like that. It's having your point heard, being able to effectively communicate that. I know we've spoke before about it. Kind versus nice. Tell us, Tell us. Tell the viewers what you mean. So, viewers, listeners. We're on a podcast, aren't we? We're not streaming live. Tell.

[B]

Tell the.

[A]

Tell the listeners what you mean versus when you say kind versus nice.

[B]

So a lot of people, when they, when they, when they hear the word kind, I think actually, hang on, let me, Let me turn this around. I'll put a pause in there, actually. What do you think? If someone is being kind, what does that suggest to you?

[A]

If someone's being kind, they are buying someone an ice cream. Being. Being polite. Please and thank yous.

[B]

Am I.

[A]

Am I on my way off there?

[B]

Yeah. That is particularly what nice is. And nice is kind of pushing things down just to get along.

[A]

Yeah.

[B]

You might feel conflict, you might not agree with someone, but you don't want to be mean. So you're. You're just going along with it. Kind is. It's a little bit sharper. Yeah, it's. It's all. It's all the things. No, it's. It's helping your colleagues be the best they can be. Working out. No, actually pointing out good things as they go along, but also pointing out bad things. So. Yeah, if you've got conflicts, you know, and you want to have this conversation, it's kinder to have a difficult conversation and, you know, get that out in the open or kind of difficult feedback, but the kind. Yeah, it's not cruel to be kind. It's doing it in this human manner.

[A]

Yeah, yeah.

[B]

Ways of giving feedback that aren't cruel. Sure. Aren't nice.

[A]

So there's. Yeah, basically it's a. It's a clear, concise conversation. Not cruel, but it's for the good of the team and it's. It's constructive. Constructive, isn't it? I guess, if that's the word. But sounds. Sounds like all teams should be doing it.

[B]

I. I don't know if you've seen Ted Lasso. Yeah, it's been kind of a big thing over. Over the last, especially during lockdown. But the evolution of that character. And it starts out as someone who's very nice, but to the point where it almost killed him.

[A]

Yeah.

[B]

Where he gets therapy and thumbs up for therapy. Everyone should do it.

[A]

Yeah.

[B]

Being more kind. He's looking after himself. He's giving people the hard feedback they need. It's not just hoping. Everything just gets along and that's the journey that we all have to take.

[A]

Yeah. No, I think that's if. If anyone has watched it, they'll completely understand. And that's. That's the perfect sort of example there, isn't it? It's. Yeah, it's. It's an interesting conversation, kind versus nice. Because unless someone's had that conversation, I don't think they. They understand. So it's. It's being nice actually, in the long run is actually can be detrimental. You want to be kind. That's really good. Do you think that that has become more difficult with. With the modern ways of working, Damien, obviously. Is it easier to be kind face to face than it is over a team's call? What effect has the modern way of working had on our psychology, do you think? And perhaps specifically for software developers, of course.

[B]

So get back to the personal story. Lockdown absolutely broke me again. You can imagine thinking about no software engineering science background, developing before moving into management. I thought I would love being locked in the house, not having to do anything, not having to make small talk, all of that.

[A]

Yeah.

[B]

Yeah. It took two weeks before I was almost screaming wanting to go back into an office. And I know this is a very personal thing. Before the people with the pitchforks come after me, I discovered I was an extrovert. Or at least an ambivert sometime. No. Two weeks into lockdown. One of the biggest things I noticed for me during lockdown was that zoom and online calls, all of this stuff made everything very two dimensional so that we didn't do the small talk or the how are you today? That sort of thing. Meetings were very much literally 2D, wasn't it? It was, yeah. And. Yeah.

[A]

Yeah.

[B]

And we're not gonna learn about each other.

[A]

Yeah. I mean, it is. It's completely true. I mean, I. I've worked from home for a long time as well, and being perhaps what I'd say is more of a people person. The time you spend in an office, you know, you'll have conversations you wouldn't. You wouldn't have. You just. I know it sounds obvious, but getting someone a coffee, walking past someone's desk, just catching Eyes with someone at the office. Oh, you know, I need a reminder that oh, I need to do this for you or things like that. You know, if you're not hot on your reminders on your laptop, it's, it's, it's just invaluable really, isn't it? That time in the office.

[B]

Yeah. And the psychology wise, it took us a long time to actually understand the people on the screen were people. We've spent all of our lives being primed that a person is three dimensional in front of you. You can see their body language, you can see the subtle facial expressions when someone is just shoulders in the head on a flat screen. We've been primed through video games, through television. They're not people, you know, they're coming on the screen. And we switched into that mode without knowing it. So that was a, I think there was a, almost like a desert of empathy at the time where yeah, we were all a little bit more ratty with each other. We all demanded a lot more of each other and didn't spend the time to, you know, see where, where we each were. We all. Okay.

[A]

Yeah.

[B]

And then the, while the productivity of individuals went up. Yeah, the productivity, the effectiveness of a team went down because we lost that psychological safety. We lost the ability to make mistakes.

[A]

Yeah, I think there's, there's a right way of perhaps working remotely and there's a wrong way. I think you can't just do it. You've got to have certain things, certain support, people support set up there. You know, you've got to have regular check ins and things like that to help with that this psychological struggle through essentially just being on your own and like you say, not having that human contact. It's interesting you said, look, we are, we have kind of been tuned to think that someone on a screen isn't real or there's not that. You know, from watching TV and playing computer games and stuff like that. It's on the tv. You know, you don't have that. It's just not the same, is it? You don't have those, those body languages coming back at you. You know, it's head and shoulders, that's all it is in a screen. Interesting that you said productivity went up and why do you think that was then?

[B]

So it's a very specific type of productivity though. The productivity of a person went up. Because you're at home all day, there are fewer interruptions. If someone wants to just have a chat, it's a big thing. You have to go put something in the diary or you have to call them on Slack or Zoom. You have the conversation, you have to think about why you're having the conversation as opposed to just dropping by someone there saying, hey, how you doing? You're not looking. No, you're not looking great. Is that. But yeah, you have all of that extra time to do the bits of work that are just work.

[A]

Yeah. So it's not that often you get a sort of an invite in your Outlook calendar for. To talk about the football or stuff like that. But, you know, because you might think that that's not right. But realistically in the office you will do that. You'll have a chat about your weekend, the football, good or bad, and it'll be invaluable that you just. Yeah. Like say when you're at home, you don't, you don't have those calendar invites for that.

[B]

And we tried really hard at the start of lockdown, you know, if you, if you remember that time, there was a lot of we're gonna do all the same things. We're gonna have social time on Zoom, the quizzes. It was just reminding me that it wasn't good enough.

[A]

Yeah, yeah, yeah, I know, I understand. Yeah, it's. We did try. Yeah. I guess it's. It's all about that hybrid now, really, having a bit of a mix of both. And I think that has come from. Or feedback from it. You know, one way remote just doesn't.

[B]

Doesn't work.

[A]

That's quite where.

[B]

Yeah.

[A]

Got to have that bit of a blend.

[B]

It's also very personal. So the way I'm talking about myself, sure, I know I'm in the minority, the person who wants to be in the office and around people, especially in development, you know, that, that sort of. I'm person in the minority there, but so is that I never want to talk to people and there's always something in between. So it is up to the person which. Which way they want to live their life.

[A]

Yeah, I mean, there's, there's nothing more personal is that and your psychology, how you, how you feel, how you react. So it's, it's not a one blanket fits all. Although there might be things out there that ring true for a lot of people. There's nothing more personal really. I mean, like you say, like some people during lockdown had the time of their life, they loved it. You know, it's, it's interesting. So I guess moving away from sort of remote working and how that affected us, what would you say are the three most important points or three. My three most important psychological traits for a successful developer. Or we could do five. How many would you like to do?

[B]

We're all individuals and I don't really think that there are specific traits that mean you're going to be a good developer or not. But there are some behaviors that will help you a lot. Biggest one is going to be curiosity. I got the same thing for most no knowledge roles. Curiosity is your, your biggest friend.

[A]

Yeah.

[B]

Because yeah, you need to be curious about the customer problem, what they actually want to be fixed. You know, what is going to help people. Then curious understand how you're going to fix it and how you're going to make it better. But not just do the kind of, the smallest thing that would solve that problem but think wider about the issues that would come up around there. So what the wider systems is going to integrate with. I think that's probably a big trait.

[A]

Very, very true. Obviously understanding a problem outside in is very difficult and then sometimes if you were limited to three questions, you're not going to have the same overview. I like to see it as a bit of a jigsaw. So if, if you ask 20 questions, you'll have more pieces there. So it's easier if you ask two questions or they're not the right questions then and you're not, and you're not curious. Curious enough to ask them in the first place, then you're going to have maybe three or four outside pieces and you're not going to know how to, how to, to work on it. Would, would you go go along with my little idea of a jigsaw? I've always used that.

[B]

Yeah, I like that. Obviously you're, you're always going to be wrong, but the more curious you are at the start, the less likely that wrong is going to be. Yeah.

[A]

And I mean in soft software development I would imagine it's, it's even more important because they're not always visual things and you know, the, you know, if you talking about like a monolith system, you might not necessarily even know until you've, you've been curious enough to, to test something. Right. But of manual testing there and you might, it's. Yeah. Curiosity I think is. Yeah, that's, that's a really good point.

[B]

And it goes beyond just finding out what the customer wants. It's customer, your customer wants a certain piece of business, you know, functionality. You need to be curious about the entire system and how it interacts with other things to learn the parts that the customer never knows they want. But if you don't do them, you won't help the problem.

[A]

Yeah, fantastic. Okay, so, Damien, carry on with your journey in software engineering and how it's shaped you today.

[B]

Yeah. So then Acceleras again, much more about developer experience, building tools to help them get software in effectively. And I was just halfway through kind of career at the time, starting to feel a little bit burnt up probably. If you're a developer and you haven't felt coming close to burnout at some time, then you're rare and incredibly lucky. I have a very weird reaction to burnout. And what I did was sign up for an Open University course, not realizing just how much work it was going to be. So then around the end of my time at Acceleras, I took on a psychology master's with the Omniversity. I'd spent about 10 years getting that at the same time working. And then after Acceleras, I went to a small company that you might have heard of. They used to make mobile phones. Motorola.

[A]

Motorola. No, I never heard of. Yeah, of course we have. Huge conglomerate.

[B]

Yeah. And that was a huge step up in learning about software development at scale. So most of the companies I've worked for had about 200 developers. Motorola at that time had 77,000 developers.

[A]

Wow.

[B]

I was working for a very small part of it, which is basically trying to build Android before Android came out.

[A]

Okay, interesting.

[B]

And that was a very different way of doing software. It's kind of at that point, then all the agile side of things vanished because you're talking about hardware still very old school.

[A]

Embedded stuff.

[B]

Embedded stuff, Embedded processes. So building where we were, we're building the OS framework and the OS for a foam that had to go through very various regulatory checks. For some, I discovered as an injury that there were regulations in some parts of the industry. And then that went to device manufacturers, had to certify it there and then network owners that certified there. So that was a lot slower process. But then learning to work with hardware and lots more developers, that was interesting to him.

[A]

Right. Slightly different to what you'd previously been doing in terms of that. Was that a valuable part, a valuable learning curve? I would say that you went on through Motorola.

[B]

This is where I actually learned a lot more doing psychology degree than I ever did doing computer science is if you think about the scales of people. So in. In the Cambridge site, there were 400 people. That's a lot harder to. For any one person to know what any one other person does.

[A]

Sure.

[B]

So trying to get that entire system in Your head is very hard. And where I was working on the, on the building was very much I had to understand all of the different teams and who was fighting with whom, who.

[A]

Yeah.

[B]

Who was happy, who wasn't, what parts of the system were less good than others. That's a. Learning about development as actually as a psychology game as opposed to building.

[A]

And I guess if you've got that, that level of communication or if psychological understanding, you could learn about the pros and cons a lot quicker through talking through the team rather than just sitting down on your own going through lines and lines of code. And, you know, it's. It does benefit,

[B]

especially for a team. For a company that size, one person changing something deep in an operating system has massive ramifications for everyone else. So. So you have to talk, you have to figure out if I'm changing the Bluetooth stack, how's that going to affect everything else about the phone? Okay. I need to get drivers updated, talk to the driver's team. And this is, let's probably hint at this now, but this is where later on, much smarter people than me, I come up with team topologies and talk about, hey, we've been told silos are bad for 20 years, but actually if you want to be a human being and able to reason about this stuff, you have to have some sort of silos.

[A]

Okay, interesting. So how long, how long were you at Motorola for then, Damien? Was that, was that a long stand?

[B]

Wasn't a massive stint. The iPhone came out, Android came out, and the market changed sufficiently that I don't think Motorola kept up with the times.

[A]

Yeah, right.

[B]

Closed their Cambridge office. And that's when I, I moved down to London.

[A]

Okay.

[B]

Worked for a few years for this, this web thing that was starting to get big again. Never. We never worked on a web app before. I worked for a company called Boardex at the time, and they, they built relationship capital management software. So again, Right. Looking at the relationships between people and how you can leverage them and the strength of those relationships. Sure. And that was a huge change for Motorola because. Went from huge development teams worldwide to a very small team of six people.

[A]

Okay.

[B]

And they worked proper. Scrum. And this is one of the dangers of Scrum. I've seen that It's. It becomes very easy, especially if you're a developer, to look at the things that Scrum or a framework says you have to do and then do that alone as opposed to understanding what, what they're there for.

[A]

Okay.

[B]

So, for example, there's one piece of work I was working on. On the installer. And because you're supposed to make progress every sprint, it became busy work because if you did the installer at the end and everything worked, then it's a lot easier than completely reworking the installer every week just to make progress.

[A]

I see, yeah. Yeah.

[B]

So there was a bit of tension there between me and development manager on whether I should just spend my time making slow progress. And yeah, incremental progress is good, but sometimes, you know, it's a contention between avoiding rework and avoiding not making progress until the very end.

[A]

Yeah. So that's, That's a good mix, isn't it, between methodologies and psychology. And you've got to take into account both equally, I would imagine.

[B]

And one thing I noticed there actually was the. This was just before DevOps became a thing and the operations team and development team didn't talk very well and I was in between both. But the operations team would complain about this scrum thing. Things like, oh, yeah, they're just in process for process sake. This, it's not very stable. And development team would obviously complain about the operations team. That's all. They're setting their ways. Why can't they just make a change? And then DevOps started coming out, people were writing about it and gradually they started to come together. It was great to see that. But it took a lot of trying to get each kind of side of the business to understand the other side's problems and why they're thinking that way rather than saying they're wrong. Because obviously I'm right.

[A]

The element of empathy that we're touching on there, I think, which is something we've.

[B]

The hardest part, isn't it, understanding that. So there's a thing I know occasionally it's called the liking gap.

[A]

Okay.

[B]

But basically, as humans, we spend all of our time in our own head. So we've got this one voice that's constant, that's always here.

[A]

Yeah.

[B]

What we don't understand a lot of the time on a very visceral level is that other people don't have access to that voice, but we assume they know this constant stream of thoughts that's always here. We don't. We.

[A]

We often think that we are. Or other. We assume other people are mind readers, but unfortunately that. That doesn't exist.

[B]

If only we could.

[A]

Yeah, I know, I know, but yeah, that's a good point. Obviously that's. That's just. Well, it's a. It's a psychological understanding, isn't it, that you need to communicate your Thoughts and other people will have other thoughts and. And trying to work together and understand why somebody else has done something.

[B]

Yeah. And then no understanding the, the grace and kindness that, you know, you'll have a lot of time where this hasn't. It takes a long time to build up this kind of ability to have conversations that, you know are going to be tricky, but the conversations are important because that's how you build an understanding of the other person's world.

[A]

Yeah. So it's. It sounds like at this point in your career you're starting to understand a bit about, like, the leadership, what things work like. You've got this scrum, you've done waterfall. DevOps is. Is on the brink. So would you say this was quite a, you know, like when we were talking about the graph and how you

[B]

learn and these quantum jumps.

[A]

Yeah, it sounds like you're about, you know. Yeah, about there. So. So where did it lead you next, Damien?

[B]

The next day moved back to. Came. I say moved. I moved companies back to Cambridge because I want to stop eating for a while. It was back and forth six hours a day on the train by me.

[A]

Yeah.

[B]

So you could imagine if I was that person during lockdown, I probably would have been a lot more happy.

[A]

Yes. Yeah. Very individual, like we said.

[B]

Yeah, yeah. And started working for a security software company called Bromium.

[A]

Right.

[B]

That's where I started leading a team and so building more around the process and actually taking a smaller company to the point where it needs to be okay. Again, that was about bringing in DevOps practices, about reducing how often reducing the time between releases, getting customer value early and often.

[A]

So you'd. You'd completed your psychology masters at this point, is that right?

[B]

I did, actually, yeah. So, yeah, I was about two years into bromine, but I'd finally written up and.

[A]

10,000 words.

[B]

Yeah, yeah. And then for two minutes, I think at most thought about a doctorate and thought, no, I don't have any more hair left. I can't do that yet.

[A]

It was. It was a similar thought process for myself. I did. I've got a master's in town planning and I think I thought about it probably about a minute and a half. I thought, I think I'm there. Education wise, I think I'm happy. But. So then that must have been. You must have been able to take so much from that master's degree and implement it into running the teams. It sounds like it all came together at a really, really good time and it must have helped you with your career quite a lot.

[B]

Yeah. So then after Bromium, I moved over to feature space.

[A]

Right.

[B]

I was employee number 87 when I joined there. So as a small engineering team, 30 people, but growing really, really quickly.

[A]

Scaling up. Yes. Yeah.

[B]

With lots of great technical people, but not a lot of process. So I came in to do the process management and kind of take some of the things I'd learned previously and introduce them to a company that's growing far too quickly. And I spent my time there kind of growing the team from that 30 people team to 120.

[A]

Wow.

[B]

Building the leadership team, building communication processes, and basically trying to instill that kind empathetic, reward, team forced culture across the company. And this is around the biggest thing there. So one of my big projects was actually taking the organization. So it's like development before people and structures, right?

[A]

Yeah.

[B]

Taking the organization to a place that

[A]

would support less code, more people.

[B]

Turning Outlook and PowerPoint into my IDE.

[A]

Right.

[B]

So this is around the time I've kind of hinted at it before, as team topologies came out.

[A]

Okay.

[B]

And there's nothing majorly new in team topologies, but what it does is it brings together 20 years of thought and practice into a fairly slender book. But it's all gold about how you organize teams, different types of teams that you would. You would organize people in, and how you organize people to allow as much trust as possible.

[A]

Sure.

[B]

So if you think about the connections between people. So if you've got two people in the team, you only have to have one conversation to kind of figure something out.

[A]

Yeah.

[B]

If you've got four people in the team, you have to have eight conversations going across.

[A]

Yeah.

[B]

And scaling like that, since you've got a single team over five or six people, then to have trust in that team of people becomes incredibly difficult because you have to constantly have these conversations. And that's why we organize into teams.

[A]

Yeah, yeah.

[B]

But then the key things around team topologies is you organize the teams around very specific parts of your software architecture. So then that team can do everything it needs to do around that piece of the system.

[A]

Right.

[B]

And then you do actually put silos in between teams. So there's a great concept in there called the Team API, which is where you describe when you have a team, you describe how you contact the team, the parts of the system they are responsible for, the APIs, the technical APIs that they use. And if you're changing a part of the system that might affect that, what those are, basically that's how you communicate with the team.

[A]

Brilliant.

[B]

But then you're Taking the individuals. So you're taking the whole. I'm an individual, do my job. He's up, up a level in that the units of the organization are really teams and the teams then talk to each other through these interfaces.

[A]

Yeah. Would you say that's a challenge faced by a lot of companies out there? How would you say that's implemented quite broadly? Or would you say it's something that a lot of companies could take into context and try and apply?

[B]

Oh, if you look at some of the stuff that Matt Skelton, the Manual pay have been writing recently, it's gone way outside of technical teams and companies of any type of business are starting to implement these sorts of ideas.

[A]

Yeah.

[B]

Laying out what, who's responsible for what and how those people interact.

[A]

There's additional layers of governance. I think that perhaps the best way to say it that is needed around these teams. The G word. Yeah, but it's important, isn't it?

[B]

There's a key piece. Everyone starts, especially with the agile kind of movement. Everyone talks about empowered teams, but empowerment on its own can create chaos. Like, well, this is my piece, you can't have it. And people are fighting over ownership of code or, or this is my process. It, the team topologies kind of framework gives you more of a. A way of laying out the boundaries of this empowerment. And boundaries are super, super empowering.

[A]

Yeah, yeah.

[B]

Because the constraints are what allow you then to go off and do whatever you need to do in the. Within those boundaries.

[A]

Sure, yeah. The rules. Rules are there for a reason sort of thing, isn't it? How could we help or encourage people to understand the importance of this, this psychology aspect? Because let's be honest, Damon, there's nothing too many guys in your industry that have this level of understanding of psychology. This with a master's degree in psychology, what a fantastic mix. It's almost. I think everyone should have some sort of education in psychology for all lines of work. Right. That's. Let's not pretend it's not. But I mean my, my girlfriend has a bachelor's degree in psychology and often I'll run things past her and to just views it completely different to me. Oh God, you're so right. How can we better understand the psychology of a software developer? It's critical. Critical to their success. Right. By understanding thought processes and the motivation of someone behind why they're doing what they're doing. It can change. Can change. Right? Yeah.

[B]

Probably shouldn't say this, but there's nothing actually special about software developers as people. You understand psychology of the individual rather than the software developers that are all this stereotype that you've got.

[A]

Yeah. I mean, there's stereotypes for all types of people, right? Salesmen, you know, salespeople, are that better guys in the suit that won't, won't let you speak, they'll. Won't leave you alone, they'll hassle you on the phone. That's, that's the stereotypical salesman. Right. Egotistical, flashy car. But realistically, most of us aren't. I mean, there's, there's, there's, there's all that. And in software development, I guess there is, there's that, there's that picture that people paint. But. Yeah, go on.

[B]

So, so, yeah, there are traits, you know, and like you said, they're stereotypes for a reason. But most of developers, at least that I've known, want to fix things. They want to solve problems for real people. That's why they're there. And this can be great because you're solving real business problems, you're saving companies money, you're stopping real people from being defrauded, you're making all these cool things that we've got to play with.

[A]

Absolutely.

[B]

It can also have a dark side in that the first thing most developers will do is try to fix a problem rather than pause and try to consider, well, what are we trying to do here?

[A]

Why is the problem there in the first place?

[B]

Is there something else we can do rather than making the code change, or is it what the customer actually wants? There's all sorts of questions that you can ask before jumping straight to, I'm going to make an early code fix late at night.

[A]

Are we trying to fix something that doesn't need fixing? There's sometimes that question. Is it? Yeah, you really got it. That, that inquisitiveness and that we spoke about earlier, you know, curiosity.

[B]

That's the key thing.

[A]

Yeah, yeah, yeah.

[B]

And the downside as well for a lot of developers is that when, when code bases get too creaky, when there's a lot of pressure from a business to do lots of little things and do too much, that as development teams feel like they're not providing value, developers in those teams are very hard on themselves.

[A]

Are we touching on imposter syndrome maybe as well here?

[B]

I think imposter syndrome, burnout, stress, all of these things from not being able to do the one thing that you think you're great at.

[A]

So I guess what we're touching on so many interesting points here. Damien, what can we do to help? Perhaps Spread the word and better understand the psychology of a software developer. Besides picking up a book or doing a psychology degree,

[B]

there's a lot you don't even need to learn. It's all about communication. Talking to your colleagues and setting aside your own thoughts and actually truly listening. None of us actually really listens when I'm talking. Right now, I bet you that you're sitting thinking, what's the next question? You're going to be saying, yeah, exactly, you're human. Yeah, that's. That's what we all do. Which means that we're either waiting to knock down a point or, you know, we're just not present. We're not truly kind of trying to understand what that person is trying to say. And it's rarely, it's the words that the person's trying to say. There's always something behind there and you can dig into it and figure that out.

[A]

Would you agree? I. I'd say I. I mean, I'm 33, okay. So I'm. I'm getting to a point in my life where perhaps I can look back at myself 10, 15 years ago and think, God, like for me, that the listening aspect. I remember when I first sort of started in sales, you know, it was very much what you just said, like, not listening, thinking of what next to say. Whereas as I've got older, a bit more calm. You know, there's nothing wrong with being open, honest. You know, we are all human. If I was to say, if you'd said something when I was younger, if someone had said something I didn't understand, I would nod and pretend to understand and save my gray sort of thing. But as I got older. But actually, there's absolutely nothing wrong with me saying sorry. I mean, even if I'm the only one in the room, I don't understand. Can you explain it until I do? And then my word, that was. I mean, that is a, an important aspect to have that open, clear communication. Like you said, if you can have that, then there's nothing, you know, I mean, like, like you said, the technical point of view you get from your university degrees, you get your technical understanding. But if you can't ask that question, if there's something you don't understand, then my word is your. Is it going to be difficult?

[B]

Yeah, there all sorts of reasons why you wouldn't ask questions. I don't want to feel look like some stupid or, or even worse, if teams don't have that safety, you could get shouted at for asking a question. It's fostering that environment and going really hard on you. Reward people not just for technical excellence, but also for communication and collaboration.

[A]

That's it. I mean, that's a prime example of where psychology can hinder development full stop. Any sort of progress, you know, if, if someone's scared to ask questions, it's. And that just proves sort of your point that psychology and the psychology of a developer is almost, if not more important than their ability to their technical ability, I guess. Where would you say now, your journey, obviously manager and director now of your own, your own company. What would you say, what would you say is the next peak for you to go on to?

[B]

Now, I think I'm at the bottom of one of these curves.

[A]

Yeah, sure. Yes.

[B]

I'd done this once before with lots of white hair and lots of stress. Learned a lot of things not to do. Like to do it again. That's what I want to do. And that's why I've set up this consulting company as well, to help people who want to talk about psychology of development, psychology of organizations. And if you like what I've said and you want to talk.

[A]

Yeah, yeah, by all means. I picked up on it. I can't remember if I mentioned it earlier. It was the last time we spoke, but the translation of the name of your business, just tell the listeners,

[B]

it's called Kova, which of course, Irish. Irish words is unpronounceable to anyone but the Irish. It can be.

[A]

Apologies for my pronunciation at the start if I got it wrong.

[B]

It can be roughly translated as empathy. It can mean working together, it can mean all sorts of things like that, but it's in the region of empathy.

[A]

That's brilliant. I think that's probably one of my favorite names of a company I've ever heard because I'm a strong one for empathy. I think it, it's. It's really important to understand when you're talking to someone, where they're coming from and what, what they might be, how

[B]

they might be viewing it, what you have to do.

[A]

Yeah, exactly. It's perspective, isn't it? You have to understand a problem before you can even go about trying to, to fix it. But I think, I guess that's our time. Damien, I think I'll thank you immensely for, for coming on and giving us your time. It's been really, really a great, honest, open chat about psychology. You know, some from. We don't always talk about it, do we? I think it's important to, to share, have open and honest conversations and hopefully, I guess off the back of this, anyone's listening and, and has a conversation about anything that they're. They're struggling with. You know, it doesn't necessarily have to be something you're struggling with. Talk about what you're enjoying, you know, it's. It's equally as important. Right. So is there any last, final words, Damien, you'd like to say

[B]

this world is very tough, particularly now. This is kind of the first recession or almost recession a lot of people have ever gone through in their lives.

[A]

We made it an hour and 15 minutes without using the word recession. I think we might deserve a pat on the back.

[B]

Had to get it in there. The important thing is there's no being kind. Being kind to each other. It's difficult. And when times are difficult, you need to remember that there is only kindness. Yeah, I'm being kind to myself is also just as important.

[A]

And understanding. Yeah, understanding what kindness means. We spoke about it earlier. Not being just nice all the time, but being kind. I think that's probably a great way to finish. So, Damien, thank you so much for your time. I'll speak to you soon, no doubt, and enjoy the rest of your week. And thanks very much for joining us here at the Godel Pod.

[B]

Thanks so much, Michael.

[A]

No worries. Take care.