Software Development At SAP: Development Manager

Every software development project has its own challenges. One must be completed in a short amount of time; another lacks experienced developers. These challenges stem from external factors: The time limit has been set because of the market pressure; getting 10 more developers with the precise qualifications needed is unrealistic. An experienced development manager will use a flanking strategy to mitigate these issues. They must adapt to reality instead of trying to change it.

The first step in doing so is to be aware of the properties of the project.

Each item gets assigned a probability-of-failure rate. Most important is that the combinations make sense. Obvious collisions are when a project needs to be done soon, but the company is short on resources. Or when the specifications are clear, but a large development team might create management issues.

All these none-matching combinations increase the probability of failure and need to be addressed upfront. Typical techniques include a phased approach where only the base functionality is developed – everything else is a stretch goal or roadmap. Or splitting the entire team into smaller groups that are easier to handle, putting a single person in charge of putting all the components together later.

Time is of the essence

Another interesting fact is that most project constraints have a common theme: time. Time is the only resource which cannot be increased but is always required. Examples: If we know exactly what to build, it takes time to get the others on board. If we only have an idea, it takes time to come to a final decision on the design. Without management involvement from the start, it takes time to defend the project. For every item, there is a consequence which always somehow relates to time.

What is the biggest avoidable waste of time? The decision-making process. If people spend 90 percent of their time in meetings, there is something severely wrong with the process. Companies can avoid this through two different approaches.

Hierarchical

Teamwork takes time. Team members need to sync, develop their own ideas, and understand the others’ suggestions. On a more personal level, all team members have their own experiences and fears that need to be addressed. All of this takes time, but the process can be shortened if companies run the project like a ship, for example. One person sets the rules, defines what the product should look like, and the developers implement.

While this is the exact opposite of everything we learned from agile methodologies, it is the most efficient way of software development. Some conditions apply, though: It is most efficient if the person in charge truly knows how to implement the vision, if the project is small enough for one person to manage, and if the developers are mostly junior. That’s a lot of ifs.

This approach also carries a higher inherent risk. By reducing teamwork and making fast decisions, a lot of time can be saved, but any feedback loop is also cut short.

I have seen a few cases where it did work, but more cases where it failed. Some examples of what could go wrong:

• The dev manager always ignores the input from product marketing and product management teams. Soon, they get frustrated and leave the team, resulting in even less feedback being provided. The finished product solves exactly one problem nicely, but it’s a problem no customer has.
• The dev manager is an engineer who knows the project details very well. The only decision-making process in this project is to get clearance from this manager. However, because there are so many decisions to be made, they do not have time to think through all the consequences. The result is a set of functionalities, partly contradicting each other, instead of a single product. Example: The product has a validation feature on the dataflow level, and the job object holds variables for dataflows. Now a dataflow can be valid and invalid at the same time, depending on the job it is called from.
• The dev manager makes all the decisions, and senior developers have no say. The result is a decrease in motivation. Despite the head count, in terms of productivity, the manager now just has the equivalent of half a team.

Cooperative

For building something beautiful, the creative input from a broad range of people is essential. A more technology-focused person knows all the settings. If they are in charge, the user interface will be a list of input fields – practical, but it might look terrible. The product manager, as the customer’s ambassador, comes up with simple to use UIs that work – only for a single use case, though. Combining both their inputs produces the optimal solution in this case.

The other advantage of a cooperative approach is that the decision-making process is distributed, meaning it can scale beyond a single person.

I have seen some cases where it fails, however, mostly when decisions aren’t being made. For example, let’s imagine that the dev manager asks for the current state of a feature. One half of the team provides a list of advantages for Option 1, the other half favors Option 2 and backs this decision up with equally important facts. Both make reasonable arguments, so which option should the dev manager choose? If one of these two options were clearly superior, there would not have been any discussion in the first place. Such a situation needs a management decision – any decision is better than no decision, after all.

A lack of decision making is the root cause of many failed projects. Some examples of cooperative approaches gone wrong:

• The dev manager doesn’t get informed about roadblocks. The team culture punishes the messenger, and no final decision is made.
• The dev manager has a trusted advisor. Because of their good relationship with the manager, this person’s proposal has been chosen, regardless of the downsides. The product might thrive in areas this person has a good knowledge of, but suffer in all others.
• The dev manager asks for a list of pros and cons – the results are equal. They are afraid of making the wrong decision, and more unimportant facts are added in the pursuit of finding a solution.
• The dev manager tries to be loved by everyone and shies away from making hard decisions.

The benefit of modern Scrum-based software development (if used correctly) is that it addresses all these issues.

Adaptive

These are the reasons why it is imperative for the manager to adapt their management style to reality. Depending on the people involved, the available time, the size of the project, the corporate culture, the history of the team, etc., different setups and decision-making processes are optimal.

A dev manager explaining how they tick and asking all team members to adapt to their style should do their homework on what the role of a manager actually is: To create a productive working environment for motivated and self-sufficient team members where no manager is really needed.