Defining Productivity in Tech: Insights from Rob Wade Part Two

How do you measure quality of this process? I mean, don't like— so when you were talking, I was like, okay, well, that's all good in its own merits, and I do see that value-add. Yeah, but it does feel, you know, conceptual, like, or conversational. The only thing which came to my mind is DORA metrics, which is the change failure rate. Like, you know, if you have good QA, yep, It doesn't matter how much we ship.

Yeah.

You know, the change failure rate should be constant, right?

Absolutely.

That's our quality bar. Like, that's one measure. Is there any other measures which you yourself was aligning to as a, as a QA in your background?

I think having, um, this requires quite a lot of setup, like in terms of your process, but if you've got a reliable measure of when things move in and out of status, and so let's say take Jira as an example, or Monday or something, you've got your workflows kind of programmed in. You can look at how many times things bounce back and forth between states as a measure of whether you're doing that right. Because if you're bouncing back and forth between states constantly, once, you know, okay, once is a misunderstanding, or I didn't do it, didn't, oh, it's not quite what we missed a test case or something like that happens. A prolonged repeated bouncing back and forth is a fundamental breakdown in interpretation of how things should run, because you keep finding You keep getting there and you keep going. Ping pong. Yeah, it's a ping pong match. Like the early kind of dynamics I had in my last big QA role was a tennis match. There was an adversarial kind of us and them with QAs and devs. And I think part of the reason for that was the way the business was set up. So you had a pool of QAs who would go to projects. You didn't have QAs embedded in a team when I first started. That changed because I think what happened was, you know, not just me, but me and others like me in different teams were kind of embedded in the teams for a long term, and actually you noticed that those teams kind of worked nicely. And I think it kind of diffused that antagonism. I think, you know, where I encountered it a lot was if I was kind of seconded to a project for a couple of months, just while they figured out what I was doing next internally, I would kind of get more of a 'Oh, the pedantic one's found a problem again.' It's like, well, yeah, that's my job. Literally what I'm here to do. The best compliment you can pay me is that I'm a pedant, because that is why I'm here.

And finding issues, that's like, yeah, high five. That's my OKRs.

Because certainly with technology leaders I've spoken to, this has been kind of well understood, but the worst place to find a bug is production. The most expensive place to find a bug is production, because not only do you have to fix it now, and you might be losing money while your bug is in place, you might have lost money up till the point it's been noticed, and you have to drop tools on the other thing you were doing, which means you're now context-switched out. So you've had a hit on your productivity at that moment, because you're working on, you know, ticket 114, and there's an error with 112. You have to drop tools and go and sort out 112, bring it back, maybe do 1.15 or 1.12.1. In the meantime, 1.14 is stalling and you're then going to have to sort of take the hit to pick it back up. And you know, you're going to have the cost, the kind of cost of delay built into that. I think, you know, that's always a kind of, if you get buy-in for that mindset in a team, that production's a bad place to find it, then you have an easier life because they don't want it to happen that way. And Where you can use data is, in fact, I can speak to an example of this. So this wasn't my initiative, this was my manager at the time, but I always liked this. He documented, he went through this manually to start with, just to illustrate a point, every single ticket for months and months and months, and he tracked how long it spent in each status in our workflow tool. And he mapped that data out and he came up with an average, and then he also presented the raw data to the team. And all they did was say, here's the data, what do you think? And they just, you know, what jumps out at you? And what we zeroed in on, there was a period of time where the changes were done, and then they were sitting there ready to be approved by our change advisory. We had a change advisory because it was regulated. And then the question became, why is that taking so long? And the answer was because one person in the team was the only person who did it. So the entire team en masse adopted a new mindset. Your ticket is done when it's on production. Because until that point, the unspoken agreement of done was it's ready to be approved. As soon as we changed that goalpost and said done is now production, all the devs started picking up their own tasks and getting them approved. And just the throughput just went shooting up through the roof because that time spent in approval state was just one of the big bottlenecks because there was one person in the team responsible for it. So just sometimes data is really powerful in that sense. And like I say, if you have a reliable, and this is one of the challenges that you have to kind of have that scaffolding in place. If you have a reliable measure for how many, how things go kind of through the different states, then you can identify things like it's bouncing back and forth a lot, which means it's It's a, you know, it's a tennis—

Does Jira have that? I'm just like thinking you're talking and I'm thinking about all the internal reports Jira have. I've never seen anything.

So it's a— so Easy BI is the, is the most powerful tool that delivers that, but annoyingly it's a paid add-on. Yeah, I'm trying to get buy-in.

So yeah, there's a lot you can buy for Jira.

Yeah, I mean, this is the thing, but I think it's, you know, the modular plugin-based approach is kind of good though, because the alternative is you pay a much bigger subscription fee for a bunch of stuff you might not use. I like the kind of choose what you want model as well.

So it's got a lot— there's one of the challenges you with regulated markets is that it needs to go a very thorough, you know, investigation of any third-party tool you want to bring in, which prolongs your time of being able to get it. And not everybody's able to pass these, you know, and all that stuff.

But having worked in the scale-up space now, I can appreciate that actually a certain amount of that is good. Yeah, because the alternative is the wild, wild west, right? Everybody's buying, oh, oh, I quite like the look of that subscription, we're up, we're running. It's like, well, hang on, what? Where did this come from? Like, what are we— oh, we're putting loads of that. We're putting all sorts of stuff into it. It's like, what stuff? Because now we have another data dependency. Now we have a place where personal data is being stored. This stuff needs to be a little bit more joined up. And this is the, the, the, the challenge is finding the balance, the sweet spot between the two. So having a world where you have excessive bureaucracy and you can't actually move the needle at all versus everybody's in play all the time and everybody's making decisions and everybody's got input and everybody's got a point to kind of prove and they're all going off and doing their own thing. You want to kind of find a way to rein that in. And that's kind of one of the things that builds scalability is having a good, like a kind of good lightweight flexible process that's scalable. Because otherwise you just, again, you get bogged down in bureaucracy or you don't have any process in which case you get the results you get and you can't really, not really much you can do about it.

Yep, I agree. It's always a trade-off. I mean, that the beauty of everything we do, and I think it's not only tech, there's always a trade-off. Like, you're never ever gonna get everything you want. There's gonna be a sacrifice, and you, you will choose depending on the context at that given time and whatever you want to achieve. Yeah. So we talked about QA quite extensively. I feel like maybe there's no answer to that, to the next question, but is there like one aspect which you think is highly overlooked by others when it comes to QA? It's like when I say others, I mean like developers, POs, business people where you know that QA, you know, maybe bring that value add, maybe do something else, but it's just not being seen in the right lights.

I think it's that dialogue piece. I think the opportunity of being able to kind of shape stuff before you start building it is the bit that, you know, QAs can act as kind of blueprinters to help everybody get on the same page in terms of what we're trying to achieve. And I think that that's something that actually is overlooked by some QAs as well. I think some people—

They don't understand that they actually have that influence.

Yeah.

If they did, I think they would do that well.

I think, you know, being willing to seize the, you know, to embrace the opportunity that lives in a vacuum in terms of, you know, if there's a void of responsibility, then there's an opportunity you can take. It's like, well, actually, if nobody's going to have that, I could do something really cool with that. So I'll take it and I'll do that. And then you can lead by example. And if you do it well, then others will follow suit. And then you can potentially— this comes back to the point we were talking about earlier, right, with embracing that you can have creativity. Similarly, you can make impact in a big company because if you do something sufficiently well and people see it and go, oh, that's really cool, we should do something like that, you've made an impact because you've had this kind of ripple across the rest of the business where they might not take your process wholesale, but you've built the foundation on which they will build further. So then you've kind of been able to sculpt that and take that forwards. And I think that's great. Like, it's, it's a, you know, it's, it's the most validating thing I think you can have is that people are— again, people's lives are easier because of something you've said or done or made. That's like the most rewarding thing I can think of is I made somebody's life easier by doing something. That they can leverage.

Yeah.

Um, and I think that's, yeah. And I think that's the thing that kind of the opportunity that QAs have that gets kind of overlooked most commonly by, you know, by QAs themselves because they see, because maybe the narrow, the scope of their role has been narrowed, kind of imposed upon them. Just push it. Like it's one of the most, I would say, I'd say QA is a, is a quite an underappreciated discipline in a business. And as a result, I think that, you know, QA should do everything they can to—

So that appreciation piece, Rob, it's— I agree. And it's often, which I think doesn't really work that well when it comes to hiring and offshoring QAs. So you have— I've seen that done at least in UK where you have, you know, the core product and development team you know, local to London and they all meet, and then QAs are being hired like in India, and this sort of sits like this, you know, protection layer of the quality. So with that distribution setup or hybrid setup of teams, which I know you're exposed to as well, yeah, it's like, what's the biggest frustration of running such setups?

I think the biggest challenge is around time in terms of if you've got people who work on a kind of standard day in their territory, you lose the kind of point, you have to have a minimal point of synchronization where they can actually touch base and compare notes with. And if you have developers that are distributed geographically, one of the things I've been kind of keen to do going forwards is if I'm hiring, you know, if I'm outsourcing or kind of looking to contracts, I will look to kind of keep a certain timezone variance as a boundary. And it's no reflection on the work that those developers do, because I'm sure, you know, you probably get this, in fact, actually, as a podcast host, you might get this more. LinkedIn, I'm constantly being made brutally aware of how many great services there are I can leverage around the world, right?

So nice way, Yeah, and that's the nicest way I can put it, right?

It all comes from a nice place. They want to do their best work. They want to do stuff. I'd love to be able to accommodate them all, right? But again, my budgets are finite and my bandwidth is similar. So, you know, when I look at those things, it's no reflection on, you know, an outsourcing consultancy based in Vietnam, let's say, that I can't use them. It just, it doesn't suit my, how I want to build. So, you know, I think the, where I'm trying to, you know, take Kufflink forwards and for our specific, you know, for our specific use case, we have already some geographical distribution. I want to make that, I don't want to exacerbate that any further. So, you know, with developers, it can be tricky, even if it's just different developers in different territories, like to the point about developers and QA. Having developers and QAs in a different geographical kind of time zone or in a different location is one challenge. Having developers in different ones is also kind of equally challenging, if not more so, I would say. And obviously then it becomes logistically challenging if you want that person. So maybe you've got a rockstar, you know, that you really value highly. They do great work for you. They take on a tremendous amount of burden well beyond the scope of their role. And you want to really show how to appreciate them, probably going to have to fly them out and have them meet the team. And so that means there's an extra logistical challenge to kind of get that done as well, because you're trying to do that in amongst the day-to-day operations of the business as well as new features and keeping the lights on. So I think, I think I've lost the original question.

What was the big frustration? But I think you answered that, Rob. It's about the time zones. It's about the alignment piece. And I, I resonate with that quite strongly as well. It's if you have Um, the time overlap, it's not comfortable.

Yeah.

Uh, you pretty much become asynchronous team by default.

Yeah.

And as people work when someone sleeps and someone sleeps when someone else works.

Yeah.

Which changes communication patterns.

Absolutely. And it's not to say that, you know, even a couple of hours difference can't be disruptive. And the classic example I would always point to is at my last place, we had a really great team in Estonia, right? It's only a 2-hour time difference. But when they went for— they would go for lunch just as we kind of started our day. And as they were coming back from their lunch, we were going on ours. So actually, there was still a challenge there in terms of they'd want to book a meeting at 1 o'clock. Yeah, I was really— I hadn't had a chance to go and get anything to eat, so I'd just sit there and suffer.

It's such a simple thing when you're like— yeah, and you, you so much need to be aware about these hours. So I have like 4 clocks on my Mac, and I always, when I book a meeting, I click on it and I look WhatsApp, because you put the meeting in and you don't really realize that it landed on lunch for someone, or 3 o'clock in the morning. Yeah, or you— and when you're on a receiving end, you go like, oh my God, this guy again. No, I got— you know, I need to change my lunches.

Yeah, and they're not highly paid lawyers, right? If you're a highly paid lawyer, if Japan calls at 2 AM, you take the call. Yeah, right. Developers are not in that space, right? They're not working on a, on a work of that scale, and the, you know, the not as much hinges on them doing their thing there and then.

There you go. So you should be taking that hit rather than putting their head on developers when it comes to that time alignment. So effectively, we expect them to be on our time because, you know, operations get led from whatever is your headquarters. Yes, let's say London. So by default, you're going to be pushing your expectations onto them when in reality should be, in my view, should be opposite. Like you should be facilitating their timelines and then it becomes a challenge. It's like if you're buying in these different time zones, it's like how Will you, will you wake up at 7 yourself?

Yeah.

Will the leadership? Probably not. So you're going to be offloading. It all becomes this push and pull again.

And again, it comes down to, do you then have to, you know, if you put good process in place, you might be able to ride that out. If you put good comms in place, if you have good mechanisms for that stuff, you can endure, you can weather that storm. It's just how long for, and is there a better way of doing it? And sometimes there is.

So leading to a better way. What is your— from all of these, we all in office, hybrids, uh, so we are distant but we're not remote, such as like, you know, it's very popular now in UK where people live, uh, I don't know, an hour train ride from London in a, you know, areas, and they just travel in maybe once, a couple of times a week. So it's like a hybrid, it's distant but it's not remote. And we have fully distributed where you have, you know, a couple of time zones, maybe more time zones. Let's take GitLab. Let's take Zapier, you know, where fully remote distributed teams with like 16 time zones, a full, you know, 24/7 sort of coverage. From all of these ways of working, it's like, what is your favorite one?

For me, so I have, I can talk about what works for me personally. And, and then, you know, to be honest, that's kind of, you know, what I've, what I've built my kind of departments around is, um, for me personally, I'm a hybrid person, right? I I've never liked fully remote working, even before kind of pandemic era when it was, you know, something I could do, but it was, put it this way, if I put in for a working from home request, they knew that I'd exhausted every possibility to not do that.

So, you know, we know Rob.

Yeah, exactly. It's like, I know he's not going to have a good time. He's not going to be, you know, but then I think that comes down to reputation, you know, reputation internally, right? If you're, if you're seen as reliable, Again, if you're authentic and you're seen as reliable, you will get a certain flexibility that you will be— because they know you're worthy of it and they know you're not going to— they're not going to regret giving that to you. Me personally, I've kind of softened on remote working and obviously being forced to do it for a year and a half in the pandemic era was something that helped that process along, but it really is situational, you know, I think about my role at Cufflink day to day, being on site is actually quite advantageous. So for me, the hybrid rhythm at the moment is probably 80/20 office versus home. That doesn't mean that's what I've given my— that's what I've negotiated for my team. My team has a slightly better version of that because they're doing a different job. So I think it really depends on the role and how well you can do it remotely. Having said that, I do think there's something to be said for being in, you know, co-location. I mean, something like this, for example, we've met for the first time today. We've talked a bunch, but this is the first time we've actually met in person. I can imagine it being a very different dynamic had we done this remotely for the first time. And I think that, you know, there's a certain amount of, you know, whatever the percentage is of conversation that's nonverbal, that's, you know, a portion of that is body language. If you're just seeing that part of the person, especially if they're on a dumb filter or some background that puts them in the Millennium Falcon or whatever it is— I did that during the pandemic, I can't— I'm a hypocrite for that. But, you know, if you've got somebody who's just kind of visible from the neck up, it's not— you lose a little bit of that interaction, I think.

Rapport and connection. Yeah.

And I think that, you know, There's risks to that, inherent in that, for both the businesses and the people, you know. And I think that everybody's got their opinions on remote working, and LinkedIn makes that very abundantly clear, that everybody's got their opinions. And there, you know, there's everything from, you know, there's zealots on both sides of the aisle, and then there's kind of people in between just going, shut up, shut up. But, you know, for me, I kind of sit with My hybrid rhythm depends on the kind of work I'm doing. When I was a pure engineering manager in a pure tech, it was, you know, being at home 3 days a week was, I could get loads done. The nature of my work at the moment means that actually being on site is quite useful. It means I can get certain things done a lot more quickly. But there may be a time in the future when that shifts, in which case I will kind of look to you know, to rebalance that. But right now, you know, hybrid with a kind of leaning towards office space is kind of suiting me better.

I'm hybrid as well. You know, I tried all of that and I do feel that the hybrid gives all the parties involved the shared value. You know, you get that time at home which you can do some things around that commute time. You save that time, you save that money. Then you come to office a couple of times, which means you give what the business wants to have offices which doesn't feel like it's Wild West and there's like 2 people working in that.

I've been in those offices. I've been on— yeah, I used to have—

why are we paying for all of this? It's like 3 people.

I used to have a habit of, um, I used to go into the office on a Friday because I knew it was a nice quiet space, but I'd still get to see people. So it's kind of a nice balance of I get to interact with some people. There were a few people who I really liked working with who actually did the same thing, so I used to get a kind of FaceTime with them a bit more. But I also knew that it was quiet enough that I could kind of— I didn't have to stick my headphones in to be able to focus. And I think to your point, actually, one thing that I've always found about the debate about remote and hybrid working is there's a disconnect in terms of the definition of productivity, right? So this is a bit of an exclusive because I don't think I've voiced this publicly anywhere, so you can have this.

We'll put it in a sneak peek.

Yeah, exactly. So what I've kind of The conclusion I've come to is that I think businesses and individuals are defining productivity in a completely different way, neither of which is invalid. So it's important I stress that upfront. Businesses talk about productivity in terms of, we're paying you for your time, we expect you to work for us during your time. Not an unreasonable position. Employees are thinking about productivity in the sense of, what can I get done in a day. And that definition, again, nothing wrong with that, but it stretches to, I can get a load of washing done while I'm doing my work. I can set the machine off, come back to my desk and work. And I can't do that from the office. That's an added, you know, that's a value add for working from home. I can deal with, I'm trying to think of another thing I do if I do work from home, something I can do, save money on going out for lunch. I mean, not for nothing, but during the pandemic here, very early on, I lost a ton of weight because I wasn't eating in London anymore because everything I was eating was street food. So it was all rich and all fried and I was spending a fortune. Within about 2 weeks, I'd shed so much weight. It was unreal because I'd gone from that to, you know, you make sandwiches every day or you go down to the local Co-op and that's about it. Other supermarkets are available. So make sure you don't get any— protect you from any kind of trading standards disputes. But, and I think, you know, those two definitions aren't entirely incompatible with each other, but they are different and neither one's invalid. So it's actually quite a tricky thing to navigate because when you're talking about productivity, they're actually coming at it from two completely different angles. I think the missing piece is that when you do things like tidy something up around your house that's been bugging you for ages because you're waiting for something to happen with your code or something to be deployed or something to be approved or whatever you're going through day to day, you'll worry about that little thing, that little bit less, and it will take a kind of a mental load off you. And enough of those things will make you more productive by definition because you're juggling fewer things in your head. So I think, you know, there's two things that need to kind of happen simultaneously. The people who are really kind of like I say, you know, the zealots on both sides need to acknowledge that the other side has a point in terms of the definition. So the people who are kind of all remote, gung-ho, rah, rah, rah, need to understand that actually it's not an unreasonable position to expect people to focus on, you know, work for pay. And then on the other hand, companies need to embrace that productivity, you know, people can be more productive not just by getting more work done, it can also be clearing their deck to then focus more on the work and deliver better results. So I think that's something that doesn't seem, from my observations, now granted, I don't spend a lot of time on LinkedIn because there's a lot, you know, I've got a lot on during the day. So, you know, that's very, very much low on my list of things to do in a typical workday. There's usually 10 other things that I need to make progress on. So I haven't seen that discussion kind of acknowledge that, that disconnect in the definitions. And I think that's one of the reasons that these discussions become, for lack of a better word, they're not as productive as they could be, because I think that people are talking past each other in that respect because they're defining the terms differently and the goalposts are not the same goalposts.

Yeah, so yeah, the, the, the debate, yeah, is not happening in that, in that area where, where a mutual move forward is being looked for. It's—

it's— no. And I think that hybrids, you know, I've even seen people saying, oh, if it's not 80% from home, it's not hybrid. I'm like, get, get in the sea. Honestly, it's like, we, we have enough trouble having this discussion without people then drawing the lines in the sand in hybrid, which should be a spectrum, so, so viscerally. It's like, no, that's— that you're welcome to hold your opinion, but it's a bias.

It's a— it's a— what's the bias called when, when people just remember a couple of years back Something about—

I know the one you mean, escapes me.

Yeah, like, yeah, it's that kind of situational recency, isn't it? Yeah, here it goes, like a recency bias. I think that's the definition where people just, just think about a couple months back or a couple years back. And, you know, I always like when I talk with the huge proponents of fully remote, I'm like, just take 5 years back, you were 5 days in the office. Yeah, what are you talking about? Yeah, like this is such a young notion of everybody, the business and employees, workforce realizing, yeah, what is the best way forward. But I think no one's arguing that there's a value add for people.

Yeah.

And the businesses, you know, I don't think there's real argue around value add for them as well when it comes to productivity around like time flexibility.

Yeah.

You know, you have people starting families and they, you know, maybe they can start later in the day.

Yeah.

Because, you know, they need to drop kids in a nursery, but then they will finish later in the day because the kids go to bed like at 6 and they will, you know, use a couple of hours. That dynamics overall, you know, That's a flexibility I can get behind.

When it comes to my team, I don't have very kind of strict requirements in terms of, again, stuff happens, right? You're driving to work, you're stuck in a bunch of traffic, you're going to spend all your time in that traffic. I'd actually rather they turn around and work from home at that point and make the, you know, if they're delayed, they make the time. I trust them to make the time up. So if I trust the person fundamentally, I know that if I give them something, they will, you know, embrace the gift that I've given them, right? If they see it as, oh, well, I'm entitled to that, so why would I be grateful? Well, that tells me something about that person, right? Like, I can't fully relax because they might not make my life easier. And I think, you know, that's where transparency in a team and if you have a good culture in a team where they can share things and talk to each other about stuff fully, because I didn't, I've never cracked this, right? Just to be clear. But, you know, I've had conversations before with people in the team where they're saying, oh yeah, I've not been to the office, but nah, the team, you know, we're getting on fine. And then you speak to the rest of the team, like, they're not available, I can't get hold of them, like, they're not, you know, I can't, they're not really helping the team, like, they're kind of not really there. It's like, well, then we have a problem, don't we? Because again, we're defining productivity completely differently because somebody's saying, oh, well, I'm on, you know, if they need me, they can message me. I said, well, I shouldn't have to, like, you're here to work. It's a very, as you say, it's a young world, that kind of hybrid work and remote, and we're still puzzling it out. And, you know, even in the last company I worked for, which was the bigger sort of, you know, full tech piece, we hadn't figured it out fully. We were still kind of, when I left, they were still navigating that terrain. And then I've gone to a scale-up and it's even more you know, even more profoundly behind the, you know, the discussions shifted very drastically since I've been in charge because, you know, it's about communicating to the stakeholders. It's like, well, actually this job, you don't need to be physically present to do this bit. Will I want them in the office? Sure. But, you know, I don't want, I don't need them here every day because their job is doable from anywhere. They can do it wherever they've got an internet connection, but this is what I'm going to ask them to do. And my requirements are usually pretty basic. I just want to know when they're doing stuff, and I want them to ask rather than tell me, because again, it's an attitude thing. If somebody's got an attitude of, can I do this, as opposed to, I'm going to do this— like, intent is great when it's, you know, initiative. When it's just, you know, I don't know how to explain this. I'll stop there. It's, I mean, there's different concepts in which kind of that forthrightness is valuable and when it's actually quite unproductive.

So I call them work ethics and just, uh, you know, just accountability, you know, self-management. It's, it's all these, yeah, you know, maybe washy-washy terms, but they're very real in the sense of, yeah, if you, if you're quite junior to your career and you maybe you're quite junior in general, so let's say we, you know, we're hiring some, some you know, entry-level, maybe a little bit more mature engineer, and you give them a full remote role, you know, for me that's almost like, do they even know how to self-manage? Like, do they even understand, you know, how remote is run? Will they be able to ask the questions? Will they be able to find the answers? And, you know, things like that, because they're alone home. Like, you can't really spot them getting lost.

Yes.

In a way, in office, you like, you see people getting lost.

They're like, yeah, or you walk past their, you walk past their screen and they've got the bit of code open, it's been open for 3 hours and nothing's been changed. It's like, exactly, they're stuck. So I'm gonna, I'm gonna lean in and ask how it's going.

Exactly. And so some are not in the position of actually asking for help, you know. Does it— they, they perceive that as a, as a negative sign on them as people. So they will tend to work things out. And once they, you know, at home, how you sort of sense that, because you have like some type of morning stand-up and you, you know, you're asking how they're getting with work and they go like, you know, I'm still on the same ticket, and you're like It's been 4 days, man.

Yeah, what's happening? Yeah, yeah, you must have at least made progress. Tell me about the progress. Yeah, well, actually, if there's no progress, and then, okay, yeah, we have a problem, and we've now lost 4 days to find— to that problem not being surfaced.

So it's not always where it comes from, this entitlement of, of, you know, I'm remote, so what, you know, I do whatever. And, and as well, you know, there's, there's gotcha where you actually get lost in, in daily works, you know. I, I'm guilty of that as well. Sometimes, you know, I go, I'm gonna do this, but I'm gonna go down and have a coffee. I go down, make coffee. My wife's like, you know, we're going to make coffee together. And then it's like, okay, what about this? Well, you know, the kid has something at a nursery. Then you get in a conversation, you come back, it's like, where was I? It's like 2 fucking hours. It's like, what the hell happened over here?

Absolutely. Yeah.

So you get sucked into that, you know, daily life and that self-management and self-awareness of that you actually are during business hours and you should be doing work. Yeah.

And that cuts both ways as well, right? Because I've also seen the converse of that, which is people who are reliably on 80-hour weeks because the hybrid thing has the ability to then stretch into, oh, well, I can do a couple of hours tonight and it will save me time tomorrow. It doesn't always hold, right? Sometimes 15 minutes of work today saves you 45 minutes tomorrow because you've not lost the context and you don't have to switch back in. It doesn't always hold, right? So sometimes you, oh, I'll do 2 hours of work tonight and I can start a bit later or I can, you know, relax a bit tomorrow because it will take the pressure off. No, you're just going to do another 10-hour day tomorrow. And it's not sustainable. And I've seen similarly, people have to have discipline about when putting in the hours, as in putting in, delivering some value for that time. But they also have to have discipline to stop themselves from going too far into the being busy and not productive. Because that's the danger, I guess, of remote work is it can also lead to people kind of stretching the boundaries of their work because they feel compelled to, oh, I haven't really, you know, it's an anxiety thing. I suffer with it. You know, I spend a lot of time wondering if I've had a good day in terms of getting stuff done. One of the ways I've kind of found to kind of combat that from, you know, my own inner, you know, not demons, but my own inner monologue is to, is to, is like you said, journaling, like just writing stuff down. Just, and just crossing it through. It's really satisfying as well. Just like making a list of stuff you're gonna, that is on your mind to do, just crossing stuff through when it's done. Digital doesn't have the same satisfaction as crossing something through on a notebook.

I do agree. It doesn't have the same satisfaction. I used to do app. I mean, my day starts with, you know, I'm there in the standups, but I'm really there just to listen and then pick on bigger things. And if there's no bigger things, I tend not to talk and I'm just listening. And while this is happening, I'm putting items into my to-do list, what I'm attacking today.

Yeah, same.

And then, you know, I'm just crossing them over. But that's, that's how you have an auditable way as well to reflect back and go like, okay, well, that was a good day. Yeah, well, that was a shitty day. Yeah, let's pick up some pace today. So let's just make sure that average is there, right?

Yeah, I think that, you know, where I've found, you know, I've encountered lots of people who are trying to do too many things at once, and if they don't document, they're lost. And you can ask them at the end of a day, literally the end of the day hasn't even finished yet, It's like, what have you done today? I can't tell you.

I did so much, but it's like—

It's busy idiocy, right? It's just, you're just looking, you know, you're kind of looking for stuff to keep you busy and you're throwing yourself in 17 different directions. You're not giving anyone your proper full attention or energy. And guess what? Down the road you find out that actually what you've done isn't very helpful, isn't very good. It doesn't scale.

But it does feel busy though.

Yeah, you feel busy, but then somebody asks you what you've actually achieved and you've got nothing. And it's not a good feeling.

Yeah.

You know, so I sympathize with people who kind of, who my coaching is always to find a way to reflect, be able to reflect back and say, actually, these are the things I've done that have been valuable.

Yeah. I remember I had that in one of my first performance reviews and, you know, it was like, come with a list and tell us what you did.

Yeah. I was like, yeah, where do I start?

Yeah. It's like, how do I even approach this process? You know, look at the tickets. I don't know. Look at my emails. But it it caught me off guard to some extent because, you know, I'm like, I'm working all the time. Yes. But then it's like you need to sort of put your finger on impactful things. And that's where I sort of developed this high impact notion that I really want to take initiatives which I drive, which have big changes, and I just want to drive these initiatives. I'm getting sucked into business as usual to hell. But the moment people don't need me, I'm back to my initiatives.

Yeah, it might sort of—

I have I make sense of my work.

Yeah, and it's not to say that documenting your to-do list and keeping stuff crossed off actually means you don't miss stuff, because there's a number of times somebody's asking me, how's this going? I forgot about it. Yeah, yeah, because my list is, you know, ever long, right? It's— and I think the other thing that that serves to do as well is kind of documenting that sort of thing is, again, coming back to that piece about when you're trying to get buy-in for projects is What are you, you know, what have you been, what have you achieved? It's like, well, actually, if you break down all, you look at all the different things I'm being asked to do, loads. Like, look at this list, it's massive. But then if they, if the feedback is, well, you know, what's, what's good about these things? You should have a pretty, you probably should have a compelling answer to that.

Yeah. Right. Like, why did, why does this even matter in the first place?

Yeah. You need to be able to sell why, why things are worth doing.

Is there a return of investment of all that work? It's not just a simple, yeah, I'm going to have a chat.

And again, it comes back to value isn't just the money you realize from that thing. And one of the, you know, one of the probably most powerful examples of that is building towards that kind of accelerate automatic deployment. You know, again, those four kind of key metrics. That's a really hard mindset to get into for a developer sometimes because some developers only see, they only determine value. They only interpret value as the customer is using it, the whole product, the whole feature, but actually every step you take towards delivering that feature that's on production. That's why I love feature switching. All the projects I've built at Cufflink are feature switched. So they're there on production, you know, ready to be used until we turn it on for everyone. And so we can go in and test it knowing how to find it, and we can find bugs before they Yeah, we don't need the investors to tell us that, which is quite—

which is good.

Yeah, it's nice because, you know, because you have so many different paths for people to tell you problems, it's not a nice feeling when somebody surprises you with a bug, right? And so if it comes, oh, you know, this investor who's put this much money into the platform and said this is broken.

Yeah, and they opened it probably like for the first time or second, just to see how the business is going.

Yeah, it doesn't feel good when that happens, right? It doesn't, you know, it's not a nice feeling to have somebody else point out kind of shortcomings to you on a technical level. So it's nice to be able to put it in a position where you can look at it knowing it doesn't break production, knowing it doesn't introduce any unforeseen complications, and if there are there, you can fix them before they actually become visible to other people. But that's a mindset change, you know, the definition of value is some, for some people is, it's there, the whole thing's there for people to use. They're used to delivering you know, like, for one, lack of a better expression, like one Jira ticket for an entire epic. It's like, just do the thing. So, okay, it's not necessarily, you know, there's value added in that, but the, the stuff you lose in the, in the space is, you know, I get it, hard to estimate. Yep.

Okay, so Rob, one thing, and that's in the spirit of the show, we ask every guest, okay, um, what is one, and you can only choose one, okay, factor which is the most important for any tech venture growth?

Probably won't be a surprise given the conversation we've just had. Communication. Okay.

I love that.

Dialogue. Right? Because again, if dialogue happens constructively before a project is started, you get most of the work done before you even start writing a single piece of code, before you even create branches for it. You've narrowed down where you're actually— the direction you're traveling in, because details matter. And they matter even more when the later in the game you get, the more they matter. So if you can come up with a good first draft that people can pick holes in before you start moving, that's better than just a ticket that says do the thing. And that's from a conceptual point of view, that's what, you know, trying to ship a feature as quick as possible quick and dirty deployment, that is essentially just a ticket that says do the work.

Is it any communication, or is this, um, you know, well-positioned communication? Is communication would drive actions, or is it just more about here's why we're building this and just communicating that goalpost?

If we, if we try to narrow down a little bit on what type of communication, I, I don't know that there is a a good or bad kind. I think—

It's just talking about—

Yeah, and I think that, you know, I guess maybe more importantly to enable that is a culture where you can have that dialogue, right? So maybe culture matters on reflection, maybe culture matters more, right? Because if you can't, if you don't have an environment where you can push back on, you know, oh, I'm just asking for this simple, It's like, no, you're actually asking for something simply. It's not the same thing. You're using simple words, but that doesn't make what you're asking for simple. Being able to push back on, you know, to engage in conflict. Yeah, conflict. The ability to constructively conflict. When I interviewed, you know, more frequently, I had a question about conflict in every interview.

And what was that question?

The question was, how do you engage in conflict?

And if people put my gloves on and—

yeah, exactly.

Yeah, I just get it.

If people said— because this is the actual answer I was listening for— yeah, if people said, I don't, I avoid it, I didn't want to hire them because you can't have people who avoid it. You need people who just understand that it's necessary, but you have to go about it in the right way.

That's one of, one of the ways in the Five Dysfunctions of a Team book.

Exactly.

It's a healthy conflict. Yeah. And hashing things out.

Yeah.

In a positive way. Is what actually leads to alignment and decision-making.

Yeah, because otherwise, if you can't push, if you can't kind of negotiate that terrain, you don't— you just don't— you don't address those things, you don't answer those questions, because you just— you hide it all in the mist.

Which means you leave space in people's heads to fill that with whatever perceptions they have.

Absolutely. And depending on, you know, with the nature of the business, and I think pure tech has this less than other industries. And you know, so to give some context, Cufflink is a finance company with a tech arm, right? But it's still, you know, if you have a business that's still driven by product or driven by marketing, the limit is imagination. If you have a business that's driven by tech, yeah, imagination factors in, but actually there is a kind of sobering element to that where you say, actually, this is what we can realize of that imagination with the tech we have. And in order to get to the, to the imagination you want, this is the tech we need. My goal with Cufflink, and I've made quite a lot of progress in this so far, I think, is shifting tech left in that kind of decision-making process, getting tech involved earlier and earlier in the mix so that we're not building things in our heads before tech gets involved and says, It's not that you can't have that, it's just you can't have that fast, because we can't build that fast, because it's really complicated and there's these moving parts and this, you know, the way the data is structured means it can't be done that way, or we have to extend this, or we have to build this new service, or, you know, we don't have the architecture to do it under the hood. All these myriad of things that could be a factor in why things can't be done quickly. You don't think about those when you're planning with a kind of blue sky hat on. You need somebody, and this is one of those things I've always kind of been okay to be, is kind of the difficult one in the room who says, nah.

Sobering element, isn't it? Yeah. Let me take you back from these clouds to reality.

Exactly. Yeah. You know, meanwhile, in the world we have, you know, the goalposts are really important, right? Where you want to get to absolutely is crucial in defining your journey, because how do you propose to win the league if you don't know where the goalposts are, right? You don't know where you're going to score. You don't know what, what constitutes, you know, you know, to use the sports analogy, if you don't know where the goalposts are, you can kick it around all day, but you don't know if you're doing anything useful. You don't know if you're actually doing anything valuable.

It's a very nice analogy.

Yeah. And you know, the other thing as well is, I can't remember where I picked up this analogy from, it wasn't one of mine. You always want to build a team that wins the league, not the match, because when you try and win the match, you take short-term you know, tactical decisions that might not bear fruit in the long run. So you put your, you know, you're winning 4-0, you leave your striker on because he scored 2, but actually you need them in midweek because you've got European football to play. So actually you take them off before they score 3, even though it's annoying for them to not score 3, because one, they'll be paid a little bit more for a bonus for a goal. Never quite something I've understood, because, you know, if you're a striker, that's your job, innit?

Yeah, exactly.

Not to sound too Roy Keane about it, but that's kind of—

but that's how it feels. Works as well, isn't it?

Well, yeah, exactly, right? So, you know, if you take tactical decisions constantly to try and solve short-term problems, you put yourself at risk for the longer term, to be able to deliver your longer-term vision. So the goalposts at the, you know, the destination absolutely matters, but you need to understand on that journey, on that roadmap, where you are. So, you know, you want your fully deployable automated DevOps-heavy, Terraform-based, spin-it-up-in-a-box version of the future, the AWS training workshop. What you have now is not that, right? But how far are you off that? You won't know until you actually go through the pain of finding out. And then you start to say, okay, well, step— what's step one? How do we actually start on that journey? How do we go towards that goal? Now that we know where the top of the mountain is and where we are on that, on the map, how do we get there? Right? It wouldn't have been much use for me to try and drive to you today without knowing where it was based, without knowing the postcode.

Yeah.

I'm just going to drive around all day and then I couldn't find him.

Yeah.

I've been driving all day.

It's such a simple concept though. And people still get it wrong.

I think it's just because, you know, it's hard. Again, it's a simple concept, but it doesn't make it simple to action. Yeah. Right. It makes sense and it's logical and everybody can get behind it. From a conceptual point of view, but actually to deliver that is a lot of moving parts. Yeah, it relies on everybody being ideologically aligned. It relies on everybody moving in the same direction and playing for the same kind of ideological team, even if they're, you know, you should always have everybody in the team moving towards the, the same goal for the business, which is continued growth and success. But you need everybody to kind of be aligned on what that looks like, what the definition of that is, you know, because if it's for Cufflink, if it's growing the loan book to X, it's like, okay, well, we all need to know that our goal is that as a high level so that we can all do our part to make sure that can be done. Because otherwise, if we're all thinking, oh, well, actually my goal is, forget that, forget that loan book figure. I'm interested in, I don't know, I want the DevOps to be rock solid. It's like, that's great. But unless it's serving that goal, it's not a good direction to take your energy in.

Okay.

Because, yeah.

So, um, are you sometimes in situations where the goalpost is in an area than an actual goalpost? Or is it more of, this is, this is just bad definition of a goalpost? Sometimes I feel like, you know, you basically go like, the goalpost is somewhere in the vicinity of these, of this circle, but we will know the goalpost once we come much, much closer and we'll start doing some discovery, some failure elements. Yeah. Or is that actually a lack of, a lack of real setting skills of a goalpost when it comes from leadership? Or is it that, you know, reality of not really knowing the goalposts but aiming somewhere around it?

I think this is a really unsatisfying answer in the first sentence, but stick with me. I think it can be a bit of both. And so to use the kind of the geographical analogy, if you know that your goal is in a particular city, right? Okay, you don't know the exact address, you don't have— for the sake of example, let's take, you know, you're mapping the terrain out in real time, so let's take sat navs and, you know, car directions out of the equation. You're just an explorer trying, and you know roughly that where you're going is, it's in the northerly direction, and you know which city it's in. You'll know it when you see it, but until then, you're going to be kind of heading in that direction, we're in a more advantageous space, I would say, because some of the terrain is already mapped out. Because a lot of the time, unless you're doing something fundamentally greenfield and completely innovative, this path has been trodden by somebody at some point. So you can use that kind of, okay, well, we should know after, you know, it's why sprints are so popular, right? Why Scrum kind of and Kanban and stuff deals with that in those kind of timeframes is because it gives you a kind of ready-made pocket of time to say, Okay, it's been this long, 2 weeks, 3 weeks, 4 weeks. Does this look like we're in the right direction? And this is what we've built. Does this kind of look like what you're expecting? And at the early stages, you'd expect that to be the answer more often to be no. It's like, oh no, not quite. Actually, I was expecting it to work this way. Okay, fine. We can correct that before we get to the end. The worst thing you can do, excuse me, The worst thing you can do is spend 2 years on a project and at the end of it go, what do you think? And they go, it's terrible.

Yeah, no one using it.

Yeah, I don't want to use that. And actually I'm so, you know, I'm offended you even presented it to me. It's like, that's the worst outcome possible, right? And it's avoidable, which is doubly frustrating because that's why you have ready-made kind of checkpoints to say, This is what we've got. This is our progress so far. How does that look? Does that look like what you're kind of along the right lines? Is there anything you want to change? Is there anything that actually, now you've seen it, it is what you wanted, but now you've realized you didn't want that? It's okay. Like, it's, it's, it's quite natural to, to build something because somebody says, I want it to look like this, build it, deliver a proof of concept, and they say, actually, that's not what I wanted, but I didn't realize it until I saw it. So I actually want it to be more like this. It's a lot easier to steer it when you've got kind of something to compare against. It's why first draft is so powerful because, you know, I've got a handful of, you know, fiction ideas in my head, but they're too nebulous and really ill-defined because none of them are captured. And if I started capturing them as I go along, you know, some of them I'll go, this is cool. Yeah, this is good. I should keep with this. And some of them, this is crap. And chuck it away. It's okay, you know, because you, you need to realize a certain, a certain amount of it before you can really kind of evaluate whether you're on the right track or whether it's what you want to do. I think that, you know, to your question, is it a sort of lack of definition? It can be for sure. I think that, you know, if you've got— again, you're a sports team, it probably helps to know what sport you're playing to understand what the goalposts look like, because a basketball team isn't going to get much luck in a hockey, hockey stadium. Because they're not equipped for that environment. For one thing, they're going to slip all over the place, and for another thing, there's no basket. They're going to miss every time because they're shooting over the goal.

It's good. Yeah, I love that.

It's, you know, sometimes it can be a lack of requirements, sometimes it can be that, yeah, you do need to make a certain amount of progress towards the goal, especially if it's big, before you'll know if you're on the right track. And you will get close, you know, as you get closer and closer to the end, you should expect, this is kind of the overarching philosophy and what I'm trying to kind of build in my role. I want the discussions around what needs to change to become increasingly trivial as you get closer to the end. So the big, you know, significant shifts in functionality and look and feel in kind of overall working are decided earlier. And at the end, it's about do we make that button red or yellow? Okay. Because those are simple things to ask for and simple things to change. The ones at the beginning are the simple things to ask for, but the hard things to change. So you always want that process to be all the hard stuff figured out at the beginning. And as you get closer to the end, it becomes increasingly trivial, the decisions you're making.

It's a great philosophy.

I will let you know if I have a crack at it.

Yeah. We will check with you in a year or so.

All right.

Good to know. So that's lovely, Rob. A last one before we, we all split. Do you have anyone in your network which you personally know, maybe your mentor, who would you, you know, recommend for the show?

Oh, I know just the guy. So his name's Alex. Uh, he is a— he works in recruitment in the financial sector by day, and in his off time, he is a professional wrestling promotion manager.

Professional wrestling promotion manager.

So I commentate for him in my spare time, but he runs the show. He would be— I've seen his kind of thought process expressed on podcasts. You'd love him. Okay, we'll try to take growth, you know, maybe he'll have— I definitely have some thoughts on it. Okay, um, so I think, you know, you should definitely at least have a chat to him, even if he— even if it doesn't make it to air.

All right, we'll try to get him on the show soon. Alright, so that was lovely, Rob. So much information, so much— I want to say correct views because I resonate with them. Well, we don't know, you know, people listening might have different views, which always invites conversation, which is great.

Yeah.

Thanks for coming. Hopefully you enjoyed it.

Yeah, no, absolutely. Thank you for having me. It's been, it's been really nice to chat. Cheers, Rob. Cheers.