How I started the process of healing a dying software group
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 story, 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 blog post, I will present the group’s background including a few major failure points which occurred in my group — and which 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 theirs and the company’s time?
The more hours I spent at the office, the more challenges I 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 could 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 let the group’s already bad reputation 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 up 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 got the assignment, since it would take 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 realized that 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 that Steve, much like Suzy, had a thirst for power. He always requested more people for his team, and 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 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. As we are an R&D group, I started with the technology.
Overcoming a technological gap — a horrible circumstance or a creative adventure?
My next step was to figure out how to overcome technological gaps. When I say technological gaps, I don’t mean switching from Java to Node.js, oh no. We’re talking here about obsolete systems, ancient coding language (worse than hieroglyphs, trust me on that one), an impossible coding environment, no coding methodology, plenty of spaghetti code etc. The systems were implemented in such a way that there was no possible hardware upgrade without just writing everything from scratch.
I began solving each problem separately. I found several solutions to each problem and began prioritizing. For example, the coding environment issue. The system’s coding environment was so old, that even the company that designed it had already been shut down for many years. It was designed in a certain way that even the simple things were in fact very counter-intuitive.
The compilation process, for one, had to be done very carefully. In order to compile one file, a programmer had to find all the files that were affected by it, all the files it might affect and files that are somehow related to it. They needed to find all these files manually, and run them through some other processes, and then when that was finally over with- they needed to wait for a few hours for the compilation to be complete. This was the least of all problems; therefore it was the first issue to attend to.
After massive research and thought, we found an elegant solution, that was immediately applicable. We found a way to automate the previously manual process through a third party application. However, an easy compilation was not the main goal here. My goal was to target all the faulty infrastructures, find and implement a simple solution, yet constantly remind the client we needed more budget to solve the more serious infrastructure issues.
This proved to be a path worth pursuing, since each problem we’ve solved uncovered more issues concerning the architecture and design of the system. This project was doomed the moment the papers were signed, but I hadn’t given up hope.
I started sniffing around, trying to find an interesting project related to our system. I found a project that could solve a very serious problem that we could add to the main system.
This decision provided two things: first, the client understood there was more potential to the group than he had previously thought. And second, that we could add infrastructure upgrades as a part of the new project’s budget.
This had more value than just money — the developers began feeling the new spirit, they felt more needed, and they began working with extra willpower on infrastructure projects, since they knew it was meant to serve a project the client believed in. This led to an effective work environment, where people felt more productive and felt more inclined to share creative solutions.
At this point, you might ask — where is our DevOps team?
Well, to tell you the truth — there was no designated DevOps team, nor was there a QA team, a product manager, a proper project manager and so on. We had to rely on ourselves and to be completely honest — but it was better that way.
In my opinion, distributing DevOps responsibilities among team members is more efficient and leads to better and faster results instead of depending on an outside team to come and rescue us from poor infrastructure. By sharing the responsibilities, I made sure that when integration and deployment time came, my group members would know how to deal with issues. By integration time, they would have come to a point in their research of the code and its behavior where things made sense. Another positive outcome was a shared interest in succeeding, leading to better teamwork and shared efforts.
Each third party application we wrote made the people stronger. They felt committed to the project and wanted to do whatever it took to make sure the system was approachable — for them but also for the next generations.
One of my developers began showing unusual expertise in DevOps related projects. I began quietly grooming him for the position of DevOps team expert. He was always excited to research the system’s code, to write manuals, to suggest improvements, to explore various solutions, to help others. He was a great DevOps mentor, our go-to guy.
Suddenly there was hope. We began solving one infrastructure problem at a time. After building a few relatively small helpful applications, we could embark on an end-to-end solution to something big.
One of our big infrastructure projects was to change the work environment from the old obsolete one to the beloved Visual Studio. This project had been postponed for many years because of low prioritizing. Since we drew infrastructure on our flag — this topic now became the top priority.
This project was the perfect study case. I wanted to prove that my group was both professionally capable and had fuel to see a massive project through. These things were very important to me since the group has never released a version and people outside the group claimed that the programmers were unprofessional.
My thesis was that when a manager creates an environment where every effort is put in order to reach one major goal — people would work hard to reach that one major goal. They will research, they will talk to experts and they will find a way.
The first aspect I was trying to prove, through the new environment platform porting project, was that the group consisted of programmers who had a passion for their jobs. Since they began working on the project, it became very clear in a very short amount of time that they had large amounts of fuel and passion that were just waiting for the right time. They had tons of energy and they put their souls into the project.
My developers began researching, came with different solutions, coded day and night — until we decided on the proper architecture and design. This was not an easy project and we began working on it from point blank. Reviewing the code, throughout the process, made sure that programming skills were not a problem — this cleared out the second aspect of my thesis.
This project’s success had opened the group to a whole new dimension. Their professional self-esteem has begun its restoration process, and they were now very eager to prove themselves worthy to other clients.
I felt improvement, but it wasn’t the group’s time yet. They needed to fill some of the other holes they had fallen into, now and again, over the years. They needed building and empowering. We needed proper marketing, and effective software group marketing comes with, believe it or not, good software products. We needed to work on development methodologies and coding standards, on proper product management and on project milestones before we could show anything to anyone.
Overcoming the technology gap was a difficult step. It demanded many sacrifices from each group member, but it was necessary when it came to leaving the vicious zero-products cycle. It was necessary for improvement and for the upcoming products we were going to sell our future clients.
What is a group’s identity? How do we define our group and how do we create an identity when there is none?
All this and more in my next blog post. Stay tuned :)