The leadership gold in your git history
Many of the methodologies we use today help keep us forward-focused. The tools, the processes, the team structure — it’s all there to support and strengthen our teams’ ability to ship value to customers.
And while forward movement is necessary, being entirely forward-focused isn’t actually the best approach to running software teams. There’s a counterintuitive way about those who arrive at their destination before the rest: they take time to reflect. They look back and learn not just from the previous sprint, but from the entire history of their codebase.
And while a team or organization’s history is commonly seen as a valuable leadership tool — where Marketing can draw from previous campaigns and Sales can see the impact that strategic changes have had on their productivity — Engineering has effectively been left without a way to access their work history.
“Right off the bat, one of the most exciting things about GitPrime was that it wasn’t a tool that started the day you signed up, and then forward you could gather data. No – from day one, we were able to analyze our repos all the way back through time.
So now, when someone asks, ‘hey, how much are we going to slow down during holidays?’ I can answer that question. Or, ‘If someone leaves the company, what’s the effect on our rate of contributing to projects?’ I can answer that question because I can go back in time, see what actually happened, and use that as a predictive indicator of what is likely to happen again if an event like that occurs.”
— Trek Glowacki, Popular Pays
But beyond using your history to inform future decisions, there are a few less-obvious ways that make the ability to quickly access and visualize the entire history of your codebase a valuable instrument.
It reduces the effect of cognitive biases
The human brain is an incredible intuition engine — it’s like a supercomputer, humming along, collecting data, and detecting oddities and patterns. It’s always absorbing and sorting through information.
But, while it’s an incredible ability, our brains are naturally inclined to fill in the gaps between the information we have, which makes us vulnerable to biases or bringing otherwise false information into the picture when we have limited perspective.
For example, our brains might respond to a lack of information by:
- Filling in characteristics from stereotypes, generalities, and prior histories,
- Editing and reinforcing errors in memories,
- Favoring what is near and/or what we understand, or
- Being drawn to details (or people) that confirm our existing beliefs.
But, when we have data around how our teams work, our brains don’t need to fill in gaps. We don’t walk into a room full of engineers playing ping-pong and assume they’re not serious about their work because we know they’re doing a fantastic job. We’re aware when someone is being over-relied on or assigned the wrong tasks. We’re comfortable with how long it’s taking a new engineer to integrate with the team, because (even though we can be impatient at times) we have the data to show that it typically takes this long to fully onboard a team member.
It’s important to fuel our intuition engines with a ton of meaningful data around how our teams work so we’re less vulnerable to having cognitive biases negatively affect our decisions.
It facilitates more productive conversations
We spend much of our time talking with others and looking for signals that show how work is coming along so we can help our teams by removing anything that’s slowing them down.
Said differently, we spend a lot of time getting status updates.
But status updates tend to be vague. You ask Jessica, “How’s it going?” — she responds “good.” You ask Jeff if he’s succeeding, and he says “I think so.” These conversations are ambiguous and filled with interpretation. They leave you leading in a world of uncertainty, and that gives you a limited window into how effective you can be in your position.
But when you can visualize how different members of your team work, you can start to detect when someone is struggling. You can notice when someone is dealing with poor requirements, or when the problem someone was assigned to isn’t a good fit. This kind of data shows you the what — it gives you a clear status update, and quickly — so you can jump to figuring out why. It makes for a much more meaningful and productive conversation.
It provides for quick pattern recognition
Having a historical concept supplies a solid reference point.
Let’s say you’re dealing with a problematic feature, and it’s in the same class of problems that the team has run into before. With the ability to quickly access your codebase history, you can look back through time and solve for questions like, “is this simply a little fire that needs to be put out, or is this a larger systematic issue that we keep running into?”
Ultimately, when you have the entire lineage of the codebase to feed into your brain, you can start looking at how the team operates. You will begin to notice patterns and detect things that look a little wonky.
And as the saying goes, “those who don’t learn from history are doomed to repeat it.”
Get Engineering Impact: the weekly newsletter for managers of software teams
Keep current with trends in engineering leadership, productivity, culture, and scaling development teams.