What Kind of Car Are You Driving?
February 10, 2024
Outside of Sedona, AZ, there is a famous hike called “The Devil’s Bridge.” It’s a bit of a scramble up a mountain to a narrow land bridge near the top. Behind the bridge is a vast landscape of Arizona desert and sandstone mountains around. It’s worth the trek if you are in the area.
To get to the trail, you have two options: go straight to the trailhead or take an additional trail, which adds a few miles to your route. Since the trail is a bit challenging, many trekkers naturally want to go straight to the trailhead.
The complication is that the road directly to the trailhead is, well… bumpy. By bumpy, I mean you need a proper 4x4 offroad vehicle to take it. You can rent Jeeps or other vehicles in town, but it ain’t cheap. Many decide to use their existing car and hike the extra miles vs. renting or taking a shuttle.
But effectively, an external factor influences how you get to the trail: the car you drive affects the route you take.
And while that is an obvious statement, it occurred to me recently how this plays into how we plan and build our software.
Planning: Mapping a Route to a Destination
Often, in software, we spend a lot of time planning. Depending on your teams’ preferences, this might be big plans upfront or short plans before every iteration. Regardless of the exact way your team creates plans, the point or goal of planning is centered around two core questions:
- Where are we trying to go?
- How do we get there?
The first question is about what you need to build. What features, extensions, bugfixes, etc., need to go into your product. What are your customers looking for? What is causing them heartburn? The idea of horizons and vision often play into this here, too. You might have a clear picture of where to go in the next month but a vague one for the following year.
The second question is often more tactical. How are we going to get there? Are we building new APIs or systems? Are we buying instead of building? Who is working on what?
This is where the rubber meets the road. You start mapping out the routes you need to take to get to that destination, considering factors like time, capacity, and importance of each feature or component. Again, this route might have varying degrees of clarity. If you are in Raleigh and want to drive to San Francisco, your first steps are “get on 40 and go west.” You don’t need to know the last ten turns of your route to start driving.
Highways, City Driving, and Dirt Roads
There is one catch, though, with the above analogy: not all roads are the same, and not all cars drive on all of them effectively.
For example, most cars do well on the highway. The best cars are the ones that can go quickly but also have enough fuel and fuel efficiency to avoid stopping too often.
But what about when you get into busy San Francisco? Do you want a massive Ford Expedition as you take twisty turns and tricky corners? Probably not. You’d like something smaller and more nimble.
On the flip side, what if your route runs into an obstacle, and you are forced down a long take a detour? Or perhaps I-40 is shut down near Flagstaff, but you can take a dirt road to get around it and meet up with the highway on the other side. If you had a Jeep or other off-road vehicle, you might take it. If you had a Porsche Cayman, you might pass (or accept if you like danger).
Our routes in software aren’t that different. Sometimes, we have a clear picture of what we need to build, and we just need to execute (a highway). There might be times when there are some complex migrations and edge cases to handle (city driving), and you want to grab the easy-to-navigate sedan. There might be other times you need to reinvent a service, or there may not exist a known path to build what you need to (dirt roads), and a Land Rover or Jeep (or bulldozer!) is what you need.
In each case, you need to have the right car.
What Kind of Car Are You Driving?
In this analogy, the car you drive is the capabilities and patterns of your team. Is your team really good at executing a plan if there is clarity? Can you navigate complexity without losing your cool? Do you know when to push through obstacles by going off-road?
Depending on your team’s maturity, experience, and makeup, you might excel in one area but not in the others.
While every team is different, I’ve found that newly formed teams, or teams composed of primarily junior engineers, often struggle with complexity or large roadblocks. On the other hand, some very experienced or mainly senior teams can struggle to execute as they become distracted by potential edge cases or spend too long ping-ponging on solution options. But they really know how to get around roadblocks.
I’ve also learned that some individuals are better “drivers” than others in each of these situations. Some engineers might be really good at tearing down a dirt road or bulldozing through an obstacle but need help to navigate a complex and dynamic environment with many external factors. I’ve met engineers who have built their reputation on navigating such constrained systems with precision and ease and others who constantly tinker with new ideas that unlock an entire team with their work.
Learning who on your team is the preferred driver for each car can be just as helpful in knowing which car you need.
Switching Cars
The unique part here, though, is that you can switch cars. In the real world, you’d be stuck on I-40 with the same car all the way through. But in our analogy, you get a magical morphing car that transforms whenever it suits you.
How does that work? These switches can happen as your team builds new skills, practices problem-solving together, and gets really good at owning your domain. By solving more and more problems together, helping each other acquire new skills and knowledge, and learning when and how to pivot, the teams extend their abilities to transform from any given mode into another.
This switch happens suddenly, though. You’ll hit a roadblock and need to hop into the Jeep to keep making progress on a deliverable. You might get back to the highway, see the ramp, and then boom: realize you’ve got some potholes to navigate and a bunch of traffic (traffic is a whole nother conversation!). The sooner you recognize when you need to switch cars or your working mode, the better.
What I’ve found really helpful here is recognizing who those “drivers” are from earlier. If you have someone on your team who knows how to navigate the city well, give them the proverbial wheel the moment you exit the highway. It acts as the catalyst for the shift that needs to take place.
I know this analogy is a stretch, so thanks for reading along!
I was originally inspired to write it after listening to an interesting episode of Developer Tea. While the episode focuses more on gaining alignment on motivation and team planning, it talks about how better planning often requires an “engine” for generating plans based on values and processes rather than plans being generated on an ad-hoc basis.
When discussing this with a colleague, he remarked that different engines will naturally generate different plans to get to a particular destination. The reason is that some engines (cars) are constrained by existing roads, some engines are constrained by fuel, and the size of engines also varies. Instead of trying to find the “one perfect engine,” an effective team knows how to take these external factors into account when developing their plan. To use our analogy language again, an effective team’s road map will make sure it uses roads they can drive on without breaking apart or running out of gas.
I hope this somewhat whimsical article helps you think a bit differently about planning software projects for your team. I’ve already seen how these ideas have helped me understand how others work and when/why the right call is to switch cars rather than trying to find a one-size-fits-all roadmap.
Happy coding!
If you enjoyed this article, you should join my newsletter! Every other Tuesday, I send you tools, resources, and a new article to help you build great teams that build great software.
Dan Goslen is a software engineer, climber, and coffee drinker. He has spent 10 years writing software systems that range from monoliths to micro-services and everywhere in between. He's passionate about building great software teams that build great software. He currently works as a software engineer in Raleigh, NC where he lives with his wife and son.