Reflecting on the past year @ Volvo Cars

Jul 03, 2023

I’ve been working at Volvo Cars Stockholm Tech Hub as an Engineering Manager for the past year now. Volvo Cars (& the rest of the automobile industry) is going through an unprecedented ecosystem transformation - driven primarily, in my view, by changing consumer behaviours, new energy policies, climate change and shifting geo-political landscapes. These conditions have led Volvo Cars to realise that if done right, software can be both a competitive differentiator and an advantage.

Thank you for reading Musings on Software. This post is public so feel free to share it.

Like a conventional large enterprise, Volvo Cars had outsourced most of its software development to software vendors. Once software went from being a 'cost' to a strategic driver, something that can affect the top line, Volvo Cars decided to in-source all software development and be a software led company. This effectively meant disrupting businesses, processes & practices that have evolved over the past century and figuring out what a software driven world looks like for Volvo Cars.

I've lead teams before, in both managerial & non-managerial roles, but I've never led a team through a change of this magnitude. This is why I joined Volvo Cars. To lead through ambiguity and change and hopefully leave a dent (yes, that is a DHH reference) in the transformed automobile industry. This is what drives me and makes me excited to go to work everyday. It has it’s challenges, but that’s what makes it fun.

Below, I share some of my reflections. None of these reflections are revelations as such, but due to the scale of Volvo Cars, I have come to appreciate these points even more -

Greenfield Development in a Brownfield Environment

Taking on greenfield development in a greenfield environment is very different from taking it on in a brownfield environment. In the former, there are no constraints - technical or otherwise. In the latter, there are plenty of constraints. It is extremely easy to focus on greenfield development ignoring the reality of environment in which you operate only to realise you have built the wrong thing. It is much better to take a step back and identify the hard constraints that need to be adhered to and what degrees of freedom you can afford before diving into a solution. What makes this harder (& fun) is that because the whole company is going through a transformation, the landscape in which you operate also keeps changing.

Speed vs Quality takes on a whole new dimension

With ‘Quality’, I refer to the quality of decision making. Building on top of the previous point, when you operate in a brownfield environment, there are only so many things that are known to you. The number of unknown unknowns is high - especially if you are new to the environment. A cheap way of getting feedback on a decision you have made in an environment not entirely familiar to you is to socialise that decision and get feedback on it. This is one of those instances where getting more eyes on the decision does increase the quality of the decision. However, it is very easy to get into consensus building mode and start seeking input from 4071 people before making a decision. Socialising your intent to make a decision with the right set of people and getting just enough validation to move ahead is as much an art as it is a science. How much speed are you willing to sacrifice to increase the quality of your decision making? Just how much input do you need on a decision before the loss of speed becomes unacceptable to you? These are things that you tinker around and find out. Having a certain amount of chutzpah, I have found, helps move things quicker.

New found respect for developer tooling

I worked at companies where software was the bread and butter. They put in investments in developer tooling to make lives of developers easier. It is because they understand the importance of developer experience. That dev time is best spent solving business problems, not fighting problems lower down the value chain. Not having such level of developer tooling made me realise how much I took for granted.

It is understandable that a company like Volvo Cars, whose bread and butter is automobiles hasn’t invested in developer tooling as much. It is also very impressive that the company leadership has managed to build feedback loops between themselves and the folks building software on the ground. I find it very reassuring (that the company is indeed moving towards being software led) that the leadership listened and has invested in creating a developer experience org to solve developer’s day to day problems.

Watching from the side lines on how our developer experience teams are studying development patterns, researching their users and the progress they are making towards improving the experience, I have a new found respect for anyone trying to improve the developer tooling. I’ll be the first to admit that I (& my ilk - the peeps developing the product and whining about the state of dev ex) have not made life easy for them.

Share Musings on Software

Platforms are hard

It is not uncommon for teams in Volvo Cars to build, maintain and operate software that serves anywhere between 1 to 89 markets, with multiple stakeholders in each market. Each of these teams, in turn, depends on other teams for some key capabilities. Teams depend on the infrastructure platform to run their workloads. It is not uncommon for five new teams to start up and want to onboard themselves to a platform that hasn’t yet figured out how to automate onboarding. Every team has their unique requirements, demands from platform teams. Almost every other team has to frequently make decisions when it builds something new -

Is this something the platform should build?
Is it on their roadmap?
Should we wait or build our own?

While this certainly complicates the life of product teams, I can’t imagine the kind of toll it takes on platform teams. To continuously deliver existing value with little to no slack to move things forward, I do not envy the people attempting to build platforms. Reaffirms two of my beliefs -

Platforms can never scale if they take the ‘service’ approach
Platforms could benefit from a dedicated person from the Product function

If you are on a platform team, I would love hear how you operate your team -

Room for significant efficiency gains

There are way too many layers between ‘people who write the software’ and ‘people who use the software’. Symptoms of a conventional enterprise that outsourced all of it’s development. With the push towards, forgive the cliché, “empowered autonomous teams”, more and more teams will be closer to the users using the software. This is bound to create faster feedback loops and reduce the need for as many layers between the product development org and the users of the product.

Consultants vs Product Engineers

Consulting firms that make their buck by outsourcing stuff to countries with a weak currency (I’m not going to name them, you probably know who I’m talking about) get a bad rep. I used to work for such consulting firms before I switched to doing engineering at product companies. I never understood why these consulting firms built up the reputation that they did. Now I do. Looking at all the stuff that was built, I couldn’t help but wonder if they did what was right for themselves and not what was right for the company.

Consulting 101 - go in, sell fluff, do account mining, create problems, throw more head count at the said problem, make more money.
Boutique Consulting 101 - go in, identify problem, solve problem, charge a bomb, get out, leave company picking up the pieces.
Product Engineering - understand the ecosystem, understand value being delivered now, understand what value needs to be delivered next, figure out how to get there as soon as possible, with as little cost as possible, keeping in mind existing constraints and not increasing the maintenance cost of software

There is a distinction to be made here between operating as a delivery team and operating as a product development team. Most consulting firms couldn’t give two hoots about product development - the incentives are not aligned. They are incentivised towards and are really good at delivery. There are times when this is exactly what your company needs, there are times when this is exactly what you don’t need. One of my biggest learnings at Volvo Cars is to understand when to bring in consultants and when not to. I’m grateful for that learning.

Governance is hard

Coming up with an engineering governance framework is a hard job as is. At Volvo Cars, this is compounded by the fact there are different teams comprised of engineers with diverse technical backgrounds working on different tech stacks that have different non functional requirements, yet, fall under the same org. What works for a team doing greenfield development and uses Kubernetes to run compute workloads will not work for a team that follows an Agile Release Train to deploy on Salesforce. Identifying what governance structures to apply higher up and how that structure should evolve as it makes its way down towards different teams is a problem we haven’t figured out yet.

If you have any inputs on engineering governance, I would love to hear from you -

Musings on Software