By Victoriya Kalmanovich

This series portrays my experience as an R&D group leader of a group that has the same behavior as a failing startup. In my last two blog posts, I’ve presented a short background regarding the developers and the technologies. This blog post will deal with the vague definition of a group’s identity.

In my last blog post, I portrayed an image almost too good to be true. An image of a productive software group, full of energy and hunger for projects. I knew I must look away from newly gained success and only into the problems, however unfortunate that made me feel.

On the one hand, I felt the need to present the milestones I’ve created to restore some kind of productivity. I wanted to show the boss all the recent successes — the coding methodology, working regulations and other concepts we’ve begun implementing. I wanted to present the training concepts and procedures we’ve established. I wanted to present the strong cooperation I’ve led with another organization. This cooperation granted an opportunity to combine the organization’s knowledge pool and create better professional training for my group. On top of these, one of our projects was accepted to an acceleration program. I really wanted to show that off as well.

But I knew this image would soon fade unless I continued targeting the main issues. The primary issue was this next hard truth. The group didn’t have a strong basis and it was just a matter of time until it might collapse again. I identified it as the group’s lost identity.

What is a group identity?

When we reach a point in life where we seek our unique identity we look into various questions. Where am I from? What is my heritage? Who influences me? What’s exciting for me? What’s the reason I wake up in the morning? These questions helped me shape my personal identity both as a human being and as a leader. The same process happens one way or another in every organizational structure.

Defining a group’s identity must happen the moment a manager takes the reins. They must look at the group’s responsibilities and define each group member’s position. It clears many things up. It provides clear borders regarding the manager’s and the developers’ responsibilities.

This process must occur at the group manager’s level and even higher. It is rare that a complex organizational understanding such as an identity can depend on the team leads’ scope or lower. It is also unfair to the team leads, who already have enough on their plate.

As you may recall from my previous blog post, I talked about the vicious zero-products cycle. This cycle started somewhere, so I started retracing the group’s steps. I realized that the moment the last official product version was released was the breaking point. This was the point where there was no clear view on what the group’s main objective was, what was its purpose and what was the product it was responsible for delivering.

What was the main objective?

The main objective was software and system maintenance for a very complex system. In order to perform software maintenance on such a large amount of code, a developer must work on the code. The developer must understand it and get to know its genius functions, but also its inherent faults and flaws. The developer must feel the code. They can only gain this feeling through massive research and deep understanding of procedures within the system.

In my view, it is impossible to maintain the entire system simultaneously, as a result of a small number of maintenance dedicated developers and a very serious lack of knowledge. So I declared that maintaining specific domains every year was good enough for us. The alternative would be scattered maintenance that would only lead to more gaps in the long run.

Let’s look at a simple example such as inserting an image on a screen. This is easy in modern systems written in readable code that follows proper coding methodologies.

In our case, to insert a feature, the developer needed to follow more complex steps. They would research the entire screen’s code and the entire code of screens that might be affected by the change. It might take up to a month of research. After the research would’ve developed some conclusions. They would try to decipher the relevant piece of the system’s architecture and find a few ways to implement image insertion.

In parallel, and this is the important part, the developer must document EVERYTHING. Every difficult method. Every process they discover. Every architecture or network insight they have. Every unusual phenomenon and its investigation all the way to its origin. This is crucial since the existing documentation and most of the written code are barely readable.

The objective seems very straightforward, but regulated documentation and code maintenance is not the only thing that defines a group’s identity. The group has to have a purpose. Our purpose went missing.

Where did the purpose go?

At some point, software maintenance was performed under no regulations and slowly went out of the professional focus. What started flowing instead were side projects. Side projects became the main objective. Whenever a client approached one of the teams, in need of a quick fix, the group would pivot in that direction. People were working on side projects for the sake of working. The difficult yet crucial maintenance was completely abandoned.

When I started my position as group leader, almost every group member told me they didn’t know exactly what the group was actually meant to do. They felt they had no real goals when they came to work. Side projects scattered the purpose.

Why do we sometimes need to manage our clients?

A software group cannot blindly do what the client wants. Especially when the client changes their mind frequently. For example — back when I was a software developer, my team and I were working on a navigation project similar to “Waze”. Our product owner kept requesting changes that made no difference whatsoever to the system’s functionality. It was always a request to change button colors or move toolbars around the UI. This kept the team from making any progress for a very long time.

In my software group, the problem was on a larger scale. The group didn’t have one indecisive client. It had a few separate clients and each client pulled in their own direction. There wasn’t one integrating factor, looking at the larger picture and managing the clients and the projects. For a long time, the group worked through a queue — first client in meant first project the group developed. Therefore, almost any type of project could be brought to the group. In time the group began dealing with QA, IT and even hardware issues, rather than software development.

Retrieving the purpose, and consequently the motivation, was an ongoing process. It began with a definition — I’ve defined, along with my team leads, our projects. We’ve prioritized them in accord with our clients’ demands, thus setting a roadmap we will not slip from, as happened in the past. This roadmap indicated our objective — system’s software maintenance was declared our purpose.

We’ve added one more project to the roadmap, a second main project, related to the system but not directly. It added to the purpose since it had great unimplemented potential. I believed it would be great for PR and to enhance the developers’ belief in their own skills. This dedicated roadmap focused the teams. We knew that by the end of the year we needed to deliver two products end-to-end.

Setting the professional compass was important. The bigger problem was regaining the developers’ trust in the group. After so many years, my developers — both experienced and new — had no fuel nor will to work. After some of my scheduled one on one talks, I mapped each developer’s strengths. If for example, one developer was really good at research — I let them do the research.

After mapping individual strengths, I mapped team strengths. Some paired programming was performed in order to strengthen some developer’s self-esteem. We’ve held a professional workshop for team leads, to strengthen management abilities. I addressed the issues I picked up when I observed the programming process and the issues the developers themselves had presented.

So how was the identity restored?

By finding a definition and restoring order. We’ve defined our field of expertise. I’ve put borders around our designated projects and let no other project cross that border. Limited the issues we work on (no more hardware issues!). Made sure there was proper usage of coding methodologies and version control. Made everyone document their work. Strengthened each programmer’s strengths. Sharpened the team leads’ set of soft skills.

I targeted both professional and personal values in order to restore the group’s inevitable software DNA.

The difficulties of leading changes in an unforgiving environment, leading innovation instead of sinking and how to survive as a young female in a very ego driven male environment? Stay tuned, all this and more as the series unravels!

Part 1 — How Can Corporations Heal a Dying Software Group?

Part 2 — Overcoming a Technological Gap — a Horrible Circumstance or a Creative Adventure?

Parts 1+2 — How I started the process of healing a dying software group

Have you tried turning your software team’s identity off and on again?