This post is intended towards the non-technical people working in the Software industry, specifically towards the non-technical manager who leads teams of developers.
I hope to have a series of at-least two posts on this topic, if not more.
- Pitfalls of a Non-technical Software Manager (This post).
- 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 e.g. roles such as Scrum master, Product owner, Project manager etc.
I have worked long enough in the software industry to acknowledge one fact – That there is a massive communication gap between technical and non-technical people. 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
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 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 definition what “non-technical manager” means in the context of this post. If you fall into one of the below, you are a non-technical manager.
- 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. ]
- You have no idea about the code and architecture in the project you are handing. [ Heck! You can’t even create the developer work-space of the project you are handling. ]
- You never attend the technical meetings. [ Because you can’t contribute or understand anything there. E.g. architecture decisions, code reviews, technical brainstorming etc. ]
- 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 ‘I know it all’ attitude. ]
Why this post?
So, why am I writing this post? You might think that you can manage (or already successfully managing) a software project.
Firstly, 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 in the next 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 e.g. manager thinks they have to make the developers stay longer in office, create unrealistic deadlines to maintain pressure and stress etc.
Seeing software development as a mechanical process is the No.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 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, 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 can be as much as 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 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 take those decisions, but you have no way of knowing if those decisions were correct or wrong, 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 for 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 a 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 and 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 by 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 to make sure that the mangers are aware of programming concepts, how a programmer mind works, what problems do 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 over-come lack of technical skills will be introduced in the next post in this series. The change shall happen, slowly but surely.
| Reference: | Pitfalls of a Non-technical Manager from our JCG partner Deepak Karanth at the Software Yoga blog. |
