“No sacred cows” — making quick vs informed decisions in a fast environment explained by CTO Ben Brown of Flock

The CTO vs Status Quo series studies how CTOs challenge the current state of affairs at their company to push it toward a new height … or to save it from doom.

Prevention is the answer to crunch

Ben considers himself a “cross-functional” leader. He may play for team technology, but his knack for business management, coaching, and emotional intelligence make him a respected mediator with a down-to-earth character.

As a manager, he scaled engineering from 10 to over 100 employees at three companies. He proved his departments’ work had an unmistakable impact on user and revenue growth in the UK and beyond.

He worked under rigorous targets with a desire to remain a guide rather than a general. The experience forced him to figure out how to inspire decisions Boards approve of while keeping his teams shielded and engaged.

His approach:

• remind engineers they’re shaping an entire product, so each piece must be valuable,
• defend the team’s right to create a solution,
• inspire collaborators to think like responsible business owners.

Today, he’d like to share his story with you. 

TL:DR: better product decisions start with a culture that shares the same view of what users are willing to pay for. 

About Ben & Flock

Customer-centric engineering 

Eric Ignasik: Nice to talk to you, Ben. You joined Flock, an insurtech scale-up, 7 months ago after it raised an impressive $38 million in February 2023.

Previously, you worked as a technology leader for product-focused companies in EV, finance, or e-commerce markets. What did Flock do to win you over?

I used to work for an EV subscription company called Onto, which had its commercial fleet insurance through Flock. Both companies shared the vision of reducing risk for drivers and vehicle damage through technology.

Unfortunately, Onto hit some challenging times when the value of second-hand electric cars declined. Soon after, Flock happened to be looking for a new CTO, and I decided to join as I was very aligned with its purpose.

Flock is an insurtech that works with commercial fleets for courier or delivery services. We work a lot with Amazon logistics fleets.

Our mission is to make the world quantifiably safer by using telematics and vehicle data to uncover fleet insights that minimize accidents.

For example, the faster an insurance claim is made, the lower the cost of that claim. That’s something I didn’t know before jumping into the insurance world.

Flock does a lot of work to detect car accidents and get drivers to report them as soon as possible. Our customers can benefit from this by reducing annual insurance costs for the entire fleet — often the third biggest cost for fleet managers.

We work with them as a partner — not like an agent who turns up one day with a new insurance price.

Flock’s mission is to “make the world quantifiably safer”. It offers a fleet management platform that ranks vehicle safety as a key offering. For this reason, this service has to stay fault-proof.

Which development processes cannot be rushed or altered to keep a digital product competitive?

In the UK, there is a saying that goes: “No sacred cows”. In a start-up environment, there is always pressure to act quickly. Sometimes, we have to make tough decisions, so everything is up for discussion.

Still, there are a couple of places where people like to cut corners, which makes things difficult.

For instance, an urgent requirement comes in. What’s the quickest way to get that delivered? You assign it to the most experienced person because they can quickly grasp the code.

But if we do this every time, how will anyone else on the team ever learn to work with the requirements?

The right approach is to pair someone with a senior engineer so they get upskilled and can handle a similar request the next time.

I tend to hire team players. You need a great team of professionals who can deliver, not just superheroes who can jump in, save the day, and then jump out again.

The second thing worth examining is how you think about developing a product. There’s actually a book by a guy called Mike Kirsten titled “Project to Product” that deals with this.

The concept is that we’re going to continue to build our software over the years. How do we create this long-term, evolving product?

If you fall short here, you build a lot of disjointed blocks that never really fit together.

We know that investing in automated testing leads to higher quality products and faster, more sustainable delivery. Or that we can automatically scale our platforms by building robust CI/CD pipelines.

McKinsey reported customer satisfaction as a growth driver was a top priority for UK insurtech companies in 2023.

Does this mindset come from the organization’s culture or the competitive market? Or is it what a CTO and CPO can shape?

It is partly influenced by external pressures and partly by internal culture. But I would say internal culture makes it more likely to succeed.

Some of our teams are connected to customers on a minute-by-minute basis as people phone up or when we have “safety intervention calls’,” which we started doing 6-12 months ago. On those calls, our employee might say, “Hey, you’ve had three claims in the last three months, and they were because of this and that. You reported them in an average of 20 days. We can work together to get them reported in 24 hours.”.

In turn, this can help the customer have cheaper insurance next year. We have a lot of calls like that going on.

One of the challenges is then dealing with all this information coming in from our partners and exposing our teams to it. There are SaaS products that help collect such facts.

But we also have a townhall-style session every two weeks called “Flock o’Clock” with our actual customer, who is interviewed by our people during a live session. We find out why they love Flock and what can be improved.

Intuit, a company I used to work for, has customer focus in its DNA through a process called “Design for Delight” that’s embedded into the organization. It’s their true differentiator.

It lets people get closer to customers’ problems and learn to build features of value instead of those they think should be released.

“Design to Delight” is a rare example of a customer-centric methodology taught to each employee. Source: Intuit’s YouTube

Just a quick follow-up question about Flock’s town hall. How do the employees feel about it?

It leads to great conversations along the lines of “I didn’t realize that,” helping them grow their levels of empathy. As far as I’m aware, none of our staff are commercial fleet owners, so they can’t learn from the product themselves.

Dealing with market turbulence

So, what business or product decisions do you think put unnecessary pressure on the IT department? And why do such decisions happen?

At a startup, many situations tend to crop up quickly without much thought.

That’s because either a new supplier needs to be integrated, we need to work with this new company, or revenue has been difficult this quarter, and we have to readjust for Q2.

My role is not as a technology leader but as a cross-functional business leader. So I need to understand the business context behind these situations to figure out what’s crucial.

In my time at Onto, we started to expand from the UK into the US, Germany, and France according to a release plan.

As it often happens, there wasn’t enough time to deliver the full scope by launch. I had to ask our team: “How can we reduce the amount of the build we need? What features can we take out to hit that deadline?”.

You’re saying your role as a CTO is very much a commercial one?

Yeah, totally. I have a seat at the C-suite table, so I need to operate in a way that I’m taking responsibility and ownership of that seat — that’s my commercial mindset. 

You mentioned expanding operations internationally during your time at Onto. What market changes can put technology companies at risk of making rushed product decisions?

This hasn’t happened to us at Flock, but we work with commercial fleet insurance providers to sell their policies. When we have to bring on a new insurance provider really quickly, connecting to third-party services can be a challenge.

Another example of the unexpected that nobody at Onto predicted was the decline in the value of EV vehicles, which slowly drove us out of business. Unfortunately, we had to pivot very fast, scaling down operations, which resulted in us losing some of our valuable team members.

We refocused development efforts on building features with the greatest chance of supporting Onto — focusing on features that could help us understand or reduce operating costs.

And I’d like to focus on development prioritization a bit more. Could you present an ideal scenario for making an informed decision on a technology initiative — with all the best practices you’d recommend?

Such decisions tend to come out of a Sales or a Board call. What can often be difficult for some of my teams is if they feel they found out about a project too late. So, I bring some of my team along to such meetings.

There’s a strong need for over-communication regarding each big decision, which brings in emotions that affect the teams. Like a heightened sense of, I guess, awareness or excitement.

In such particular situations, I like to ask the “why” questions. Why do we want to do this? Why are we trying to achieve it? Is there a way to get the same outcomes differently?

Technologists and product people are problem solvers who respond to such questions with engagement. Saying, “Hey, here’s a solution that needs to be implemented,” frustrates them. I brainstorm with both teams whenever possible to better understand the context and potential solutions. It’s really just about having a transparent conversation.

Flock does customer check-ins with product overviews rather than irregular customer interviews. Source: Flock’s LinkedIn

Just a quick follow-up question about Flock’s town hall. How do the employees feel about it?

Understanding business v engineering

Ben, The Global CTO Survey has listed overcommitment as one of the top delivery challenges over the last three years. Is this because of wrong estimations, market changes, or careless deadlines?

As CTOs, we’re now being asked to deliver more. In the past, we asked for three more teams and the answer was to go off and hire them now. Now we hear there’s no money for it.

Over the last 18 months, the challenge for engineering has been to do more with less. Most CEOs are extremely, uh, entrepreneurial. They really want to push forward.

We’re in an environment where you no longer get rewarded for just adding a dozen more engineers. Far more funding rounds are determined by companies that can move towards profitability, not just because they’ve doubled in size.

All we can do is operate on the highest priority pieces. Get those done as quickly as possible, move on to the next step and keep working in that manner.

My way of tackling this, which isn’t always successful, is to ensure people start prioritizing requests as early as possible.

I think sometimes it’s my job to queue up requests and act as a translator for my teams to help them understand the order of things and relieve the pressure they feel so they don’t burn out.

Projects that are not based on a solid market analysis can also add to the pressure. At least since 2020, a growing number of technology companies have restricted access to features or rushed releases to boost profits. Like Twitter or Reddit, which introduced paid API access that users don’t want to pay for.

Why do product companies make decisions so disconnected from user needs?

There are a lot of tech unicorns out there that are probably not very profitable. Now they have to pump out revenue. I guess that in their desperation, the owners are wondering how they can monetize users.

I wonder if we’ll get more comfortable paying for software in the future. Over the last 15 or 20 years, most of us have become conditioned that the stuff we use online is free. It’s almost like the era of free software is slowly disappearing. But every digital product has to become a commercial product.

Yeah. The bill is in the post, so to speak. In 2023, vFunction surveyed 250 technology professionals and found that 76% of refactoring projects are considered a failure because of perceived “risk” or “no case for ROI.”. How do you get buy-in to deal with legacy technology?

I’ve been fairly lucky that Flock is young enough not to have the same legacy issues as a larger, 20-year-old organization might have.

I think Facebook once had to do a big rewrite, stopping feature development for a while because everything fell over. My aim is to never get into that situation.

We need to start dealing with the legacy continually. I am a big believer that we can’t ask to stop the roadmap for a while to redevelop something. It’s a non-commercial way of thinking.

My job is to keep working with the roadmap and avoid a standstill. We’ll be pretty successful if I can keep things moving forward and balance out technical debt with modern feature development.

At Flock, we’re aligned that technical improvements take 20 percent of the roadmap, while features take 80 percent, which we measure by story points for each sprint.

Nobody’s going to give you permission to set out time for refactoring. I had this conversation with my leadership team, and fortunately, they trusted my judgment that we needed it to operate well. But I didn’t ask for permission.

I expect the engineers to continue developing a better and better product. It’s not an opportunity to complain that nobody allows them to fix legacy issues. You need to take the time for these 20 percent and get on with it.

Practices that make teams resilient

You suggested that informed decisions come from continuous alignment. And you’re are an advocate of transparent communication. What was the hardest silo you had to break to make a successful product decision for the team or the company?

When I joined Onto, there was a distinct lack of trust between the company’s technology and product divisions.

In the past, the product team was asked to build something and then yelled at if the end result was even slightly off-scope. Misplaced appreciation was the basis for a combative relationship.

In the early days of most of my roles, I had to re-establish that level of trust. “The Five Dysfunctions of a Team” says that trust is the basic requirement for a high-performing team — that’s where you have to start.

In the early stages of a relationship, everyone wants the other person to say “I love you” first. It’s the same with trust. If you’re the first person to trust you, what happens if the other person breaks that trust? Am I then the fool in this relationship?

The manager should be the first person to show trust, or it’s very difficult to influence the other side. It’s to be hoped that colleagues will reciprocate the trust a little so that the situation improves for everyone involved.

But it’s also very difficult to lead teams because trust usually comes from the experience of sprints going well. Software development is complicated and can go wrong, which gives the other party the opportunity to say: “Hey, we can’t trust you.”. This brings us back to the crucial element of transparency.

The analogy to love is spot on. One of the other things we’ve learned about you is that you’ve suggested that the idea of a servant leader is close to your heart.

Could you explain how that works for efficiency in a fast-paced insurtech market?

Servant leadership came to light in the last 20 years as a new paradigm of leadership. It’s the opposite of what a traditional leader has been — the kind of hero, the savior, the person who does everything, one who commands and controls.

A servant leader is there to help the employee become better. Over the past few years, I’ve had these conversations with myself about my role as a technology leader. I figured my mission was to create an environment that enabled people to do the best work of their lives.

It’s not about doing all of the interesting work myself, or jumping in to save the day. It’s to make sure we have the right environment so that my teams can do that.

In my early years as a leader, I spent a lot of time learning coaching techniques to get people to reflect on things and recognize how to do them better.

When I was young, I enjoyed playing high-performance sports. I like the analogy that work teams are very much like sports teams. To do the right thing, members need to collaborate and set expectations for each other. They’re not really like families that you can’t really choose and kind of have to accept.

Servant leadership is similar to modern sports coaching, which isn’t just about telling people what to do. It’s about getting people to make the right decision in every situation.

Ron Jeffries, one of the founding fathers of Extreme Programming, believes a manager who asks for urgency lives in fear. What causes stakeholders to sound the alarm — and how can an organization overcome this behavior?

It might be that if we don’t act urgently, we won’t onboard this new customer, and maybe the startup might go bankrupt. Or if we don’t get the function out, we might not sign up the three enterprise customers we already had on the roadmap.

Urgency is never pleasant, but sometimes it’s unavoidable. I spend a lot of time managing the impact it has on my team to help them process the pressure, risk, and fear they’re experiencing.

You have to learn to handle sudden requests because they happen a lot in one’s career.

Good to remember

To sum it up, could you list three golden rules for other CTOs to help them navigate tough decisions?

Rule number one probably has to be to act as a cross-functional leader rather than a technology leader, because that’s the crux of where that sits.

I think rule number two is to ask questions to get context and gain empathy. Only then will you understand where somebody is coming from. 

And rule number three has to be that your job as a technologist is to support an organization rather than to be a request taker. Don’t just be the fly on the wall at a meeting that doesn’t say anything. You’re a commercial leader — you should have an opinion worth sharing.

Resources

You already referenced a couple of books throughout the interview. We learned you keep yourself educated and reference specific authors and their theories in interviews.

Any other learning material you’d like to recommend for its value?

So there’s a really interesting book called “The Culture Map” by Erin Mayer explaining how specific social groups might behave differently or mean something else around the same thing.

My wife is from Hong Kong, and the title enlightened me about some behaviors or thinking patterns that Asian cultures present.

Another book that’s worth a try is “Start With Why” by Simon Sinek. “Why” is my favorite question.And then perhaps another one for technology leaders, which some might already know of, is “Team Topologies.”. It influenced how I think about team design for engineering.

What’s next? Three actions for CTOs to take

Ben leans towards making informed decisions but knows sudden requests are unavoidable. 

But it seems he’s rather centered on preparing his teams to outperform in an environment we could define as Constant Change / Constant Improvement.

If you’d like to lead your engineers towards self-management (like Majid from Northfork did):

1. Involve key engineers in Board-led technology projects to shape that commercial mindset that will keep them focused on the roadmap,
2. Over-communicate Board announcements or strategic decisions as being uninformed demotivates engineers, which in turn hurts delivery progress,
3. Keep product and engineering connected to customers directly through Zoom calls or in-person meetings to help them make decisions user-centric decisions.

Note what Ben said servant leadership. Organizational change cannot be forced without the employees starting a resistance movement — but it can be inspired.