At our recent Leadership Lessons AMA, Daniel Amber, CTO at Cars.co.za, shared how he went from video editing to leading an engineering team.
He didn’t sugarcoat the tough moments. For example, he shared how letting a front-end developer try their hand at back-end work ended up stalling the whole project pipeline. In the session, he also talks about whether he’d recommend an MBA to other engineering leaders, since he completed one before becoming CTO.
Here are the parts worth keeping, in his own words, lightly edited for clarity.
Watch the full session on demand.
Moving from engineering into leadership, what mindset shift was hardest?
I've spent years building up my leadership journey, and it took me towards the end of that journey to figure out that one of the hardest parts is you're no longer part of the team. You're managing or leading a team, and you kind of have to separate yourself from being part of the boys to being in charge of them. I needed to figure out where I wanted to be, emotionally step outside, and challenge myself to talk to people in ways I wasn't really comfortable talking to them.
Talking to the team more was step number one. Just actually understanding where everybody was and how they like to be spoken to, speaking to them very frequently, seeing what their interests were and where they wanted to go. Then when you talk to them and there are issues, it doesn't feel like you're criticising them. You're trying to assist them where they want to grow. That's the hard part. Being critical of somebody else feels like, oh man, this person is going to have a bad day, they're not going to have any output, I'm not going to have a developer that's happy, no one's going to win. But in actual fact, once you repeat that process often enough and in the right way, you get the opposite reaction. If you want someone to tell you where you can grow, and they actually have an influence on your career, that's a worthwhile person to listen to.
Many engineers hesitate to step into leadership because they fear losing technical credibility. How did you handle that?
That's a real concern, and it's still a concern for me. You do have to take a step back technically. You're not hands on, you're not the person who gets to execute all the time. You have to have a bird's eye view of every system, including the cost involved. Your technical edge has to differ, and it has to come more from a business sense. Your technical expertise does grow, but it grows in a different area.
The problem is that you go into development because you like to code. What I do personally is scope out time after hours or on the weekends for my own projects, and just remember why I love doing what I love doing. It's very unnatural for me to have hard conversations with people day in and day out, so it's nice to fall back on knowing I can still program something that works.
Can you share a moment in your leadership journey where something didn't go as planned?
The biggest blunder I made recently involved a front end developer who is very keen to move into the back end space. I thought, let me try make this person happy, I'll give them a task that involves some back end and some front end. That task didn't go as planned. It took much longer than it should have, and I didn't communicate what my intentions were with stakeholders. So the whole project pipeline took longer, and I was met with, well, why did you do that without saying anything to anybody? Which was true.
I put the developer in a bad position, because it was unfair on him not to at least ramp him up before starting that process. It didn't look good on me, it didn't look good on the developer, and it didn't look good on the people managing projects at the time. It seemed like such a small thing at the time, but any delay in anything has an impact.
What I learned is to be prepared and to communicate, communicate, communicate. Also, understand where people are at. Sink or swim can work, but it can also fail, and where I thought it would be okay, it just wasn't.
Was there a point where you felt out of your depth, and what helped you move through it?
To be honest, I'm experiencing imposter syndrome right now, being interviewed like this. But when I felt completely out of my depth was when I had to start taking control of people and their careers, and moving away from my safe space, which was programming and being very successful on the development side. Then you figure out there's a whole people element to a team. Sometimes everything seems black and white: there's this ticket, you do this, take it to the end, and then it's finished. But people's personal lives come in. I still sometimes feel imposter syndrome trying to communicate things to people, telling them how to improve their own situation, how to better their career at Cars or outside of Cars when they leave the company. It's just challenging.
What I do is try to solve the direct problem at the exact time. In that example, the first thing I did was open up communication pipelines: figure out how I could communicate more frequently with the people it affected, exactly what I needed to keep people on board with, and double check I was communicating in the right way with them. It's fairly verbose communication, fairly involved and very frequent, but it actually makes you move a lot faster than not having it. Figure out the point of failure and then resolve it as soon as possible.
What milestone or decision taught you the most as a leader?
The decision I consciously made to give people adequately more responsibility in the team and take it away from myself, where the responsibility matched their skill set and pushed it just a little bit further. I was talking to a dev yesterday, and I said I would love more than anything to do the piece of work he's working on because it's so good. But the responsibility is now completely on him. All I'll do is review it. I'll take ownership if it doesn't work, and if it does work, he's the one who created the solution.
A small thing that came up recently, which I didn't realise had such an impact on my team, was letting everybody else run the stand-ups week on week. I used to just run them myself. By doing that, everybody else felt more involved, and they also felt like they were getting leadership responsibility for work that they didn't actually have before, instead of the "I'm just telling you what to do" mindset. There was a quote from the course I did, which I'm sure comes from somebody else: leadership is all about you and never about you. That's exactly what it is.
What do you look for in a developer who's ready to level up, especially on AI-driven teams?
The first thing is to get rid of the stigma around using AI. Don't let people feel like they're going to be replaced with AI, or that your team is going to try get rid of people by leveraging AI. Just make people feel comfortable using it and embrace the usage of it. At the end of last year pretty much everyone was on VS Code, and I said, guys, we're all going to just start using Cursor, that's the standard. Because Cursor was built on top of VS Code, it looks the same and you can use the same plugins. That's step number one.
Very recently I've pushed the idea of urgency and critical thinking. Are we building the right thing before we even start building it? I'm pushing the idea in the team that syntax is a given. It's going to be correct now, and you have to know what correct syntax looks like. Now you have to understand whether that code is meant to be there, and whether that solution is for a problem that's meant to be solved. The level of thinking just changes. I've also got a session with my team next week on AI and how I've been using it, just to further the idea that you shouldn't be ashamed of how much you use it.
How do you build a culture where people learn from their mistakes instead of hiding from them?
I'm proud of Cars as a company here, because I've made very big mistakes during my career at the business, and it was because of the responsibility that was given to me. Every time I've made a mistake, no matter the size, it's never actually been held against me, and I do the same for my team.
I'd rather set you up and give you some responsibility. It's my job to give you the adequate amount of responsibility and make sure that I'm not setting you up for failure. Then if there is an issue that arises, you can come to me, and there's no disciplinary or anything. There's going to be no problem, unless it was intentional, which it's never going to be. We can look at it together, look at ways we could have mitigated the problem, or look at how we could solve this problem going forward, and use it as an ideation session to improve the pace of the team and the quality of the code the team produces.
What are the biggest signs that decision-making, not execution, is the real bottleneck?
When decisions change frequently. You get a brief for something, and you notice this won't work because of X, Y and Z, so you take it back, and then there's another problem, and you take it back again. Before it even hits dev, you can find problems in the decision flow.
The other issue is when it does hit dev, and there are multiple decision makers who then have to talk amongst each other, but you've already built something. Problems can happen when you've branched off production and production starts to run ahead of that branch, which is a major feature, and now you're starting to struggle because stakeholders themselves can't decide amongst each other. As soon as something starts to linger off the production branch, you can tell this has been a problem up the chain.
In general, it's better to have one person who is in charge of everything and can make the call on anything, and that person needs to trust somebody else with decisions when they're not available, and then be okay with decisions made outside of the fact. It's a communication issue, and it can also sometimes be a data issue, where the people who are making decisions don't have the correct data.
AI means teams can produce more than before. How do you stop that turning into noise?
The fact of the matter is you can produce more than before. You can actually increase your output. The trick is getting that output to a consistent quality and making sure that you're not just spitting out features. You can very easily get into a place where you're just spitting out features, and you actually worsen your product. Our platform can now do X, Y and Z, where it doesn't even need to do it at all. In a sense, you're slowing down, because instead of working on something that's different, you're overloaded with small improvements that nobody is using.
That's also a communication aspect. We could spend two months making 100 features, or we could spend six months making a product that doesn't exist and that's hard to rebuild. What call do we make?
Questions from the audience
What qualities do you look for in developers who want to get promoted, and eventually become a CTO?
Primarily, the ability to take responsibility, and somebody who has urgency in solving matters. If there's an issue, I'd love it if that person can look at that issue, take ownership of it, work on it and get it out as soon as possible. That's step number one: their own autonomy, their own reliability.
Second to that, somebody who is kind and talks to people in a nice way is also really important, because you need somebody who is easy to deal with in situations where the context might not be that good. You don't want to tiptoe around issues. You want to be able to have open and honest conversations and for people not to take offence. Those are the main qualities, taking it as a given that the skill set is there.
How do you keep up with new tech as a CTO?
When it comes to the infrastructure at Cars specifically, I try not to change it too often, but it always has to be up to date with the latest version, and you keep constant pulse checks on that to make sure versions are aligned and the platform is up to date.
When it comes to me, what I've started doing is exploring how AI would build something, given a problem, and using AI to compare different tools. I don't have the time I used to have where I could play around with everything. Take a search database. I can't play around with Meilisearch, Elasticsearch and Solr. There's literally no way I could spin everything up, see what it feels like to use and then play around with the APIs. But I can get a comparison table of all of them, figure out what requirements I want very quickly, and then start playing around with one or two technologies. If they work out in my personal capacity, I could start leveraging them in the business if it makes sense.