Navigating the Tech Landscape: Startups vs. Enterprises with Rob Wade - Part One

Hello everyone. Hey Rob.

Hello.

How are you doing? How are you feeling?

Yeah, good. Thanks for having me.

Of course. So today, big topics. We got startups versus enterprises and dynamics of people. We're going to talk about quality as well. We're going to talk about hybrid work. So we have 3 big topics to discuss. So before we jump into topics, Rob, who is Rob? Give us an elevator pitch.

So my name's Rob, Rob Wade. I'm the head of group IT at Cufflink. Cufflink's a fintech platform based in the UK. We're based in Kent, our main office. And yeah, my role is, as it sounds, head of IT. It encompasses everything from the kind of on-site infrastructure to the development of our platform. And kind of maintaining the development teams and looking after the people in there. So I wear a lot of hats.

A lot of hats.

Yeah. And I don't always wear them perfectly, but yeah, I'm always trying to kind of pick the ones I know the best.

Is there a difference between head of IT and chief technology officer as a CTO?

Practically, so far in my experience, no. So what we found, so kind of for a bit of context, I kind of joined with that initial kind of CTO title. After some time had passed and dust had settled, it was pretty clear that my role was kind of, it didn't quite reflect, the title didn't quite reflect the job I was actually doing kind of day to day. So we kind of agreed that Head of Group IT was a better fit in terms of title. It kind of better encompassed and encapsulated what I actually spend my time working on. So we kind of, we changed it.

That makes perfect sense because you want to reflect the responsibilities to global markets as well.

Yeah, absolutely. And I think that, you know, probably a certain amount of this was self-inflicted, but there was a lot of pressure that came with the title that I probably felt an unreasonable amount of responsibility to kind of deliver on that, on that kind of brief. But then at the same time, I'm there to learn how to do that role, right? So I'm trying to kind of embody a role I don't quite fully understand. So, okay, you know, that probably added to the, you know, again, it was a probably a kind of self-inflicted pressure that, you know, this new role— not going to say the pressure's off because really it's never truly off. But I certainly feel kind of better day to day about kind of what I'm doing and kind of the value I bring.

It's good to feel that you understand what is expected and what value you actually bring, isn't it?

Absolutely. Yeah. I mean, you know, I like to think, and obviously I'm not the best person to judge this fully, but I always like to think that I I always bring kind of more value than I kind of command from a financial perspective.

Is that work ethics, Rob? Is that like your accountability level and work ethics, or is it just that you love what you do?

It's a bit of both, I think. You know, I think when you work in an environment, especially true when you like the people you work with, if you feel a kind of certain— everything from you know, a kind of responsibility to deliver for them, to make their lives easier. But also even to the point of, you know, you might feel a kind of instinctive protectiveness of somebody who you work with, who you think this person's a kind of national treasure in terms of, you know, how much work they do and how much they're responsible for. You want to make their lives easier too. So I think it's, it's a combination of kind of love for what you do and, and the people you work with, but also, yeah, I kind of, you I've always felt responsible to kind of do my best work. And so that's an attitude I try to bring into everything I do.

Okay, that's a very nice approach. I mean, undoubtedly head of group of IT, right?

Well, you know, I'm not going to say I've had no complaints, but they're definitely outnumbered by the positives. So, you know, taking that as a sign I'm in the right direction at the moment.

You can be loved by everybody, isn't it? It's one of these things where I like this question, and I got this very interview process. You know, someone asked me, if people are having an evening out now and they're talking about you, what are they saying? So it really, like, you know, it's like it forces you to self-reflect and try to think of how people actually see you. And as long as, you know, there's more positive, you know, you're doing, you know, your job well. But you can't be a hero in everyone's mind, you know, there will be issues.

No, far from it. And, you know, I've had kind of challenges in the not too distant past where I've had to be, you know, I've had to— I mean, as a leader, you always have to contend with delivering bad news. Um, I've delivered, you know, the individual kind, the group kind, the, you know, the whole team kind. It's— you have to take the rough with the smooth, you know. With the responsibility comes the responsibility, the weight of responsibility and the burden of, of being the person who sometimes has to you know, proverbially swing the sword.

I love that. That's a good saying. It's a good saying.

I'd love to say it was mine, but I don't know where I picked it up. Yeah, it's just assimilated by kind of conversational osmosis, I think.

Okay. Um, so if we compare this in the startup environment, and let me define the startup. So let's say it's a business which is, um, 40 to 60 people size as a whole business. So that means that engineering department is likely around like 20 to 30.

Okay.

And then we have an enterprise where we walk into hundreds to 500 people.

Yeah.

How the dynamics differ. And let's just take maybe a very first one. How do you tend to work with people when you have— I know you at the name basis because it's just one of you, and now I have no idea who you are, I didn't see you, but I know I need to work with you.

Yeah, I mean, it's a different kind of— it is a very different beast to be, you know, a cog in the machine, as it were. And not to say that, you know, the cogs are very important, right? It's not going to— not to belittle that role in the wider organization, because without the cogs, the machine doesn't do its stuff at the, you know, these small things you do down here kind of percolate up to the top. And if enough people are doing them, then it's, you know, it's kind of driving the engine forward.

Yeah, machine stops, isn't it?

Yeah, exactly. You know, where I am now is very much in a kind of scale-up space. So it's a small company, but with, you know, big ambitions. And I think big success that's kind of, you have to then contend with keeping pace with delivering on even things like technical debt. You know, I'm lucky I'm in the finance space because obviously debt is a concept they understand and I can explain things in those terms. So I have an easier life than some perhaps in getting buy-in for some of the things that we need to do because obviously We talked about this earlier, kind of off air. Senior leadership in the business will always want the kind of attractive stuff, especially the kind of the stuff that's going to make money, right? The direct revenue drivers. But value is not just the money you actually bring in, it's also time spent doing more important things. It's not parking the bus because the platform is on fire. It's not having to drop tools and deal with live issues. Those things are all value-added. And it's not just about kind of what brings in the most revenue immediately. It's also about over time, how do you kind of realize increased kind of value and reduce your operational costs? Because that's value-added too, right? The lower your operating costs, the kind of— that can have an impact on your profit as well as new revenue, new money. So yeah, I think that's one thing I've kind of hypothesized because obviously I didn't do the sort of tech, the leader of the head of entire department thing at my last place. I came from, like I say, a kind of engineering management level role, kind of middle manager, starting to kind of work my way up the ladder. Working my way into kind of probably dev manager or, you know, all the way up to head of department and maybe that role eventually, that kind of CTO, head of technology. But that was a way off in a business of that size. I'm actually kind of glad because, you know, the experience I'm having now where I'm kind of learning all the time about new problems I would never have had to contend with in an engineering manager role in one team with one very restricted product brief. It's a world apart and it's a really enriching experience. Not to say it's a stress-free experience by any stretch. I've been challenged with the desire to continue enough times I had to dig very deep. But again, when you want the business to succeed because the people inside it are people you kind of attach value to, you kind of resonate emotionally with that, that can be very kind of powerful as a motivator to kind of take you forwards.

Okay, so we've got, we've got 3 things. Technical debt is being seen differently comparing to startups where potentially it could be crippling. And as well, it's very hard to sell the notion of we're going to be spending our team's time in making this code work where, where, you know, potentially our runway is like 6 months and we need to capture, you know, new revenue. That's, that protecting that bottom line is different with enterprises. We have the challenges element as well. You know, every day is a new challenge just because of the sheer size of the whole operations. Where in startups you're likely just being faced with just the product fitness or product fit and developing the features to just get more revenue. Yeah, we have the team management, you know, or people management element where you have likely, you know, maybe 10, 12 headcount, which is different comparing to enterprise where you have much more of a headcount. So in your position as a, as a leader of leaders and coming from a position of being a leader to the team, how would you say that differs? Like, did your one-to-one somehow change? Did your communication pattern somehow change? Just like, how you get fed information in general? Do you tend to still go to the team and have chats, or do you rely on some, you know, reporting?

It's tricky. I think my specific case is a, is a, is a little diff— you know, a little bit different to perhaps some others who kind of worked their way into that position of engineering management or kind of head of development. Through a technical kind of path. So I started with QA. I was a manual QA. Automation was something I kind of dabbled with, but there was never— I'm sure you can relate to this. There's oftentimes where you have all the willing and no time in which to actually invest that energy, and the opportunity is then kind of not quite there. There's been a few occasions, and I've worked with so many teams over the years, where they've kind of given me a little bit of space to pick up some skills, and I was starting to kind of get some traction in improving my technical knowledge. But the circumstances of, you know, having to still keep the wheels, you know, have to keep the, the engine moving, you still have to spend most of your time doing your day-to-day job. And unless you're a phenomenal coach in terms of kind of delegating that responsibility away and getting those people up to the standard that you would work at, which, you know, I'd like to say I made strides, I definitely didn't kind of get all the way there. It just means that you're always going to have to make it a secondary consideration to kind of skill up in that space. So for me, you know, I've always been very happy to do two things. So one is to acknowledge what I don't know. So if somebody is talking and they've lost me, I'll just, you've lost me. It's simple, but it's quite a powerful thing. And it's actually, I think, it's not something that everybody finds comfortable. I'm all right with being, you know, I don't feel it makes me look stupid to not know everything.

Yeah, people tend to somehow shield away from the fact of acknowledging that I actually don't know what you're talking about. Yeah, it's like, do you understand what I'm saying? Yeah, yeah, yeah.

But yeah, in the meantime, it's like one of those old movies with scene missing kind of playing out in their heads. It's, you know, I've always been quite happy to acknowledge where I don't know stuff. And then on the other side as well, because I'm happy to not know everything, I've always been quite happy to put, you know, if I can put trust in somebody, I will let them just, you know, give them kind of what I want in terms of the output and I'll let them run the show. They can tell me how it's done. I just tell them what I need to achieve. And so, you know, I'm quite fortunate that the team around me in my role now is very strong in that respect. So I can give them a brief and, you know, they can go ahead and support me in executing that brief and take that, you know, take one of those hats off my head. Doesn't mean I'm still not, you know, wearing plenty, but everything I can hand over knowing it will get done in a way that I'm kind of ideologically aligned with is one less thing I have to contend with day to day. And so it just frees me up to spend my energy more wisely.

That's a great delegation, isn't it? And then it's done in such a healthy manner where, you know, you acknowledging you don't know things, you just becoming authentic by, by its own thing. You say like, it's me, I don't know that thing. You delegating well, and then people feel empowered to effectively help, you know, the head of group of IT, which is, you know, a good feeling in general. Absolutely. It's just a, a good bubble of leadership.

Yeah, it's, you know, when it works well, it works really well. And I think that, you know, my observations, and these are purely my own kind of experiences, if people are kind of engaging in the opposite behavior where they're kind of obfuscating that, that kind of, will it, that, you know, they're being unwilling to kind of, to kind of, um, acknowledge that they don't know everything, if they're kind of pretending, most people see through that.

Yeah, that's not being authentic because, yeah, there's an element with every single human being where we have this gut feeling, where you talk with a person and you go like, you know, I'm having a great chat, I have no issues trusting you. It's all like, well, and then when people are not being authentic, there's something you just pick up on, these vibes, and you go like, like, it's very hard for me to build a full trust with you, which again, if you are sitting in a leadership position, that's probably not going to bode well.

Yeah, absolutely. And I think, you know, beyond the professional, just in a general day-to-day sense, like maintaining that disconnected, you know, there's a facade of a person who kind of knows everything, never, you know, their confidence is never knocked. It must be exhausting, like, to kind of maintain that. I can only imagine. I don't, you know, I don't engage in that, like I said, because I am happy to say I don't know everything. We were talking on the way here and, you know, my my, I want to say fears, but my expectation of my role, where I was going to find the challenges. This obviously, when I went in this kind of with the name of CTO was, oh, I don't know the stack. And maybe I'm not, you know, maybe I'm too hands-off, maybe I'm not, you know, maybe there's a disconnect that I'm too non-technical to be able to kind of perform this role. It's not the challenge I faced at all. And, but the reality is, When I came in and told the dev team, look, I don't know this stuff inside out, so I'm going to need you to tell me why this stuff is important, why it matters that we do X, Y, and Z, why we address this piece of tech debt. I can understand if you tell me why it matters and give me a kind of high level. Generally speaking, I can kind of read code and interpret what it does. My struggle is creating my own. So I can, if they give me a walkthrough of how things are stitched together, I can probably kind of intuit what it does. That's all I need. I need to understand what we've done and why we've done it kind of at a high level that way. And that's enough for me to go and pitch to the stakeholders, to pitch to senior leadership, to say, this is important that we do this. And so we need to prioritize it. You know, and I think that, you know, to the point, to the question about scale-ups versus kind of larger corporates, I think, having the ability to kind of have those conversations is a really kind of underserved skill. I remember being told in my last job by somebody in HR, we're having a conversation off the back of a, you know, we had an engineering managers forum and there was always a kind of, there was always a wind that blew a particular way in terms of sentiment. And A lot of the time I would, you know, in a respectful way voice my, you know, disagreement if I didn't agree, but do my best to kind of not attack people in positions and stuff because it wasn't, you know, we just held different opinions. It's not, you know, nobody's bad as human beings for that.

Exactly, it's just different viewpoints.

Yeah, so we would come out of those meetings and this kind of person in HR was sitting there talking, we were talking, and I made some— I'm quite glib about my you know, about my skills, and I'm quite fond of joking that I bring nothing to the table, right? And then they said, you communicate like a kind of, you know, you communicate like a human in a tech world. You'd be surprised how much difference that can make.

That's actually very rare.

Yeah, and so I've kind of held on to that, and actually I found almost reinforcing that when I've moved into Cufflink and taken on that kind of head of technology role. That comms piece is where I've kind of been able to make the most impact, is being able to talk to people and kind of put things in terms that they can relate to and make— kind of tell the stories of why these things are important and how we should do things and kind of why we should do them that way.

There's so many layers around communication and people in leadership positions, I think, underestimate the importance of being able to construct a message in such a way that actually sparks action.

Yes.

And as well, if you, you know, work with remote teams, you have different cultures. There's a different pattern of communication which they understand better. All of that in general as communication is a very, very strong skill to have.

Yes.

So good to hear, Rob. Let's change gears. Creativity.

Okay.

I'm in a startup. You know, we failing fast. You know, we changing features left and right. New big client came out. They need something. So it's very creative in nature. Would you say that differs in the big enterprises? Would you say that? You know, that is an idea that startups allow more creative space than big enterprises. Would you say yes, no? What's your opinion on that?

I kind of have a mixed opinion on that. I think that there is still space for it. I think that it's sometimes easy to fall into the trap of thinking that because the machine is big, you can't be creative in your piece, if that makes sense. So if you have a small kind of a small scope inside the overall product, let's say, so you're in a tech company, you've got obviously lots of different moving parts that make the business turn as a whole. Within your part, there will be space for creativity, there will be space for innovation, there will be space for leveraging some new tech. But it would be easy to look at the overall machine and say, why bother? It doesn't change anything. But that's probably the, you know, that's probably when you take the concept of the big picture and then kind of into the negative world, being kind of depressed because, to kind of use a real-world analogy, it's like picking up a guitar for the first time and learning, starting to learn to play, and then you start listening to progressive rock and going, why do I, why bother?

Yeah, I'm never gonna be that good.

I'm never gonna be that good. It's like, yeah, but believe it or not, those people all were in your position. They just were in your position a long time ago, and they've spent that time honing their craft and improving their, and improving their process and learning that skill. It's easy to kind of be discouraged by that, you know, by that kind of imposing, especially kind of monolithic structure. So, oh, what, you know, how am I possibly going to be able to innovate in this space? Or look at the size of this beast. And, you know, the problem becomes when the company as a whole doesn't appear to be doing anything new, and that can happen. I've seen that kind of ossification where you're not actually developing anything new. What you're doing is taking the working formula and distributing it into kind of more places. Obviously, you and I come from a kind of background of regulated industries and delivering content across multiple territories and jurisdictions. You can fall into that thing of, you know, actually, we're a distribution service. We're not developing anything new. All we're doing is taking what we've got, this bundle of, you know, working 1.0, and just putting it somewhere new. It's not innovation, right? So I can understand that that would be discouraging, but I think that you have to, you just have to carve out whatever space you can to, however small, do something neat and do something that, you know, drives you.

Yeah. Get your creative juice flowing.

Yeah. And again, back to that comms piece, if you build something sufficiently, you know, I'll say innovative, because that's, if nothing else, I'm conscious I've probably used that word a few times in the last couple of minutes. But, you know, if you build something sufficiently cool, then people might see that and go, oh, wow, that's really cool. We should do that. I've seen that happen. You know, a team builds, you know, does something small in their DevOps infrastructure to simplify their process. And another team goes, That's cool. Can we, you know, not steal it? Because it's, you know, if nothing else, they made it on company time, so it's the company's IP. It's not these, you know, you can't steal it from, you know.

Is that innovation, Rob? Sorry to jump in, but is that mindset before innovation? So are we talking about— because I've seen that, you know, before as well, and I've seen that all the time in any teams. You have some people who will, as you say, you know, cut off the space. They will go like, you know what, I'm going to take Fridays when it's quite calm, and I'm going to do something creative around that. Yeah, but it's not everybody who does that. So is it more about the people and the mindset first when it comes to all of that creativity and innovation?

Possibly. And I think that where, you know, where companies can kind of enable that is to give everybody that space. And I think that, you know, I've seen efforts to do that, and they usually mix success because I think the problem becomes if you don't schedule the fun and you don't compel the fun, people will just go, well, actually, I've got loads to do. I'm just going to get on with some work. I'm just going to— I don't feel like I'm going to— it's hard to convince people to have fun.

You're so right about that.

You don't want to kind of make, okay, Thursday afternoons, everybody drops tools and goes off and does something cool. It's like, why? I've got loads to— I've got so much to do. It doesn't feel like a fun experience. And moreover, there's also that kind of of with anything, certainly in my experience of all the attempts I've made to learn new things, there's a period of time where it's not fun to learn this thing. You have to kind of get a certain foundation of, um, of skill before you can start to self-propel. And until that point, it doesn't feel like fun. It feels like work. So then if you compound that feeling of I have to get to a certain point before this feels like fun, so it feels like work and I'm already at work. And this is supposed to be the fun time, it's really easy to just convince yourself to just forget it. Just put the kibosh on it.

I'm guilty of that. I can tell you right now.

Me too.

That's literally me.

The number of times, you know, the number of times, I mean, even in my personal life where I've tried to pick up a new skill, like, you know, because I work, I've worked in tech spaces, I've tried to sort of, I'd be really interested in learning to develop video games. I've tried, I've dabbled, but it's that process of this is not fun yet. And I'm just learning how to make fun. But at the same time, that bit is feeling a lot like work, and I'm— this is my personal time, I'm supposed to be having fun. The fun will come, but it's just that you have to kind of ride that, ride that period of chaos.

As they did before the—

Yeah, exactly. You have to kind of go through that pain to then get to a point where you can kind of turn it into something fun. It can come to some— realize something cool.

Yeah.

But I think it's, it's a struggle sometimes, especially because it might be one of many struggles you might have in your day-to-day kind of thought process. Everybody's grappling with everything, lots of different things all the time. Everybody's kind of got a different journey. So, you know, it might just be the wrong time to try and kind of push yourself to do that because you might not have the energy and that's okay. It's a really tough thing to kind of create in your workplace culture. Is that kind of, no, there's scheduled time for fun. It's like, brilliant. That's— nothing says let's get on with it like scheduled fun. And some— for some people, that's such a contradiction in terms that they just reject the concept. Yeah, as well. So you see people going, well, well, it's obviously— that's not real, is it? It's—

but it is important concept though. Like, you have to have this outlet where you— where you can get that creativity to happen and just, just, just switch the gears. You know, for me, it works very well I mean, I do this Friday afternoons and I think it's just worked itself out. So the Friday afternoons is just a lot more calmer. Yeah. You know, I'm less on demand as it would mean. So I can, I can do something else and I, you know, try to put things which just literally is different from what is day to day. Yeah. So different that it, you know, my mind shifts and feels like, oh, this is something new. Like, this is different.

Yeah.

So it just gives me that outlet to breathe.

And even having, you know, something like this. You know, we're, we're in a studio right now recording a podcast. Yeah, that's an outlet that kind of takes, it takes what you've, what you work on and what you, or the skill you have and all the kind of network you've built, and it channels it into a different direction. Yeah, probably doesn't feel like as much work.

Oh no, it's lovely. Yeah, I love talking with people, you know, especially like, you know, uh, huge CTOs and huge head of groups of ITs and just asking questions which helped me to be better at my job and just understand the, you know, the market. The tech market in general.

Yeah, and I think, you know, to my mind as well, talking these things through sometimes is actually quite good for somebody like my position.

Yeah.

You know, I've taken to— I started doing this as a kind of, um, an effort to kind of dissuade the worst aspects of my character. Um, I can be quite emotionally volatile, uh, if I get kind of surprised. By bad news or kind of, you know, a massive change of direction that, you know, I kind of object to— what's the word— viscerally. Okay. So knowing this, I started to spend my car journeys to and from work or anywhere just talking as if I'm having a conversation about it and just letting loose and just venting kind of most raw version of my opinion.

I love that.

So that then when I come to actually have the conversation with somebody, it might be at my current work, it might have been a previous work, it doesn't— it might be in personal life, it doesn't really matter. The time I have with them is not the first time I've expressed the thought, so it's not going to be the most raw it could possibly be. I've had a chance to kind of sculpt it a little bit and to kind of hear it in its most kind of raw format and, and, and hear what it sounds like to somebody, you know, being on the receiving end. So, you know, just being in a car by myself, I don't do it when my baby's in the car just because I'm worried. She's starting to pick up words now. I can't.

Yeah. She's gonna wave from there.

Exactly.

Yeah.

I don't want her kind of, you know, taking mum to task for something that's completely unrelated because that's gonna do me no favours at home. Uh, but you know, when it comes to when I'm just on my own in the car, I will often practise conversations I might have to have. And it might be, you know, something about my work, it might be a personal conversation where somebody's frustrating me and I might need to, you know, prepare myself for the conversation we might have to have about that frustration. It's, you know, it's kind of in service of channeling my neurotic energy into something, you know, into a more productive outlet and making it so that when I have, like I say, when I have those conversations, I'm not just unloading for the first time completely, you know, raw. To the CEO or the head of operations or the COO, I'm, you know, I've had a chance to at least walk it through and understand better kind of the steps that are actually— it helps me understand what's actually frustrating me, you know, because sometimes in the course of unloading you'll go, and it really annoys me because of this. There it is. There's the actual motivation as to why and why this thing annoys me. It's nothing to do with the decision. It's everything to do with these things that seem disconnected, but It's good that I've identified that because now I have to— I know I have to tell the story to walk them to where I am because otherwise they're going to have no context for why I'm so annoyed.

Yeah, the self-reflection piece, I mean, that's a— that's a— I call it maturity element because I feel like you need to reach a certain, you know, challenges in your life, maybe in your career where you— where you're at that point where you go like, you know, I need— I need to go for a walk and just— just have a chat with myself and just see what— what's— what's where this is coming from.

Absolutely.

That's just like, you know, you don't Initially, you don't have that self-reflection, you know, when you just, you just have emotions and you just unload in unhealthy ways. For me, it's actually writing. So I don't talk with myself in cars, but I love going for a walk and just having conversations in my head. Yeah, but what leaves my head is actually sitting down and writing, you know, an email or like a journaling. And we used to do that in a startup where when we have like very, you know, tough clients and we have conversations and we would go write emails and then we would pass emails to other executives and go like, can you read this? Yeah. And just tell me how it reads.

That's another thing as well.

It's so dangerous, especially when you're talking big contracts, you know, to go like, here's my answer to you, and then it just lands in diminishing trust ways. Then you go like, well, I lost that. Yeah, that's it. Like, that's client.

That's all. And, and, you know, it's frustrating to kind of think back on it and think, actually, it wouldn't take— it wouldn't have taken much to put myself in a position where I wasn't doing that. And so something as simple as, like you said, I do the same thing. You get somebody senior, especially if they're at your desk and you've already drafted it up, just like, while you're here, actually, can you just read this and make sure it looks okay? Because I'm about to send this. I'm just like, I'm going to send this. So like the intent's still there. I just want to read it and make sure I'm not completely up the wrong, you know, on the wrong track. And, you know, 9 times out of 10, I would say the feedback is, no, that's good. But occasionally you'll get, I would change, I'd take that out.

Yeah, that's edgy.

Yeah, you know, it's sometimes I'm too fluffy in how I pitch things. I think to your point about you can't be the hero, you can't be liked by everyone. It doesn't mean I don't try. And it is actually at times it's not a good habit because what I found is sometimes you can agonize so much about how you're going to say something you dilute what you're actually trying to say completely.

Yeah.

And so the person leaves the meeting. So if it's a performance thing, you're so, you know, you're constantly trying not to upset them and you're trying so hard to think about that. They actually don't leave the meeting realizing they've done anything wrong. And you don't want that because they need to, they need to have the opportunity to learn. And you want to be able to come back in a, you know, a couple of months and say, well, look, we talked about this. I gave you this feedback to improve and it hasn't improved, you're actually kind of hurting yourself in the future because you don't have that, that kind of foundation to build on. If you have to have those difficult conversations, you've actually made it more difficult for yourself and you've set yourself back however many months you've kind of wasted where they're laboring under this delusion that they've done everything perfectly hunky-dory and everybody's happy with everything.

Yeah, that's a very strong shout, Rob. I've seen that done, the feedback in general, seen that done, you know, so poorly Literally what you just said is that, you know, you go in a room and you go like, okay, well, there's one big thing I want that person to improve upon.

Yeah.

You're so afraid to upset it.

Yes.

You deliver it in such a way that person walks out and he's like, I'm doing great.

Yeah.

And promotion's coming.

Yeah, exactly.

Yeah. You know, you're absolutely right.

You do have that, you know, and, and as a leader, you always are going to end up in a world where people are going to ask you for stuff and you, you, it's not that you can't give it to them. You won't, because actually, you know, they're asking you for something that you don't think they're ready for or up for or warranted, or there's somebody else that's more deserving. These things are tough. And that, you know, we don't— nobody in any kind of management or leadership role has an unlimited budget to play with. Everything, every piece of money you move from one place comes from somewhere else, right? It's not a— you know, there's a finite amount to play with. So, you know, you have to then sometimes take tough decisions. If somebody comes to you and says, I want X percent raise because I think I'm deserving, it's like, well, actually put aside the number, right? But actually this person who's working just as hard, if not more so, is just as deserving, if not more so, of an increase. And I'm not going to give them that number. So then for you, that's like, it's going to be even, you know, you're not even going to touch that number because, you know, it's not about favorites. It's, you know, it's just realistic. Like, there are some people who are going to be more deserving in a particular snapshot in time. There are going to be some people who are going to be more deserving of advancement, uh, increase in kind of salary, you know, a bonus or whatever. And these things are tough. And that's one of the downsides of being a leader is sometimes You can't just give everybody a, you know, a 5-star rating, assuming you use a 5-star system. It's up to you really. But, you know, you can't give everybody a perfect rating every time because it just does, it just doesn't work that way, you know. And you're then going to have to, you know, is it better to give everybody consecutive 5-star reviews and then have to lay them all off because you've run out of money to keep the, you know, keep that team running? Probably not, right? So you're doing them a disservice in the long run to kind of placate them in the short term.

I love when people ask. I feel like ask is underrated muscle.

Yes.

I mean, in general, it's not about getting things, but it's about receiving things.

Yeah.

So to be able to receive a thing, you have to ask in the first place. So what for me as a person, you know, it's difficult to comprehend is when someone comes in and goes like, I worked there for 2 years, you know, I constantly showed these good improvements. Why did my, you know, 'Salary didn't go up and now I'm leaving.' And I'm like, 'You didn't ask.' Yeah, like, we haven't had that conversation. Yeah, we like— how do I just take it from, you know, a rabbit from a hat and go like, 'I'm just gonna give you money'? Yeah, if someone is asking and, you know, they may be at the same level, it's just like, just maybe have a conversation first. Maybe, you know, get that asking muscle going. So I love when people come in and ask, but you're absolutely right, Rob. It's like, uh, it is a finite amount of budgets which we need to distribute And, you know, you're doing well, it's probably some other people doing well. And there's a— there's really banding and elements to it. And it's just when it lands, it lands equally to everybody. Yeah. You know, it's not about favor, it's not about friends, it's about being fair of how the money is being distributed in the business. Yeah.

And I think I've kind of, you know, obviously the journey I'm on where I've kind of gone from the larger kind of pure tech corporate down to a sort of— we're not down, but, you know, in a different journey to a sort of a more senior position in a smaller company and one that's not pure tech is, you know, the money that somebody wants for a raise is also the same budget from which we buy software licenses or, you know, laptops for staff, right? And that's something that is a problem for the whole business. It's not just, oh, we'll only tech, we only buy laptops for tech in tech budgets. No, it's technology. So it's coming in, it's going in the tech budget. So every time you're kind of, as you get more exposure to more zones of responsibility where the kind of money needs to be spent, you have to have those balance kind of thoughts of, you know, well, actually, I could give this person X percent, you know, raise, or I can do this, this, and this with the same money. And actually, I need to do these two things out of those four. The other two, okay, yeah, fine, maybe I can park those, in which case maybe I can go back to them with a slightly smaller number and do those two things I need to do with the rest because I don't have the money to do it, you know, to do everything. And, you know, I think it's true in larger corporates as well, but I think you feel it more intensely in the smaller kind of organization in the leadership position. Just the knowledge of, okay, I can actually see the numbers that are being spent. I don't have a kind of, you know, they don't just communicate to me a percentage from HR that says, you know, try and keep, you know, try and keep it around this much, you know, as an average across your team. It's like, I actually know, I see exactly how much is being spent on everything. And that's quite sobering in terms of, you know, when it then comes to how do we spend the money. So you have to then take some quite tough calls.

It's always a trade-off and it's always a subtle dance of push and pull.

Absolutely.

Like, it's never an easy decision. And I think you don't really realize that until you're actually in those positions.

Yeah.

And you are responsible for this. And because you're coming, you know, from your career not being those positions, just being a developer asking for more salaries. Once you end up in these budget management position, you go like, ah, right. So he wasn't a dick back then.

Yeah.

You know, he made some tough calls and you start developing a little bit different respect to some of the managers you went through.

But I think to that point, Again, it comes back to that. If people, you know, if you're kind of authentic in what you, you know, obviously there's certain things you can't tell people, right? If there's movements around the business that are happening that aren't confirmed, but you've been given a heads up of like, you need to probably prepare yourself mentally for this. You don't, you can't go and, you know, do the same thing for your team because actually you're going to put more stress on them that they didn't sign up for. When it comes to things you can talk about, authenticity is good, right? Because then you understand if, you know, the people in my team and people I work with generally, one of the things I've always kind of wanted to believe to your question, to your kind of thought about earlier about what would people say about you when you're not there, right? I would hope that if people were kind of thinking about that in the context of me, nobody would ever be able to say, oh, this is Rob's opinion. Really? Because for better or worse, I do speak my mind. And so people always know where I am and I don't maintain different versions of my beliefs for the different audiences. The wording might change, the delivery might be different. You know, I might kind of pitch it more comedically if I'm venting. But the core opinion doesn't change.

Underlying message is basically the same. Yeah, just the narrative that changes.

Exactly, because I think sometimes you do have to be conscious that, okay, yeah, I'm in a meeting with external clients, I can't really, you know, I can't use the exact terminology I would use to describe this part of our process. I wouldn't— I talk about differently internally to how I'd pitch externally, whereas, you know, internally I might say, you know, more— what's the word— more direct things. To an external client, it's a need of improvement, right? Because both are true, and the underlying— again, the underlying core is this thing can be improved, but it's just different in how you kind of communicate that.

That's where the politics in the bigger organizations comes in play. Yeah, absolutely. Maybe even in startups, but I call it politics, but Yeah, it's basically that notion, right? Is that there's a— the underlying message is the same, but how you put it to your employees, which potentially are all your friends in startup because it's only 6 of them. Yeah. And how you put that in enterprise where you never met that person.

Sure.

And, you know, maybe behind that person there's big budgets which you're trying to manage. Yeah. And as a technology, you have that exposure as a technology person. Sometimes you have that exposure. Let's say you're dealing with with partners.

Yeah.

And it's development team you're dealing with. But if you're dealing with them in a certain way which rubs wrongly on them, they will, they will take that message and they will bring back to their executives and they will go like, well, work with them. It's actually quite tough. You know, they're doing this. It's just, you know, that message will come up to the, to the budget decision makers and suddenly all that relationship between your business and that, that external partner is getting in a frictional situation, right? So, so all of that communication with externals is important. So it's important who actually have these conversations, and they can go wrong so quickly in these sort of cross-business meetings. Absolutely.

And even inside a company as well, I think, you know, if you've ever been in a position— I certainly have— where, you know, oh, you're not supposed to talk about this, like, you can't assume that nobody will. Right, it's just naive. So, you know, it's similarly if you've got two companies where they know each other, you probably want to tell them both the same version of events because you can't rely on the idea that they're never going to compare notes about your, you know, what that you've told them. Oh, is that what they told you? That's completely different to what they told me. And you look like an idiot because you've tried to kind of have your cake and eat it too.

Diminishes trust as well.

Yeah, exactly. And so then it's going to be less likely to Well, even if they deal with you in the future, maybe they're obliged, right? But even if they deal with you in the future, they're probably going to find themselves like not wanting to tell you as much and they won't be as transparent with you. And when that transparency breaks down, it makes your job harder. And so you've shot yourself in the foot to kind of try and play both sides. And it's just self-defeating.

100%. That sort of leads nicely into Rockstar Developers, which I would like to see what you think about. I have this notion, which is the— well, it's not my notion, this Pareto principle, right? So effectively it means that 20% of people within the business or with the team will be responsible for 80% of the results, right?

Yeah.

And usually those 20 people is, is, you know, your high performers. It's just naturally people who drive everything, right? Or rockstar developers, right? So I've seen that working quite well in, in the startups because, you know, they become this like a very big driving force, uh, ideating well, creating well, you know, making changes very quick and everybody just becomes a support.

Yeah.

And it works fairly okay. But I've seen that being a big, big problem in enterprises where you have this single point of failure. Yes. Where that Rockstar developer somehow just as a huge sun, you know, in solar system just absorbs so much knowledge.

Yeah.

That when he or she leaves, everything just starts breaking down because no one knows stuff.

Yeah.

Right. Because complexity is just on a totally different level. So from your perspective, like, what's your opinion? Is that healthy to have people like this, or do you actually manage to not have that exposure? What's your take in general on the rockstar developers?

I think I'm broadly aligned with your point of view on that. I think the only thing I would say is it's a question of how that person is managed. And even in startup and a scale-up space, you can have this dynamic. What you don't want You can have that person, like you've outlined, who knows a bunch of stuff, smashes things out quickly, they know what they're doing, they don't need a lot of help, and they don't need a lot of support, and those other people can keep them oriented. What's missing from that is the follow-up, the documentation of how things work, that contingency planning, and that removal of that single point of dependency. Even in smaller environments, I've seen those people, you know, like the people who kind of, they go on holiday for a week and then people are coming out. Well, people are coming over to you saying, oh, how do you do this? I have no idea. I'll ask them when they come back. It's like, it's not, you know, it's not good. You don't want that, especially when it's critical business kind of process, even if it's not functionality. If it's critical business process, having that one person who knows everything, And I never want to become that person. So one of the things I've been very keen to do, you know, when I've been working at Cufflink is, as I'm learning, I'm typing it up and I'm then, you know, making it available, if nothing else, because, you know, on the day if I choose to leave, I want it to be minimally disruptive. So I want to be able to say, right, okay, I need to export these files, I need to put these in the network drive, and these are my passwords, and you're good to go. And I could leave the same day. I don't want to, but the point is, you always want to be in a position where that's possible. And the longer you kind of go without addressing those, it's a form of technical debt, is that kind of lack of documentation of how things work, whether that's process or codebase or both. People can hold a lot of knowledge in their heads without even thinking about it, but it's up to the people around them to be pushing them to say, no, write that down, or show me how that Show me how you do that because at least then we double the people who can, you know, we double the paths by which we can achieve that. So if it's one, you know, database process or one, you know, piece of documentation that needs to be produced, show me where that lives, show me how you get there. Because I can type it up because I'll document it because I won't remember, I don't trust myself to remember it next time if I can't do it for 3 months because there's no need. You know, if it's a process that doesn't get done very often, say, I don't know, a bug around daylight savings, right? Say you've got a process around daylight savings every 6 months. I'm not going to remember that in 6 months, how I did it before. I have to document it. I don't trust myself to remember, but people need to be, you know, those, those kinds of, I kind of think of them as like Maverick developers, like Rockstar's kind of, you're right. That's probably quite a nice, you know, a nice environment to have. The Mavericks are the ones who just kind of charge off and do stuff and don't tell anybody what they're up to. And so I think you've got kind of two types of person inside of the same category when we talk about it traditionally. So you've got the rock stars who are like really good at what they do, but they're actually part of the team still. And then you've got the people who are just kind of off in business for themselves. They're not telling anybody what they're up to. It's not to say they're doing malicious things. I don't mean it to sound like that, but you know, they're not keeping people up to speed on what they're working on. They're not documenting anything. They're just doing stuff. You know, maybe they're actually manipulating things on production directly. It's not good. Because it's, if you have a problem, you know, you can, you and I can both speak to this having worked in regulated industries over our careers. If you have a problem and you can't point to when that problem was introduced, you've got a bigger problem.

Yeah, you've got a big problem.

A second problem.

If it's not auditable.

Yeah, exactly.

That's a big, big issue.

And that's the problem that, you know, to kind of use that classic Simpsons thing, it's like, that's the problem that Homer today makes for future Homer, right? It's avoidable. And so, you know, when you take steps to document those processes or show somebody else how you do something when you're not there and write it down or whatever, or just at least have it living in multiple heads, you reduce that kind of risk on one person. And it means that those people can then move on and it's not massively disruptive and chaotic. Now, when I worked my notice at my last place, I had 8 weeks notice. It's a long time. I was busy up until the last day, but it wasn't frantic. It was just making sure that things got looked after and thinking about what have I picked up over 10+ years. But thankfully, a lot of it was either out of date because I hadn't worked in a team for 6 years or 7 years, and so the knowledge had moved on. Great, problem solved. Or I've been taking notes as I went, in which case I could just point them to the notes and away you go. The wheel stayed on the bus, surprisingly.

So what if— so I'll give you the situation. We have changes which are driven by non-technical people. So, you know, often commercial ones.

Yeah.

And you have something big which someone wants to get it done. And from commercial perspective, if you ever work with salespeople, you know, they have some type of bonus, incentivations, right? So if they can close the deal, they get bonuses. So, so they have this incentive to drive that. And I, I do see where they tend to find their ways into the teams and sort of jump over the real processes of, you know, here's what I need to do, talk with head of engineering, you know, get some agreements, you know, pass this over to product teams, get it done. But somehow they weasel in, especially in startups, straight to developers, and they go like, can you get this done for me?

Yeah.

And then, you know, they like, they don't know. They're like, okay, well, this is, you know, I don't know, just like head of sales or whatever. So I'll go ahead and do that for you.

Yeah.

This is a lot less in regulated, you know, big industries. But in startups, that was my huge pain, like huge pains to the point where, where we were sitting in a company and I physically reordered the tables so no one can walk in in the team. That's one way. So they need to go through the main doors to me, right? Yeah, where I sit at my desk. That was— that's how bad it was. Did you ever have like experience where these like, you know, things to be done getting pushed through?

Non— yeah, for sure. And I don't think it's unique to startups either. I think it can happen in bigger companies if the processes aren't good, right? If there's not a kind of clearly defined, unambiguous process for how to get stuff done, people exploit that, right? And they're not doing it maliciously, They just, they want their thing. They're motivated by what they need and what they need is delivery because otherwise there's this problem that they've already, you know what, they've already spent the marketing budget on the thing that then this product is going to tie into. So that's already organized in the calendar. So we've got a deadline. Okay, great. So then you go to the Agile kind of, you know, the Scrum thing. Okay, you fixed the date. We're not going to compromise on quality. So then the scope needs to be really, really limited. And you can't have all this stuff. And maybe you can have it eventually, but you can't have it— you can have these things before this day. I think one of the tricky things, and I'm experiencing this pain, possibly because of my own kind of lack of detailed knowledge on how certain functions work in kind of codebases, putting a number to that is really hard. When somebody says, how long does— how long do you think this will take? If you haven't worked with that product in a certain amount of depth, you don't have that answer, and it's really hard to come up with it. So you ballpark it, you just kind of add a couple of weeks, a month, you know, you start thinking in bigger buckets, like kind of planning poker, right? You just— the buckets get bigger because the uncertainty gets kind of bigger because the project gets more complex. So that could be— that's probably the most challenging, I think, is when it's hard to come back with a proper, something more empirical than, I don't know, ages. It's not a useful answer for them either. So it's a dialogue at the end of the day. So many of these things come down to how the quality of the dialogue and the quality of the process around it. So to your point, you know, about people coming to the developer directly and saying, oh, I really need this done, can you just squeeze it in there? So, okay, fine. So then if you have a problem and that results in an incident and you need an audit log, you send them to that person you asked for the changes because that's the only source of truth. So where did that change come from? Oh, I just wanted it. Okay. You can answer to—

why did you want it?

Make that person accountable for their decisions. I think that, you know, when you, when you kind of make it clear that accountability, where accountability rests, that simplifies some of the You're always going to have those chances, right? Those people who really want certain things and they're going to kind of push their luck and they're going to ask for things. They're going to kind of, they're going to know their channels. So you cut those channels off. So whether it's, oh, they always go to this developer. Okay, cool. You tell that developer not to respond and then they go, well, they've stopped responding to me. Yeah, I told them to because this is not how we do things. And you have to be a lightning rod for that. Kind of feedback because you're going to get complaints when that happens because you've slowed the process down as far as that person's concerned. And they're right. You've done it for, you know, what you hope are legitimate reasons, but you have gummed up the works as far as they're concerned. So you have to then say, okay, well, look, I've done this because I'm accountable for the output. So if it goes wrong, are you going to support me in that? Are you going to be the one to take the flak on this? And if the answer is yes, great. I'll send you an email to confirm.

Okay.

Because it's getting it written down. It's nice.

Yeah.

Because when you talk about writing things down, you notice that some people.

Yep.

They go quiet on that front because when you put it in writing, it's auditable. So you say, well, look, you know, we agreed on this date that.

Becomes a lot more real to their minds as well. Yeah. Saying and asking is a little bit different.

Making it real is a big part of it. And like I say, having process of, okay, you can no longer, you know, that I've not told you, you can't contact the developer. That's been made clear already. And that's been ignored. Okay. I tell the developer not to respond. And if they do that, if they do that, great. They carry on with their work and everybody's happy. If they don't do that, it's going to start counting against them. And you speak to that developer and you say, look, you're not answerable to this person. You're answerable to the platform or to the you know, to the department or however the, you know, depends on the company as to what the hierarchy is. But ultimately they know who they report to and who they're accountable to, and it's not that person. So then they're not gonna, you know, they're not gonna be in trouble if this goes wrong and you're caught out working on something that hasn't been agreed, hasn't been prioritized, isn't part of the roadmap you've been worked on, on the slides.

Okay, so, um, you mentioned a little bit about speed and delivery. So when these things come in, you know, you need to take this date out of your hat. And, you know, such a pain. I mean, it's such a relatable pain where, where big things are being decided, you know, money being taken, and now you need to sort of come up with a date. I think everybody shares that pain. You give a date and you, you know, potentially misshot that date, you know, something was underestimated, whatever is the reason. So now you're faced with this speed versus quality dilemma, right? So do you still try to get everything done in a speedy way and jeopardizing quality, which is your trade-off, or do you actually cut the scope out and you still maintain whatever is your quality bar? And if so, how do you— like, what's your take on this in general? And as well, how do you protect quality in these ways where developers feel rushed and that pressure of rushing is just felt, right? Essentially, where someone giving you hints and notes like, you know what, like, let's see if we can do this. Yeah, you know what, we really need to hit that date. Like, you know, that's maybe not direct pressure. Well, let's, let's have everyone in. Yeah, all hands on deck, we have to get hit that day. Maybe it's not as direct, but still, yeah, you know, everything gets the hint of that pressure, right?

Absolutely. Um, I think that, you know, I come from a kind of, like I said, I come I come from a QA background. As a result, as you might imagine, I'm quite a kind of hardliner on quality should be protected at all costs. I'm also, I like to think, a pragmatist. So realistically, sometimes you do have to compromise. I think the important thing is you commit to nothing until you have buy-in on what happens next. And what I mean by that is, okay, you've got your kind of MVP, right? And it's not gold-plated because that's already been kind of hashed out. You've already put those things in phase 2. Love it. It'd be lovely if you get a chance to do it. So not every project has that luxury, but you kind of agree your MVP. And then as you're going along, it happens, right? Stuff becomes, as you say, stuff is undersized, stuff is more complex than previously thought. Dialogue, communication with your senior leadership, your stakeholders. We call them SLT at Cufflink, but You know, every company's got their own kind of version of that kind of dynamic. And you, you tell them what the problem is. You know, we're working on this, this is how much progress we've made. We've run into a problem here because it's way worse than we originally thought. We think we can get these things done in time for the date. Is that enough? Because if it's not, then what do you want to do? You know, do you want to adjust the date or do you want to, you know, do you want us to kind of hack this together? If that's the option, you need to understand that we're going to drop tools after that date on new stuff, and we're going to have to go and fix this because we can't have this persist. Because, you know, again, technical debt compounds. Eventually, it gets unsustainable, and you get to the point where you're actually fighting, you know, part of firefighting is not just putting out fires, it's also fire prevention for next time, right? So making things more robust, making things more scalable, sustainable, all the good ibles. That's all part of the process of improvement. So, you know, when it comes to dealing with your live incidents, fixing the incident's part, like step 1 of a journey, because then you have to figure out why the incident happened, and then you have to figure out how you could guard against that, and then you actually have to go and do that work. You can't get that without dialogue. So I have to go to, you know, in my role, I have to go to senior leadership team with projects that have been asked of me and the dev team by association. I don't have an infinite scope of developers. I wish I did, but that's not something that scales as easily. So, you know, I have a finite bandwidth for projects, and then you also have to keep the lights on. So then sometimes you have to be devoting a certain percentage of your time to technical debt, bug fixes, maintenance, upgrading software versions, dependency management, all that stuff is all part of the dev team's responsibilities. Unlikely you're going to have an environment where you've got somebody whose sole responsibility it is to bump your packages up in your front-end framework, right? It's not realistic. Front-end developers are going to do that too, you know. So you have to present the whole picture. You can't say, okay, well, we're just going to prioritize these projects, Ignore the other stuff, ignore the technical debt, ignore your operations. That's all just kind of assumed. To a certain degree, yes, but you do have to kind of say, okay, well, actually, this project here to fix this problem is a big piece of work. So it needs to go in, it's at the level where it needs to be prioritized against your other new features. And you need to understand that these things have deadlines too. You know, lots of software versions have long-term support deadlines. Sometimes you've gone past that point and actually your version of code, you know, your code relies on a version of a software that's actually not got, it's not LTS anymore. It's gone into unsupported. So you're then exposed from a security point of view. And in regulated industries, as you've no doubt found, you can only absorb a certain amount of risk on that front before you really have to start thinking, okay, big bang change time. Because you know, the more you expose yourself from a security vector, the more you run into problems around cyberattack. You might have more likely to have data breaches. They can be expensive. Like the average fine, I think, is about £3 million for a data breach.

They're damaging as well.

Yeah, exactly. And you know, if you're a company who is handling sensitive information, so like, you know, I work in finance, so we have a responsibility to look after people's data and we take that very seriously. We have to make sure that we build controls into that to make sure that we're even just thinking about it from a who can actually see this data.

Internally.

Yeah, exactly. You need to think about those things. You have to think about all of it. And so when you're building projects, you can't just give them the shiny stuff to prioritize. You have to give them the whole, the full horror of the kind of scope of work. You have to crack Pandora's box wide open on that front.

Okay, so how much of this is automated and how much, how much of this is manual when it comes to quality assurance? And what's your take as well in your experience? I would assume that manual has this human element to it where if you have a very OCD person, you know, he's probably, or she will, will, will spot a lot more things. And then you can, on opposite, you can have someone who doesn't care that much and things might slip through. Yeah, well, automation, you know, is again as good as it can be coded up. And as well, you know, it's still a program, right? It's not gonna think as human. It's not gonna be able on that spot come up with negative tests, positive tests, or some, some, some random tests and stuff like that. So, so from your perspective, you know, is one better than each other, or do they actually have different environments where they are better than each other?

I actually think there's an extra element to quality assurance. So, you know, how much of testing should be automated? And in my opinion, it's as much as practical. And to the point earlier about a bug that happens related to daylight savings, there's a cost-benefit to producing an automated solution that fixes that problem versus automating a reminder to check it every 6 months. Right? It's automation of a sort, and it's automated quality assurance, because you're making sure that you don't forget about that thing that happens every 6 months. But you're also not necessarily building a solution that takes it off your plate constantly, so you never have to worry about it again. So there's always a trade-off with that stuff. There's always a cost versus, you know, is it worth doing the work? With my kind of, my experience has been that testers can, and to maybe be a bit harsh, should be automated out of existence. QAs should not and cannot, not truly, not fully. Even if you automate every test, and to be clear, I don't think it's practical to do every single test, automating every single piece of functionality coded, it's not practical, nor is it, I don't expect it to be anytime soon. But QA is an extra element as well, right? So when I was a QA, I probably spent 40% of my time actually testing. I spent the other 60 coaching developers on things to look for, to test like me, in terms of the kind of things I cared about, how we wanted the team to kind of focus on what kind of things, fleshing out requirements. Like QAs, There's a reason a lot of Scrum Masters kind of come from a QA background, it's because they've already done that kind of, that role of fleshing out and kind of digging to find, to kind of help to shape requirements. And that's another reason that also I think I've found a lot of QAs go into product ownership, because they've already had to put that hat on, the end-user hat, and they're already thinking about what's that user experience going to be like. And to the point, you made in the run-up to the question, automating all the tests is going to tell you that it works. It doesn't necessarily tell you if the application is any good. Is it easy to use? Does it look nice? These are things that right now, maybe, who knows what the future will hold, but right now, humans do that, and humans do that better than anybody. When I was a QA, it's why I guess it didn't really worry me that I wasn't particularly kind of savvy with automation, because I was adding value in different places. I was making sure that we were building the right thing before we started building it. And actually, I think QAs have underserved potential to add value even before the code is written by making sure that you think about all the scenarios you want to run through. Putting yourself in the frame of mind of a user, actually checking whether the product owner has an opinion on how things should and shouldn't work, because you mentioned negative tests, right? How should something work? Okay, it should do this. What does that mean though? Oh, they should be able to choose an option. What kind of options do you want them to be able to choose? More than one? Do you want them to be forced to choose from different ones? That definition matters in terms of what solution you build. Because even the smartest people, and I've worked with lots of very smart people who nevertheless, when pointed in the wrong direction, will build the wrong thing. Because they're building, if they're under the impression what they're building is right, they'll build a really good version of the wrong thing, a really solid, high-quality wrong thing. So quality, you know, QAs have the potential and the power to keep the ship oriented in the right direction before it sets sail, pointing it in the right direction. And I think that's where, that's something you can't automate away. It's, that's where the value add can be for QAs, even if you've got high automation test coverage. The ones, you know, you mentioned kind of the type of person who doesn't really invest in the sort of, you know, in the product and doesn't really kind of get get involved. Those are the kind of people who, again, they will be automated out of existence and they will end up moving into another field. And fair enough, good luck and more power to them. But the people who will endure in the quality space are the people who, when they're freed up from the drudgery of the manual testing effort, what else can I do? Where else can I add value? That's a mindset that everybody should be adopting. Where else can I help? How can I help? Just that kind of, that thought process. The number of times we solved a problem before we wrote the code for it by sitting down, having a dialogue, QA and developer, even just to read the acceptance criteria and say, do we understand these the same way? This is how I understand this first one. Yeah, me too. Great. Moving on. This is how I understand the second one. Oh, I thought it meant this. Oh, interesting. Okay. Product owner, what do you like? We've got two different versions of events here. What do you want to do? And they'll tell you, and then you go with that one. And you can hold strong opinions, but you can't hold them too strongly on that front. You have to be able to let go. If you come in with a point of view on how things should be done, and we choose a different one, great. We'll just build that one. Oh, my idea didn't win. No, but the team will when you don't build the wrong thing because one person steered the ship in the wrong direction when somebody was out sick that day because they were the one who actually had the right idea about how it should be interpreted. But they were off that day. They weren't at the wheel. Somebody steered it the wrong way.

I love the trio which you just mentioned, the developer, QA, and the PO.

Yeah.

Just like just 3 people talking and aligning.

Yeah.

Of the actual right thing being getting built. I think that's overlooked.

Yes.

And understated because often QAs are not part of this process. It's often that, you know, the POs, their leads.

That's my point, right? And I think it's to their detriment that they don't get hands-on with that side of things because again, it opens up career paths. Like I said, I've seen a number of QAs go into product ownership roles. And the reason is because they've already started to kind of dip their toes in that water. The people who stay in testing and only, you know, I'm a tester, I only test. So if you stick to one role for your entire kind of career, you shouldn't be surprised when the opportunities kind of become a little more precious and a little more competitive.

Okay.

Because as the need for those reduces, there are fewer roles and the number of people competing for those roles will stay the same. Or, you know, if people aren't moving kind of in and around or trying to jump to different disciplines or pick up new skills, they can maybe leverage to do something else.

I love that. I mean, the value add which you just mentioned, I mean, you just gave me some ideas or a new appreciation for QAs. So thanks for that, Rob.

Yeah, well, I've always kind of been a, you know, a strong, I feel, you know, a strong champion for QA because obviously it's something I care deeply about. You know, I kind of find myself unable to switch it off. It's like a literature student who then can't read a book for fun. I find I use, you know, I'm using apps and software and services and I'm like, man, 'Yeah, it's like, why isn't this slightly— I wish this was slightly different, like this, but slightly better to use.' Yeah, it's just your essence, isn't it?

It's just who Rob is. You can't turn that off.

Well, yeah, maybe I shouldn't. I don't know.

You shouldn't, of course, because that's— you are where you are because of who you are. And, you know, I'm sure, you know, that, that eye on that quality is a big piece.

Yeah.

Of how you look at everything you do. Yeah.

And it's something I've kind of brought in, you know, I've tried to take that into, into Cufflink. And, you know, Again, where do I add value? So it's being able to communicate, being willing to document, being willing to kind of go and find problems and rip the lid off Pandora's box. And sometimes if you're really unlucky, it's a matrioshka of Pandora's boxes. Oh my God. Oh my God.

It's like, where did I get myself into?

Yeah, how did these keep— they still can go smaller. But, you know, that's the— that's where I think, you know, I kind of have always been able to add the most value is kind of being in that, being in that role, being that kind of being willing to, you know, absorb that.

This is where we stop for today's episode with Rob. After diving deep into the organizational dynamics of startups versus large corporations, we have explored how different roles and expectations shape the work environment in these diverse settings. We also begun touch on the pillars of quality assurance, discussing the initial strategies essential for ensuring excellence in product delivery. But there's still more to unpack in this critical area. In our next episode, we'll continue our exploration of quality assurance, going deeper into the advanced processes that define success. Plus, we'll tackle the topic of leading through change in a hybrid work environment, addressing the evolving challenges and sharing effective management strategies for today's shifting work landscape. Subscribe now and make sure you join us for part 2 of this enlightening discussion with Rob. We'll provide you with actionable insights and expert advice to navigate these complex topics. Thank you for tuning in today, and remember, the best insights often come from understanding both sides of the story.