Haystack: Tech Uncovered. Episode 1 - Jaz Chana: From Startup to Scaleup

‍

‍

Mike Davies: I'm Mike, the co-founder of Haystack. 

Welcome to episode one of the Haystack: Tech Uncovered podcast where I’ll be talking to tech leaders, disruptors, academics and innovators about all things technology, software development and culture.

Today I'll be speaking with Jaz Chana. Jaz is the Technology Director at UK-based tech unicorn, cinch.

In this episode, we cover a whole host of topics from the realities of building a tech startup, scaling an engineering team, delivering a product that customers actually want to use, and much more.

Yeah, so Jaz you’re the Technical Director at the automotive unicorn cinch, which we've all seen the cinch logo scattered around everywhere. It's on the sleeves of the spurs shirts, front and center on the England cricket team. And I actually think I saw it behind David Guetta, at his Creamfields set the other day - which was quite interesting. 

So clearly super established business and I’d imagine a very, very different experience to being a tech lead, at a startup or a scaleup organization. So what role do you actually play at cinch and how has it changed and matured over time?

‍

Jaz Chana: Yeah so, officially my title is Technology Director.

I've been with the business for two and a half years now. So I was with the business when it was just a couple of people in a room. And now we're around 170, 180 just in the product engineering. And I manage engineering, architecture IT and information security - so all of those come within my remit.

So, you know, all of the funky new things and the ambitious ideas of the product people have got, and the rest of the business usually come to me. And me and my team have to figure out how we built on those things, right, how we deliver that. So, yeah pretty interesting role. Pretty interesting journey! It’s been a rollercoaster.

‍

Mike Davies: We have a saying internally that basically, perfection is often the enemy of great. People are perfectionists. They try and look too far ahead into the future and plan for every eventuality. When in reality, you know, we probably not gonna have the influx of users that you expect. I think one of the hardest challenges for me personally was because I'd built up so much hype from friends and family, you know, like “Mikes off to start a business! He’s building an app - building a product”

And then when you finally go out and, and ship it, you want everything to be perfect and you want to solve everybody's problem. But it's almost having the bravery to just go out there and put something out there and see how people respond.

‍

Jaz Chana: I think the key is, you're not going to solve every single problem for the consumer from day one. And the point of it is, is to go out and try something. So you can go through that build regimens cycle. So really what you're trying to do is build the capability as opposed to the product, if that makes sense.

So for organizations who are just starting out, I would always say to them, build with the intention that what you start with, isn't going to be what you have six months time.  Build with the intention that you're gonna end up throwing it away and starting again. And that's perfectly fine.

One of the key strengths that a startup has is its ability to be able to pivot, right? And the ability to shift based on what it finds, based on what it learns about the market, the consumers, et cetera, et cetera. A simple example - YouTube was actually a video dating site, right? And, um, that business completely bombed.

But MySpace found their video processing technology really, really interesting, and they wanted to use that for themselves. And so then they asked YouTube if they could use their technology for their sites. And that became extremely successful in that ended up turning into the YouTube that we know today.

There’s loads of examples of that, where an organization, a startup has had to pivot, but really it shouldn't be seen as a failure. It should be a strength and it should be embraced. And really it's the biggest strength of an organization where a startup has over a larger organization that might have a lot more resources and a lot more money.

‍

Mike Davies: So how do you, at cinch, maintain that innovative edge that for example, small up-and-coming competitors might have over you in terms of being nimble on the feet. So that a lot of the things that you've just mentioned there, um, how can you kind of maintain that startup mentality? 

‍

Jaz Chana: A lot of it comes down to trying to, again, focus on outputs. You don't hire smart people and then tell them what to do, right?

You want to be able to give them a specific sort of problem to put them in a domain and set up a particular outcome. You want to ensure that they have everything they need to achieve that particular outcome, most of all, have the autonomy to be able to achieve that particular outcome. 

As soon as you start to dictate specific features or specific things. Well, you're not really getting the most out of that team. Nobody really wants to work like that either. And like I said, I have no interest in dictating to engineers what they should and shouldn't build, they're not there to do that. They're there to present their ideas, there to innovate, there to push, push that barrier, push the envelope.

So it comes down to funding, the right sorts of people building an autonomous cross-functional team, setting the right outcomes. Now there are always constraints and you need to have those and that's fine, but you set those constraints within that particular domain. 

I've seen some pretty amazing things happen. I've seen people in our teams do some pretty amazing things and solve some very difficult problems. I mean, the other thing I would say as well is, you know, not to be sort of satisfied with where you are, always have that curiosity, you always have that hunger, always want to sort of push the ball.

I think it's really important not to see your success and think, “Okay. Right. We're done.” And just being satisfied with that and just not want to drive. You've got to have that hunger and you can't be afraid to make mistakes as well. I think the final point around building that or pushing the envelope in terms of innovation is to try and create a fear-free environment, an environment of use over an overloaded term now, psychological safety.

I guess what I mean by that is I've seen so many teams who have all of those things I've just described but will fail because they're afraid to fail. Because failure will mean they'll completely take out or wipe out the business for a day and lose millions or, you know, they'll get shouted out or, lose their jobs or whatever.

And so they'll end up in some kind of paralysis. You know, we work really hard at cinch to ensure that people have the right level of psychological safety and are allowed to take risks where appropriate of course, in the right way, and allowed to fail and learn from that failure and build them and that creates a certain amount of innovation.

It comes with a certain amount of waste. You can't innovate without going through that process and creating waste. That's fine. That's not a problem. It's about going through that quickly. 

‍

Mike Davies: That's kind of a, a typical stereotype, I guess that comes part and partial with being a large dominant tech company. I'm not sure if you've read it, but it's portrayed quite nicely in the Phoenix project - I don’t know if you’ve read that before. It's kind of the slow moving behemoth that struggles to deliver tech requirements on budget on time and constantly bumping heads with other stakeholders in the business.

So what does your ideation to actual feature rollout process look like? And how do you mitigate those engineering bottlenecks? That's often mentioned in the Phoenix project, for example.

‍

Jaz Chana: If you talk about engineering bottlenecks to engineers or people in the industry. Everyone's like, oh yeah, we know where the bottlenecks are and it's usually never in writing code, or it's never usually about how long it takes to code a solution. When you talk to people externally, they have a very, very different view. It's always our engineers, they over complicate everything. They take ages to do anything. 

I went to this tech talk once and I think this really beautifully explained it to me. And for the first time, and this was before the Phoenix project really laid out where the problem was. And what is this senior engineer for this particular project what he did was he took the code base that his project that they'd been running for, I think it was two years. He took all of the code for everything they built over this two-year period.

And he counted the lines of code and he worked out the average amount of lines of code a developer could write in a day and a half there. And he worked out how many developers it would have taken over what period of time to write all that code from start to finish. And it worked out at something like 3 months it would have taken to build this piece of code from start to finish that they ended up delivering in two years. 

So his thinking, well, where was the rest of the time spent? So yeah, and really when it comes down to is, indecision, rework, analysis process, it's not making the sort of the, any kind of decision and, not being clear on what you're trying to do. 

And for me, I think when you read accelerate, that's a great example of where the majority of waste comes in. One of the key metrics is around failures post-deployment.

And if I was to extend that analogy, look at the amount of rework or the amount of time that's spent, reworking things that go out, you know, I would say that's where the majority of the waste comes into that process. And so there's a subtle distinction between putting something out with a hypothesis to try and learn something, or prove or disprove something or, and putting something out that does neither of those things, it was just completely misguided from the beginning.

Right. And having to sort of bring it back and rework. There's an important distinction between the two. One of them is you're moving forward. You're learning more about doing what you need to do. The other one is, well, you're not making any progress whatsoever. We're just sort of blindly putting stuff out.

And that's where the waste in the process comes from. So what we tend to do a lot of is user research aligned based quantitative and qualitative. And we use a lot of data that we collect from various bits of analytics across that customer journey. We tie that back to various different metrics that we measure that are important to us - that I can’t really go into detail about.

That forms the basis of our outcomes, the OKR, which we want to achieve for that particular period, for that quarter, et cetera, et cetera, these are then filtered down to the individual tribes and squads who will then come up with their ideas or hypothesis about what they can achieve.

We'll work with the rest of the business, quite closely to understand well, how does that marry with what we've got to achieve with the rest of the businesses as a whole and the business objectives across the board, and that kind of translates into loosely a roadmap that it's then implemented.

I make it sound like such a long-winded kind of process but it's really not, it's really not like that. There's so much more collaboration. I make it sound like a sequential process but it’s a bit more collaborative than that.