Holding the band together
When I was a teenager learning to play the guitar, I was fascinated by lead guitarists. Playing that showy blues solo was where the real skills were. Playing rhythm or bass was for those who didn't master their instrument.
As you get older, you learn the opposite is true. While shredding a blazingly fast solo might look cool, it's the rhythm section that makes the music great. When a lead guitarist messes up a few notes, it's called improv, and nobody really notices. When a bass player loses their tempo slightly, the band crashes on stage.
So, why was I so attracted to lead guitar? Blasting 32nd notes while holding the guitar behind your head was obviously doing more. And more was better, right? I was too inexperienced to understand what mastery looks like. Reliably holding the band together was the real skill.
Competence makes skills seem deceptively easy to the untrained eye. It takes skills to see those skills.
Stable, predictable teams are like that. They do what they say they will do and tackle the occasional emergency without drama. Experienced software developers understand how powerful that is.
Yet, to outsiders, it doesn't look nearly as impressive. They see a team quietly chugging along and think: Is that it? Can't they do "more"? Surely they could push it a little?
It's a ubiquitous pattern in the world of software development. Whenever a team is under stress, people tend to get out of the way. They might be missing all of their commitments, but look at how busy they are! They are building five features at the same time. Let them work!
On the other hand, teams that have their act together are seen as unambitious and are bombarded with requests to do "more". They are on track, so couldn't they also quickly build that new report engine? There is no drama, so why not step it up just a little? Maybe add a bass solo?
Most people tend to believe two features are better than one. That making the deadline with seconds on the clock is more productive than delivering a week early.
They have a warped view of what mastery looks like.
As technical leaders, we need to accept that quirk of human nature and find ways to handle these requests for more.
One of my favorite ways of channeling these requests is showing people the impact of more. Building that report engine will make us move the deadline for the Sharepoint integration to November. Is that what we want? That's why a plan with a timeline is so crucial.
It's also why I'm a big fan of doing one thing at a time. The habit of consistent monotasking adds another layer of friction when trying to do "more". If the organization is used to doing one thing at a time, multitasking just feels wrong.
A lot of the conversation regarding planning starts with "Business should just..." or "Management needs to understand that..."
That's just not how it works. People outside software development look at delivery with an untrained eye. More looks like better to them. That doesn't mean they are incompetent. It means they lack the specific skills needed to appreciate what software delivery mastery looks like.
It's up to us to set up systems that make change easy and multitasking hard.
It's up to us to hold the band together.