Are You a Software Developer -- or a Leader?

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

“You want me to do what?”

I was flabbergasted. My manager Daryl was looking at me with a slight smile and nodding his head.

“I want you to lead the team,” he said. “The team has grown too big for me, so management has decided that you would be a solid fit to take over as project manager. “

This couldn’t be true. I had only been on the project for a year and there were eight other developers on team.

And I was the youngest – by far.

“Why me?”

Daryl uncrossed his legs and leaned forward a bit.

“Because you are the best person for the job.”

Still not convinced, I said, “Yeah, but most of the others on the team can code circles around me. Why not pick one of them.”

Not to mention they were older and more experienced.

He leaned back in his chair and sighed. “Listen, you will learn that leadership isn’t about how technically proficient someone is. Notice I didn’t say you were the ‘best developer,’ I said you were the ‘best person’ for the job. Now let’s go tell the team.”

As Daryl and I walked down the hall to the conference room where the team was waiting for our weekly status meeting, I became a little less nervous. Perhaps he saw something in me that wasn’t just about writing code.

But I was very concerned about how the team would take it.

Everyone sitting around the big conference room table seemed to take extra notice that Daryl and I walked in together.As he announced my new role as project manager, I glanced at the faces around the room.

Some seemed indifferent. Others smiled and nodded. And one guy just crossed his arms and frowned.

After the meeting most of the team congratulated me yet one did not. Yep, Mr. Frown Face. And it just so happened that he was the oldest one with many more years of experience.

As the weeks went by it became apparent that although I enjoyed being the team’s project manager, it was a very challenging role with more responsibility. I still had code to write and now had the pleasure of being responsible for everyone else’s code.

It was also up to me to lead meetings, interface with our business users, manage project plans and make sure the team delivered quality code on time and within budget.

That wasn’t all too bad. The most challenging change was in how the team interacted with me because I had to be concerned with people not doing their jobs.

I was aware of various issues with the team but as a peer, they were an annoyance, but not my responsibility. For example, one “couple” spent a lot of time openly flirting with each other to the point it was becoming a distraction. And another team member showed up late, took two-hour lunches and promptly exited at 5 PM on the dot.

The worst situation I had to deal with was the older developer who had been walking around with the perpetual frown since my promoted. His last code integration deliverable ran very slowly and had bugs he should have caught with unit testing.

Dealing With It

I took on each of the various issues one by one, each with a bit of a knot in my stomach.

First, I individually explained to the flirtatious duo that they needed to cool it in the office. They both denied anything inappropriate was occurring, but the behavior improved.

Then I chatted with the fellow not putting in the hours and found out he just didn’t have enough to do. With a little more workload, his attendance improved.

As for Mr. Frown Face, he didn’t take to my suggested code improvements so well. He was very combative and had excuses for all the problems – none of which were satisfactory to me.

When I was simply writing code these were not my concerns.Now they were and the team knew it too. I’d pop into a cube and the developers sitting there chatting would stop talking and disperse.

I figured they were complaining about me.

I’ll admit, I had talked negatively about my manager in the past. I have found that developers can be cynical about management because of poor decisions that put developers in difficult situations.

Those feelings caused by such experiences are projected on the new manager, immediately putting them at a disadvantage. Plus, developers are typically pretty darn smart and think if they were just left alone to crank out code, all problems will be solved.

A Thorny Situation

Well, Mr. Frown Face was projecting serious daggers my way.

We had a few run-ins where he would push back on something I was asking him to do. What bugged me the most was that he wasn’t professional about it. Instead of proposing useful solutions he would make sarcastic remarks or just snicker when I made a suggestion.

It became very apparent why Mr. Frown Face was not considered good project manager material.

The issue with him continued until one night I was awakened by a call from him. He was in a panic because the on-call person had contacted him about a module he developed that seemed to have brought down the whole production system. They had spent hours trying to figure it out and were at a loss.

We got on a conference call and I took them through every step of the production process, eventually finding one flag that was set incorrectly. The code was recompiled with an emergency patch and production finished – although later than our service level agreement required.

The next afternoon, my manager Daryl came to see me to find out what happened. I explained what the problem was and how it was fixed, but never called out Mr. Frown Face. I said it was my fault for not reviewing the integration test plan more closely.

Mr. Frown Face came to see me before leaving that day. He had overheard the conversation with Daryl in my cube and wanted to thank me for not pinning the blame on him. He left as Mr. Smiley Face and from then on was much more receptive to my guidance.

What I have learned over the years is that leadership has little to do with technical expertise. More important leadership traits are fairness, integrity, honesty, trustworthiness, competence and an ability to communicate with your team, management, customers and sometimes the rest of the outside world.

Not every developer is cut out to be a leader. And some developers are much better suited to be a leader instead of writing code.

Most important, you don’t have to be in management to lead. Think about your actions and look for opportunities to show leadership every day. Even when you aren’t happy with management decisions, don’t hold it inside or worse, undermine your manager with negative comments behind their back. Instead be forthcoming with your concerns and come up with ideas that will lead to solutions.

Before you know it you might be tapped for a management position. Will you be ready?