Pitfalls of a Non-technical Manager

This post is intended towards the non-technical people working in the software industry, specifically towards the non-technical managers who lead teams of developers.

I hope to have a series of at least two posts on this topic, if not more.

1. Pitfalls of a Non-technical Software Manager (This post).
2. Ways to improve management skills by developing technical knowledge.

Non-technical people working in other roles that directly influence development teams will also find this information useful. For example, roles such as Scrum Master, Product Owner, Project Manager, etc.

I have worked long enough in the software industry to acknowledge one fact – there is a massive communication gap between technical and non-technical people, and more specifically between developers and managers. In professional circles, the two are said to exist in “Different worlds” – The programming world and the management world (the dark side).

The disconnect between the two worlds is best illustrated in the following comic:

The Non-technical Litmus Test

Image from http://xkcd.com/1425/

Have a look at the comic. Do you get the conversation? If the comic has left you confused, frankly the only reason I can think of is a lack of technical skills. You are a non-technical manager.

If just a comic can get so difficult to understand, what does that leave you with when managing large scale projects and people?

Who Qualifies as a Non-technical Manager?

First let us define what “non-technical manager” means in the context of this post. If you fall into one of the categories below, you are a non-technical manager.

1. You have never done any real programming. [The half day course you attended in the nice hotel or the 3 hours you spent watching videos on the internet don’t count.]
2. You have no idea about the code and architecture in the project you are handing. [Heck! You can’t even create the developer workspace of the project you are handling.]
3. You never attend the technical meetings. [Because you can’t contribute or understand anything there. e.g. architecture decisions, code reviews, technical brainstorming etc.]
4. You are no longer actively programming, either on job or on open-source projects. [I thought long and hard whether to include this category. I realized that this category of people is the most dangerous when it comes to managing people and software projects. Because they have coded in the past, it is easy to get into a ‘I know it all’ attitude.]

Why This Post?

So, why am I writing this post? You might think that you can manage (or you are already successfully managing) a software project.

First, it benefits you — the non-technical manager. There are two important benefits you get if you are a technically aware manager.

• Better management skills — You will always know what you are doing.
• Better communication — You will always know what you are talking about.

And you get to avoid a huge number of pitfalls as covered below. These are some of the common mistakes and traps that a non-technical manager falls into, thereby leading the team to failed projects and frustrated developers.

Second, it creates a happier work atmosphere where all developers are motivated and driven to do their best, knowing that you are always there to back them up.

Pitfalls of Being a Non-technical Manager

1. Process Will Fix Everything

The tell-tale sign of a non-technical manager is that they think most problems can be solved by changing the development “process”. It implies that all the problems can be fixed by tweaking the process and that the quality of people and the quality of their work is of lesser importance.

“Management techniques” always get applied only towards the developers, but not to other aspects of the business. For example a manager thinks they have to make the developers stay longer in the office and create unrealistic deadlines to maintain pressure and stress.

Seeing software development as a mechanical process is the #1 mistake of non-technical managers. Process changes are the right solution all the time only for manual labour work, not for creative work.

2. Quantity > Quality

Although you use the term Quality in most talks and presentations, you are not exactly sure what it means.

Its common to hear statements such as “We want it by Friday, with quality”.

As soon as the deadline nears, you are more willing to make sacrifices to the code quality rather than push ahead the deadline or cut the scope of the requirements. Because for you the code is something that can always be corrected later, but the deadlines are hard targets and should never be missed.

The reality couldn’t be further from that. It is in fact the deadline that should be moved, while the quality should always remain intact and consistent. In case the deadline cant be moved, the correct way to handle things would be to have a scope reduction.

You may be thinking, “But I have already promised to the customer…”. That point will be addressed next.

3. Promise on Release Dates in Agile

So you have spoken to the customer and promised a delivery date already? Sometimes, I have seen these dates 2-5 years into the future. Was the complexity and the scale of the development work understood before making these promises?

Often when companies say they are working on a lean or Agile model, they are only speaking of the development teams.

A crucial aspect of Agile is that the entire company needs to embrace the model, not just the development organization.

So instead of giving dates you could have told the customer that he gets to see progress of the development work every 2-4 weeks?

4. Manager vs. Leader

Without technical know-how, you are nothing but a floating piece of wood in the ocean with no ability to maneuver your way through impediments or take decisions based on sound judgement.

As is happening in our industry currently, you might still go ahead and make those decisions, but you have no way of knowing if those decisions were correct or wrong, if the project is going to succeed or not, etc.

You will still be a manager, but will never be seen as a leader.

5. All Developers are the Same

You can’t appreciate the nature of technical work. A work culture is born where none other than the developers know (or care) a dime about the code. The 10x developer is treated the same as any other developer. No one understands that programming is not typing! Developers always need to justify their work, how hard they worked, and the time it took to do the work. Developers are just numbers on the payroll.

For any company to attract and retain the best programming talents, it is important to create the right working culture without the above problems.

6. Reward Top-talkers

Because you cannot really distinguish between the work done by various people of your team, you are in no position to appreciate and distinguish technical work done by them. It leads to a culture where top technical staff are neither understood not rewarded.

So who gets the reward and gets the biggest salary hikes? The answer is obvious: The top talker. The one who is the most vocal is generally on your “best list”.

The real top performers — the real grinders — will never be happy working in such an environment.

7. Unable to Understand Work

What could be more unfortunate than not being able to understand the work that people under you are doing? How can you stand up to or defend your developers without knowing the work they are doing?

Because you are managing software developers, you ought to know about programming concepts. Only a skilled technical person commands respect from other technical people.

One may ask “Why don’t developers try to understand managerial work?” The answer is that the managers are looking after the developers, not the other way round.

8. Over-simplification

Everything should be made as simple as possible, but not simpler.
—Albert Einstein

That’s some pretty solid advice from Einstein.

The bitter reality is that most managers ask the programmers to dumb-down or use plain English to explain a technical concept or an issue.

The big negative to this approach is that by over-simplifying the technical talk, the inherent complexity of programming and the nature of the technical work never gets conveyed to you.

This results in over-simplification and estimation bias on everything that developers do.

What Next?

Now we know the issues that arise when the manager is non-technical. From personal experience, none of the above can be addressed until managers truly understand the people they manage and the intricacies of the work those people do. For a start, one way is to make sure that the managers are aware of programming concepts, how a programmer mind works, what problems they face, etc.

Is it feasible? Or do we give in an accept that things are never going to change in this industry?

As the saying goes, “Everything begins with an idea”.

Some such ideas to overcome lack of technical skills will be introduced in the next post in this series. The change shall happen, slowly but surely.