I recently had lunch with a fellow software developer at work, and we got into an interesting conversation about his latest trials and tribulations as a technical team lead.
To protect the innocent, let’s call this coworker “Fred”.
I’ve known Fred for many years, and have worked with him once before. He is well-liked and respected among his peers, and he’s my “go to” guy, as a software developer.
Most software developers have at least one “go to” guy or gal. It’s the person you inevitably reach out to, when you’ve been pulling your hair out over a particularly nasty problem, like getting stuck debugging some thorny application bug or trying to wrap your head around some new difficult technical concept.
I’d dare say I’d label him one of those “10x programmers”, though I personally HATE using that term – I’ve blogged about that in the past. But back to my point, Fred is a technical whiz kid. He has deep knowledge across a very wide swath of technical concepts. MUCH more than myself, and I’ve been in the programming game for near two decades.
But I have no qualms admitting Fred can program circles around me. He’s just THAT good.
As we were walking out to lunch, Fred lamented to me about the recent difficulties he was having in his role as his team scrum master.
For anyone unfamiliar with what a scrum master is, a scrum master is the facilitator for an agile software development team. Scrum is a methodology that allows a team to self-organize and make changes quickly, in accordance with agile principles. The scrum master manages the process for how information is exchanged.
In essence, the scrum master can be thought of as the team’s technical leader. He makes sure the development team is heading in the right direction, according to the wishes of the product owner, who tells the scrum team what to work on.
So the scrum master works towards clearing all obstacles and impediments out of the way for the team and tracks the progress of each team member’s accomplishments.
I almost think of a scrum master, as the coach of a sports team, leading the players and offering guidance and direction during a game.
So a scrum master isn’t a manager, per se, but the scrum master, certainly has to lead and perform many managerial duties.
And this is where we get back to my conversation with coworker Fred.
Keep in mind that while Fred has many years of experience as a professional software developer, writing code and designing applications, this was the very first time he ever acted in the role of an official team scrum master.
When I asked Fred his thoughts about being a scrum master, I actually remember him sighing loudly. He was having a rough time at it.
In his words, managing and leading a team was like “herding cats”, which any cat owner will attest, is an oxymoron. Cats cannot, and will not, allow us humans to lead them.
I have to admit I chuckled a little when Fred went more into details about the tough time he experienced, trying to step into a leadership role. I wasn’t used to hearing him talk about difficulties. After all, Fred was my technical go-to guy. Ok, Fred isn’t perfect, he makes mistakes just like all the rest of us puny humans.
But then it got me thinking about our strengths and weaknesses as software programmers.
Managing Requires a Completely Different Set of Skills
A good software developer has strong technical skills. It’s an absolutely vital ingredient for being a successful developer. We must know how to solve problems using our technical skills and knowledge. It’s what we get paid for.
Yet just because we may have strong technical skills, that doesn’t necessarily translate into other skills.
We’re living in an age of specialization where narrowly defined skills are regarded with high value by many potential employers.
There are not many software developers I know who also play professional sports for a living. Or who sing on Broadway.
Most of us specialize in one particular skill, and we work our entire career trying to hone it as much as humanly possible. The more skilled we are, the more valued we are in the job marketplace.
So I really shouldn’t have been surprised that my technical guru wunderkind, Fred, was having difficulties with his team. I won’t go into specifics, suffice it to say, he was having to deal with personality conflicts, team friction, and many other people problems.
And Fred was definitely having a hard time dealing with this. Dealing with people problems was wholly different than technical problems.
In the technical world, things are often black and white… it’s the very nature of computers. Computers are binary in nature. Things either work or don’t work in a computer. There is no gray area.
It’s why programming appeals to people with technical talent. You can always rely on the fact that computers never operate in a way that’s illogical. They always operate in a clearly defined and prescribed manner every single time.
But we humans are definitely not like computers.
We can act irrationally, and illogically, much as Mr. Spock was often fond of saying in “Star Trek”.
You can’t expect a person to act like a computer. So as strong as your technical skills may be, leading and managing people requires a completely different, yet equally important set of skills, to be successful.
I wouldn’t be surprised if my friend Fred naturally assumed his technical skills would come in handy in his new role as scrum master.
Turns out not so much.
I’ve blogged quite a few times about the problem of non-technical managers and executives who work at companies and organizations where technology is the lifeblood of the company.
It just doesn’t make sense to me why so many organizations think they can get away with hiring people who lack even the most basic understanding of core technology concepts and expect them to somehow work and mesh well with technical teams.
But I’ll be the first to say the problem is a two-way street.
Just because someone, like my coworker, Fred, is capable of hacking out beautifully constructed code in their sleep, doesn’t necessarily mean their technical skills will guarantee they’ll make good managers or know how to successfully lead others.
A successful manager or team lead must know how to work well with others. Show empathy. Know how to communicate well and possess many other soft skills.
And there lies the rub. Not many developers possess these soft skills, nor have any desire to learn. Some developers are quite happy staying technical and letting others deal with managing and leading. And more power to them.
Which is probably why it creates the very problem I often criticize … the lack of good TECHNICAL LEADERS.
It’s a rare find when a highly competent, technical person also possesses those necessary soft skills a person in a leadership role needs to be successful.
So my friend Fred is going to have to wing his way through his ordeal, I guess.
Would suggesting he watch more Dr. Phil reruns help any?
