One of my guilty pleasures is watching car restoration TV shows. It’s not about the cars for me, but about the whole project: the transformation from a rusty barrel to an amazing vehicle. And the whole package is interesting: from the initial buy to mechanical engineering to aesthetics to usability and a final sale.
One of the shows is Wheeler Dealers. Yes, I know it’s scripted and things are not always what they look like (see for example here and here). But Mike Brewers was, and still is, a car trader with his own company. And Edd China is a technician with a university degree in engineering product design and still working on and inventing crazy vehicles. So they are both qualified to show the tricks of their trade.
In each show Mike selects an iconic car that he tries to buy cheap, and Edd does the repairing, taking the viewers along on how the repairs go or how some of the mechanics work. Where it is not possible to fix they find ways to cheaply refurbish parts or get an aftermarket replacement for parts. In the end Mike closes a deal on the car to make a profit.
So in each episode they show the story of rebuilding a car, and working on a team together on getting it done, each person good at their speciality. Mike is good at haggling and finding good deals, and Edd (and team) are good mechanics. They both have a clear vision on what the car needs (and what not) to make it the best restoration and get it sold.
This looks a lot like the cross functional teams I work with. Each individual has their speciality, maybe it analysis or research, software engineering or designing. Or maybe it testing. But they are all trades we need to tackle the stories or epics that we want to deliver for a profit.
And where Edd and Mike discuss on what is best for the car, our software team discusses what is the best solution to implement for the story. Where Edd pinpoints out bad mechanical solutions, we see software engineers removing technical debt causing bugs. While they both aim to keep the costs low, they know when to use an aftermarket part or refurbish a new part or sometimes even build an own part. We do the same by selecting existing components of a framework or choosing to build our own.
And where in the show it feels like natural team work, where of course Edd complains about the amount of work Mike picked up, I see this quite often missing in software teams. Often people stick to their trade, and teams don’t discuss the solution. They just do their part and hand it over to the next person (or worse, just move a Jira ticket and hope someone else picks it up).
Another similarity is where Edd and Mike do not know how much work it will be when they start. They notice issues on the car, but often do not know where the mechanical issue is. They have a rough idea, but don’t know it specifically. Just like teams do when they estimate a story. You don’t need to have a clear design, just know whether it is probably worthwhile or not. Maybe I will dedicate an other story on this for another car show: Flipping Bangers, where the estimation (and failure) is more common.
And while we are on the subject of vision and teamwork, it may also be good to mention how Edd left the show after some take overs and changes were made to the format that he couldn’t agree on. This is a real good example on how you should part with a team or employer when you differ so much on the vision you have. Don’t continue on a cause you do not believe in, you will start to feel miserable. And when you leave, I would say do it in his style as well: without grudge, looking forward towards new opportunities, and wish you successor the best of luck. Whether you were right or not doesn’t really matter, create your own future!
Photo by Dylan Collette on Unsplash