10 Mistakes To Avoid as a Software Development Manager

Speaking from experience — with a second chance in a software leadership position

In my early software development career, with much hard work, I am very fortunate to become a software manager relatively early. Being relatively young and naive as a new manager, my focus has been on commitments and project deliveries.

Still, I did well and climbed the management ladder to become a senior manager without even realizing I had missed out on so much of what I should or should not do as a manager. As I look back today, I met the bottom line back then, but I failed in many ways.

After resetting my career and moving into a new industry, i.e., mobile development for the last seven years, now I’m going back to some level of management. Below are the mistakes I will avoid during this second chance I am very fortunate to have.

1. The Project Is Not the Top Priority — People Are

As developers, what’s most important to deliver? Our projects and deadlines! The only means to prove our worth and capabilities to our boss is to ensure we deliver committed deliveries.

I brought that mentality on even after being promoted to supervisor, manager, and later promoted to senior manager. I impressed my boss by showing them all projects were delivered on time.

Of course, I do have people working under me. They are resources to make projects feasible and delivered on time. When we lose one person, let’s look for another one.

I was so wrong.

Yes, I delivered projects, but now after ten years, all these projects are obsolete. They are history. Soon most of them will be forgotten. But the people we worked with ten years ago are still very much alive. I didn’t mistreat them back then, and we are still friends.

But then I asked myself: How much did I invest in making them better as a person? How much did I concern myself with their growth, so they can be better in what they are doing, not just to get the project going? How much did I know them as a person? What are their passions and aspirations?

Thinking about that makes me deeply remorseful. I failed greatly. We had 1-on-1 catch-ups, and during those catch-ups, all the conversations ended up being about the project, project, project.

Don’t get me wrong, projects are important. But if we build the people and connect with them, project deliveries become so much more natural. People-first focus enables us to grow people, connect with them, and get projects delivered.

2. Processes Should Not Be for Stats, but for Ease of Development

I’m relatively disciplined. In order to know where I spend my time most, I created a spreadsheet and logged what I did consistently. For health purposes, I measured how much water I drank daily with a log that counted how many liters of water I drank.

One day, I recall I was considering measuring the productivity of the group. We needed to measure the effort required for a project and quantify the improvement of it over time. Back then, we didn’t have a good tool to automatically do that.

So I came up with some processes and got each developer to log their effort regularly as precisely as possible for me, and I combined them in a spreadsheet. From it, I created a formula that calculated everything. The developers weren’t very happy, but I convinced them with the quote “if you can’t measure it, you can’t improve it.”

I was so wrong.

While this worked, and it wasn’t too much work (to me), it required quite an effort for the developers to remember, enter those values regularly, and get that measured. This data was then compiled and generated into some charts and statistics.

It didn’t help the developers’ productivity at all, nor ease their work in any way. I added more processes to their work without any benefits. The developers’ main priority was to get the project done, not provide statistical data. Any process introduced should help them work on the project better instead of loading them with more “tasks” than their actual work.

If we needed measurements, we should have hired professionals who would be able to quantify the developers’ effort without making their lives harder.

Anyway, last I recall on the data gathered by my initiative to measure productivity, the data didn’t end up being too useful, and finally, the process was discarded. All effort wasted!

3. Don’t Make Developers Compete — Build Camaraderie

“Competition improves performance,” I was once told. Without competition, people get complacent and later performance will degrade. That’s why we see their results in the Olympics keep improving because there’s tight competition, right?

That’s what we were taught in school as well. Students are ranked and positioned in the class. This will inspire students to work hard and get into better classes or schools eventually.

If we apply this mentality to software development, we start to introduce processes like, see who creates the fewest bugs and who has the least PR review feedbacks. Some even make a “hall of shame” for those who earn the highest PR review feedback in the code check-in request to dissuade developers from committing bad code.

Maybe we can also check the code contribution quantity by person, divide it by the bugs they contribute, and then measure each developer’s achievement. Let them compete to be the most productive developer.

I was so wrong.

One thing I forgot, working is not the Olympics, which happen every four years. Nor is it a school that one will graduate at an expected time.

The developers work five days a week, eight hours a day. It can be as much as 30% of their life, where some spend more time working than with their families.

A constant competitive environment will make the working environment hostile. Everyone will come in thinking about who will be their next rival. There will be politicking, backstabbing, and even worse, building a very uncooperative and dysfunctional team. It will be a civil war.

One lesson learned from any country: a country with civil war will fall to external forces. Similarly, organizations with internally competing dysfunctional teams will lose out to competition externally.

Therefore, let’s not build competition within. Instead, let’s build camaraderie! Make the workplace a place everyone wants to come and work together, laugh together, and build a strong sense of team together. Not only will it make developers happier at work, but it will also build a stronger organization.

4. Don’t Be Stingy With Praise; Celebrate Small Wins

I was brought up with the mentality that, by default, a job well done is expected. It is our responsibility! We are supposed to do it! Nothing is there to be praised. I think that as a doer, that’s what we should expect. We are paid to do good work.

As a manager, I’m afraid of “praise” and “thank-you” inflation. If we give someone praise or a thank-you too often, its value will become less and less. I think that eventually, people might take it for granted.

Therefore, I reserved my “thanks” and “praise” only for the really, really big achievements, i.e., an achievement that is super impressive. And my expectations went higher — to encourage “improvement.” It used to be that 80 points of goodness got “praise,” now 80 points is the norm and 90 points is required to get a “praise” of good work.

I was so wrong.

Little did I know, I was actually building an unappreciative culture. Every good deed done is expected. Why say “thank you”? After a while, people started to just do the basic essentials, as no one appreciated it.

The bar to get a “thank-you” become so high, so why bother to achieve it? Only a few top-tier performers always got all the appreciation and thanks, as they were the only ones that could constantly achieve the unachievable. Soon, most people started wondering, why even come to work. Perhaps only to earn bread and butter for the family, and nothing else.

I had an opportunity to work with a young, smart guy. Hardworking with a great attitude, but he was never at the top. Hence, he didn’t get much “gratitude” from me as the manager. I appreciate him within, but never verbally, just to be fair to the others. I treated them all equally unless they hit the high mark.

One day he resigned and went to work for another organization. And a few years later, I heard he passed away due to some unexpected illness. Young and promising guy. It’s sad he had to leave too fast. To make it worst, I never expressed my gratitude for all his sincerely done work, and I will never have the chance to do that anymore.

5. Avoid Working Overtime. Or Emailing At Night

I’m a super hardworking person. Dedicated. When I started my working career, I would work from 9 a.m. to 2 a.m. to get things done and impress my boss.

The norm getting home for most of the organizations I worked with back then was 6 p.m., although the official working hours were 9 a.m. to 5 p.m. As a hardworking employee who worked harder than others, my usual leaving time was 8 p.m.

My boss warned me to avoid doing this so I didn’t burn out. I didn’t burn out, and so I climbed the ladder to “success,” as mentioned earlier. I became a supervisor fast, later became a manager, and then became a senior manager.

I brought the working late attitude from my time as a developer to my time as a senior manager. I needed to “demonstrate” to all that I got promoted because I worked hard. I needed to be the role model. I emailed follow-ups late at night about things that I missed during the day.

I didn’t purposely do that, but because the day was filled with meetings, only at night did I have time to clear my emails and follow up on things. Hence, that became a habit.

I was so wrong.

I thought, “I’m doing it for my family, to earn a career and make life better for my family.” I didn’t realize how much time I neglected my family. I’m fortunate I had a really understanding wife who supported me during these periods so much and still managed to bring up my two kids who love and cherish me as a dad.

Not only did I neglect the family, but I also built the culture of working late. Not many could keep up with my pace, but more people were trying to keep it up. As I emailed at night, my direct subordinates would at times feel pressured to respond immediately, just to show that they were also dedicated.

The entire working culture became like a working-engine pressure cooker. Many people came to work literally feeling like they are always at the point of breaking down. Some still strived on because the company “paid them well enough.”

But working was no longer pleasurable. Coming to the office was a toil. Some “stayed back late” just to show they were “at work” without really working. They had contributed their 30% of life to the organization, and now had to pay more —a tradeoff of their family and personal life.

Thinking over it, I failed as a person, as I didn’t make life better for others. Not only did I ruin my family, but the families of others.

6. “Developers’ Happiness” Is Not Just Nice To Have

I never knew the term “developer happiness.”

When considering a process improvement — tools, technology, framework, etc., — for work, the categories I consider are effectiveness, efficiency, and cost.

What the developer feels about it is “secondary.” If it is an effective, efficient, and reasonable cost, excellent! Let’s get to it.

My theory back then was when we are more effective and efficient, developers should naturally be happier. If they are not, at least when the organization benefits from the change, we can give bonuses to developers, and they will be “happier.”

I was so wrong.

To me, back then, people were always secondary — below successful project deliveries. Terrible, when I think about it now.

The first time I heard about “developer happiness” was when I first transitioned to mobile development as a developer. We were proposing the switch to a new language, i.e., Kotlin, which was getting popular back in 2017.

When convincing the management about the new language, I tried to justify how great the language was in terms of its expressiveness because it was a more concise language compared to Java. I was questioned about its efficiency in terms of compile-time, run-time, the potential risk (will it continue to be supported in the future, etc).

It was hard to prove all the above, but my technical lead said, “If there’s no obvious downside of Kotlin, and if this increases developer’s happiness, it is worth a consideration.”

Wow! My happiness is important! I felt treasured and appreciated.

When considering changes to either tools, processes, etc., the developer's happiness is a very important consideration. If the developers like it, they will make it work as much as they can, unless we have chosen a horrible option.

Even if we did choose incorrectly, but we did it for the “developer’s happiness,” the team will willingly work towards rectifying the situation and improve it.

We will learn from mistakes, and the ones we “happily” get into, we will also “happily” fix.

7. Our Position Is Just a Position. Be Grateful for Any Treatment

“I worked hard; I deserved the promotion!” That’s a pitfall one can easily fall into when getting something that they have worked hard and earned.

I am very cautious not to fall into this “pride.” But after being in management for several years, the feeling of “eligibility” for special treatment naturally comes in.

In a team photo, I’m supposed to get “special seating” due to my position. People naturally greet me when they see me, and they know I exist. I get the attention and the special treatment. I also get priority in many things and exclusivity as the senior manager.

When I speak, people listen. I thought I had “earned it” and “deserved it.”

I was so wrong.

When I shifted my career, I no longer got all the attention. No more premium treatment. When I spoke, people interrupted and moved on. I’m just a “noise.”

Then I realized one reality: many people treated me better when I was a manager, not because of who I was, but purely because of my position.

In reality, I didn’t deserve it. If they treated me well, I should be grateful. Even if they didn't, that is all right. Never fall into the trap of feeling “entitled,” because we will never know when the one day will come where we will no longer be in the position.

In fact, it is in the days where we are “not in position,” that we discover real friends and people with genuine intent. People who treated you well without any strings attached. These are great people that we can build long-lasting relationships with.

Regardless of our position, we are just normal people like everybody else. Treat everyone respectfully. Never expect exclusive treatment. After all, we are just fellow mates living on this earth temporarily. One day, everything will pass away. By then, it is not how well we were treated that counts, but instead how well treated others.

8. Stay Technical. Be Relevant to the Developers

I started as a developer. I focused on learning technical stuff: programming languages, techniques, paradigms, best practices.

As I became a senior manager, I now had managers working for me. I thought to myself, perhaps I should focus on leadership and read more management and leadership books.

My supervisors and managers should handle all that technical stuff; I just “delegate” it to them. I no longer have time for low-level “technical-stuff” anymore.

I was so wrong.

Initially, that was sustainable, as my “past” knowledge was still relevant, and I could still understand what the developers’ said, etc.

But after a while, technology evolved. New languages emerged, and new frameworks were introduced. The developers moved on. What I understood was no longer relevant.

I still tried to use the “old knowledge” to link to what was brought up and discussed. I started making a lot of assumptions and sometimes oversimplifying things rather than staying in reality. I could no longer understand the pain and challenges of developers. My inability to comprehend the complexity made me demanding, and I issued unreasonable expectations.

To me at that time, any programming language was just a programming language. What was so difficult about that. We could learn any language within weeks and master it, as our foundation of C++ would bring us anywhere.

Now, as I restart my career, and I’m back to actual development, I now appreciate the many hardships of developers — the learning pain, and the technical challenges.

When the developers know we understand them and can relate to them, they are more willing to be led and guided. They trust our leadership.

9. Don’t Forget To Invest in Yourself. It Does Good for You and The Company

I am a very dedicated employee. My time is used to get the project done. I focus my time learning all internal processes and the company’s proprietary tooling. All big organization has their own processes and tooling, so my aim is to master them.

In another word, my investment is all focused within the organization. I’m a very loyal employee. If I spent time learning some other thing, I feel I am not focused enough because the value gained is not directly applicable to how I can apply it within the organization.

I was so wrong.

Not only I was wrong, but I was also stupid and naive too!

It is important to know and understand the organization’s internal processes that are relevant to our job, but we should learn just enough for what we need for our work.

Instead, we should spend time learning the external knowledge and areas that we have a lot of passion for. Such knowledge may not be directly relevant to the organization, but it does open our minds to broader thinking and understanding of many things.

On a selfish note, we keep ourselves relevant to the job market. Proprietary knowledge is not very useful on a resume. The industrial relevant skillset makes one continue to be marketable.

At the same time, in reality, our broader knowledge also makes us more creative, as we have the ability to think out of the box when looking for improvement and solutions. When our organization has a very diverse set of knowledge and skillset, then it will innovate and grow better.

Other than learning, we should spend time investing in ourselves in other aspects of life, such as health and emotional well-being. By being a more holistically equipped person, it makes us better employees too, and better role modes.

10. Never Rule Out That Sometimes We Are The Problem

Problems are part of life, and it is the same in management: We are there to solve problems. Sometimes we call them opportunities.

When we face problems, we have many tools to help us perform root-cause analysis. The tools help us to list different possibilities of what caused the problem, which is very helpful.

But the tool is only as helpful as to how truthful we are in identifying the root cause. In some organizations that don’t tolerate mistakes, people will avoid listing potential root causes that will reflect that they are part of the cause.

As a manager, my role is to identify the cause of the problem. Maybe it is structure, maybe it is external factors, maybe the competency of our employees, but never is it my mistake.

I know I have done my best, and the root cause cannot be me.

I was so wrong.

By never looking at myself as the potential source of the problem, I felt so powerless at times. I continued to look outside of me for what was to “blame,” so I can then avoid “accountability” of the issue.

The fault is always “others” and not “oneself.” Hence, we are not really in full control. With this, we may miss out on the actual root cause of the issue if we always exclude ourselves from the picture.

I learned this from a tech lead I had. One day a dedicated developer did a seemingly “silly” mistake, causing our software to crash externally. After some investigation, the developer learned of the mistake, felt really bad, and regretfully admitted to the mistake.

If I was the manager, perhaps I would have compassion for the developer, and ask for them to be careful in the future. I would probably ask the developer to help find a resolution to prevent the mistake in the future.

My tech lead at that time, instead of feeling relief that the developer admitted the mistake, took full responsibility, stating he had failed to make a safety net to prevent such a mistake. If he had created the safety net, this mistake would have not gone uncaught before releasing out the software.

When I heard that, I didn’t despise the tech lead because he failed to create the safety net. Instead, my respect for the tech lead grew. Not only did he make the developer feel better but also took the responsibilities fully. In that, he felt empowered to ensure the problem was resolved. Hats off!

TL;DR

If we look at the ten items above, management focus should always be on the people. The process is to help the people. The projects are opportunities for the people.

People-first leadership. In fact, if there are no people, there’s no leadership.

The priority is to grow the people and the people in return will contribute better to the organization.

People managers are nothing if there are no people to work with. We are where we are because they are there.