Reinventing and Scaling a Software Group that Lost Its Way
Imagine yourselves managing a software development group which consists of very strong programmers. They research and develop one of the most complicated systems known to mankind. They write and write and write code — but eventually, no one wants software versions of that code. No one knows what they actually do day to day. The truth is — no one believes in your group.
This year I became a software development group manager, and I’ve had to deal with 15 employees in 3 teams who, from the moment they arrive until the moment they leave the office — feel transparent.
This is my blog series, which will illustrate my journey as group lead, from a moment before closing the group, to a well appreciated, needed and a formal authority in the corporation. In this first blog post, I will present the group’s background including a few major failure points which occurred in my group — and can occur in many big corporations.
In my professional past, I developed defense systems as a software engineer, managed autonomous vehicle projects for very big clients, developed autonomous vehicles navigation algorithms and organized events as a data science community manager. Becoming a software group manager, after a very technical professional past was not an easy task.
The more problems I’ve diagnosed in my group, the more it seemed like a failing startup — there was no money, no client, no motivation. I arrived a moment before shut down.
Before managing my group, I heard of it from many different sources. The main idea was its low productivity and a grand waste of human resources. I had to try and understand — how can such a talented group of software engineers not get their well-deserved recognition? How can they work on such important projects and still seem to be wasting their and the company’s time?
The more hours I spent at the office, the more challenges I’ve discovered within the group.
I felt that in order to succeed, I needed to reach out to the people as my first step, before digging further into the projects. I scheduled one-on-one talks with everybody and a separate talk for each team. My intention was to map out my people’s thoughts, strengths and professional interests, in order to be as impartial as I can to gossip. In the meantime, I started mapping out all the projects the group had been working on at the time, and the picture I got was so scattered and misguided that none of them actually knew what the group’s main objective was.
It was very clear to me that over the years the group has lost its professional identity.
How does a group lose its identity?
When the group was established, it had a very well defined purpose and a great value as it was beneficial for the client. It was in charge of application hosting platforms and applications which were consequently hosted upon these platforms. After the final version of each of the developed products was released, the spiraling began. The group received projects that had nothing to do with its main purpose, they began supporting technical issues in order to help clients other than the main client, and worst of all — the group stopped releasing versions. Unfortunate managing choices have let the group’s already bad reputation — to deteriorate immensely. Its identity had been completely wiped out.
I immediately devised a plan which consisted of freshening up the teams, teaching proper agile development methodology and strengthening the teams leads. On the verge of change, I decided to wait. I had spotted a hostile group member.
It was a programmer who the former group manager put in a team lead position. He got to manage the strongest team of all three. As a team lead, he somehow managed to wreak havoc upon the entire group and be completely unproductive.
I knew I had to deal with the human resources problem before I headed on to solving the other issues.
To sum some of the damage he caused over the years — he set irrelevant assignments to his group members, disappeared for large amounts of time during the day, failed to complete his assignments as a programmer and his responsibilities as team lead, created an atmosphere filled with fear from approaching him and a most serious incident — deleted large amounts of code that his team members had been working on for the past year and a half. I will present one example in greater detail.
During assignment planning, he received an assignment to organize the project’s GIT. Up until that time, the GIT was a great big mess that consisted of two different project versions. Since the team lead (let’s name him Steve for the sake of the example) was the most experienced senior developer, we all agreed it would be most effective if he’d gotten the assignment, since it would’ve taken him the least amount of time and efforts. After a month, in which we’d held a few status meetings where he spoke of his progress, we found out that not only did the GIT stay exactly the way it was, but he also ordered his team members to develop upon the older version — thus creating unnecessary integration problems. Everywhere else — a worker like that would’ve been immediately fired. Unfortunately, I could not fire him nor take any other disciplinary measure against him.
This story with Steve reminded me of an employee I had as a regional manager for a non-profit organization a few years back. Let’s name her Suzy. As a regional manager, I was in charge of managing my branch managers on the one hand and on the other hand — developing our region’s community and business relations. Suzy was one of my employees. In time, we’ve realized being a branch manager lead her to have a strong thirst for power. She took on many responsibilities, treated her branch co-managers as her employees, disrespected her co-workers and basically bossed everyone around. No one had the guts to stand up to her for years, because it was a voluntary job, and we didn’t want her to use her rage against the organization. Every action had to be taken very delicately. I’d tried changing the atmosphere, adding bonding activities and a few other approaches. When we saw nothing changed her behavior, I decided to take more drastic measures.
I started actively managing their meetings and assigned more responsibilities to the other managers. I reduced the amount of power she supposedly had, by letting the other managers talk to the contacts she usually contacted. My response to the problem was decentralization, which ultimately led to a healthier work environment.
Going back to Steve — the situation was much more extreme and involved one of the company’s crown jewel projects. It was clear to everyone Steve, much like Suzy, had a thirst for power. He always requested more people for his team, It didn’t matter to him what happened next, he just needed to be everyone’s boss. At management meetings, he had to cancel out every idea but his own, and he was always so stubborn he never really listened to his peers.
Since I could not fire him, but could not keep him either, I started looking for a different position for him, far from my group. Simultaneously, I started decentralization. I gave him and his team fewer responsibilities and every new group member was forwarded to one of the other two teams. Throughout the process, I gave him performance feedback, hoping his behavior would change. His stubbornness and thirst for power prevented any change, and when he felt his power was slipping away he got angry — and so we’ve reached a turning point. At this point, Steve and I finally had a shared interest. He wanted to seek power elsewhere, and I wanted him to seek power elsewhere. I knew he was one of the group’s many setbacks, but I also knew that dealing with any other setback before I got rid of him would be futile.
Peter Drucker once said: “Management is doing things right, leadership is doing the right things”. This thought is what kept me going in the direction I believed was right. I saw in my mind’s eye an effective software group, and I knew I had to work very hard and convince many people I was going in the right direction — in order to accomplish what I’d started. I chose to fight instead of to comfortably sit in my office and watch the group suffer defeats.
To make a long story short, I got rid of Steve, he moved to another group, and I began mapping the faults and behavioral patterns I was looking forward to dealing with.
The technological gaps, lack of flexibility in the organization, creating a professional identity and returning the group’s motivation — in the following blog posts, stay tuned :)
Part 2- Overcoming a Technological Gap — a Horrible Circumstance or a Creative Adventure?
