One of the most common systems engineering problems that arise in large projects is the tendency of non-engineering managers to discount or minimize the problems that exist. However, to a great extent, managing a team of engineers and technologists is no different than managing a team in other specialized areas. As challenges and systems engineering problems arise, it is important to remember that positive change does not happen overnight. Groups develop their own cultures and people show up based on habits that have taken root over the years. Habits die hard and breaking unhealthy cultures is a non-trivial exercise that takes both time and effort. A second piece of good advice is to seek guidance from others who have been where you are. Take a look at how other engineering leaders handled problems depending on what you are experiencing. While this may sound easy, it is all about. Corrective actions should take into account the specific people in your team. Use the approaches of others as a guide but remember that your impact will vary depending on the personalities and context. With these points in mind, let’s look at some general guidelines that are effective in addressing performance issues in technology teams as well as solving efficient systems engineering problems.
When you encounter a systems engineering issue, the first step is to identify the real problem and then shed light on how that problem may be related to others. It is important to be clear about the root of the problem to find a real solution. Once the real issue is isolated, I suggest using the “Hot Stove” principle: you can either warn the child walking towards the hot stove that his hand will burn if he touches the stove or let him touch it and experience the pain. When it comes to mitigating risk, the first alternative is the best, and low-performing workers need and deserve clear warnings about where their actions are going, along with the consequences. It is the job of the engineering leader to be clear and to deal with situations head-on. Engineering managers who do not want controversy tend not to be managers for a long time.
Further, engineering problem management can be divided into two different groups. There is reactive problem management, which reacts to a problem when it occurs. The other is proactive management. This is the act of locating and resolving an issue before it results in an incident or problem in the system. Problem management falls under a larger umbrella of technical processes (decomposition includes the following processes: stakeholder requirements definition, requirements analysis, and architecture design. Realization includes the following processes: transition, validation, verification, integration, and implementation). Engineering databases with troubleshooting procedures often include problem management, event management, request fulfillment, event management, and access management.
Incident and problem might seem like similar words, but in the realm of problem management, they have different meanings. According to standard engineering procedures, an incident refers to an unplanned interruption to a service or the failure of a component of a service that hasn’t yet impacted the service. A problem, on the other hand, is made up of more than one related incident, or those that have common issues. Therefore, a problem is more severe than an incident. It requires more follow-up. A problem is not an incident, but an incident can create a problem if it’s recurring. Managing an incident means fixing it and restoring the system as fast as possible. A problem is resolved by discovering its root cause to make sure that new incidents don’t occur. Therefore, incident management is getting the system back in order quickly. Problem management is working to find and resolve the underlying cause of the error that has resulted in several incidents. The problem management process can be broken down into the following seven steps: (1) Detection (problem identification); (2) Logging (historical data are crucial and precious in any problem management life cycle process); (3) Diagnosis (identify the root cause); (4) Workaround (set the technological ship back on course and reduce downtime and disruption until a permanent change resolution is available. Just be careful not to accrue too much technical debt); (5) Known error record (This is where you can go back in your historical database and look up problems when arose and see if it’s one you’ve already handled); (6) Resolution (if you have a resolution for the problem, implement it with standard change procedure and test the resolution to make sure it is working. Sometimes this process is carried out through a request for change document, which then must be approved before being implemented); (7) Closure (once resolved and tested, the problem can be closed. The final bit of paperwork is usually completed by the engineer or service desk technician, who makes sure that the details are accurate for future reference).
A successful problem management results in less downtime and fewer disruptions in the business facet of a project. It also improves service availability and quality. Problem management helps companies reduce the time they spend having to resolve problems and also the number of problems that occur. This all leads to an increase in productivity and reduces costs. The final step in the problem management journey is that it leads to improved customer satisfaction.
The knowledge and understanding of proper KPI metrics are imminent. A uniform approach is a prerequisite for the work a manager does daily. The more objective a manager can be, the more likely he is to be able to provide meaningful feedback. KPI measurements are a key tool for achieving objectivity. Project-related metrics are important for both engineering teams and managers. Upstanding managers need to be able to assess whether teams are living up to their commitments, whether individual team members are meeting their own, and so on. When it comes to discussing issues, telling someone that something is wrong is not enough. Specific examples, facts, and measurements contribute significantly to minimizing subjectivity and allowing productive discussion. KPI metrics that teams and managers typically track to assess project work are also useful for reviewing overall as well as individual performance. These may include:
· Story points committed vs. delivered
· Defect count
· Defect span (the amount of time it takes outstanding bugs to be closed, once assigned)
Especially for engineering teams, always remember that if you do not measure it, you cannot manage it, and this includes people.
Placing team members in the right roles is paramount. People are the reason firms succeed, and your team should be given the resources they need to succeed. This means setting goals, parameters, and guidelines as well as articulating a plan with achievable and measurable milestones. Feedback along the way helps minimize bumps and ensures that everyone is on the same page with expectations and deliverables. If expectations are unclear, the fault lies as much with the manager as the employee. Individuals are responsible for managing their careers and reaching their goals. Strong managers help their team members by concretely supporting their objectives. Taking an interest and mentoring team members provides many benefits. If you help your teams grow, then you will see better results. Having an organization that is structured to support two career paths is an example. In a development organization, one career ladder would be management-oriented while a second would be technical. This allows team members to advance in the organization in ways that match their skills, interests, and goals.
Active team dynamic management requires that the last alternative available to a manager is to disband the team or remove failed or obstructed team members. While this is obvious, too many managers are not moving fast enough when it comes to letting people go. Evaluating good versus bad is not just a technique. The personality and adaptation to the culture of a team must also be taken into account. When necessary, changing team members may be the best solution to a persistent team problem.
Engineering leaders are required to manage proactively and be self-aware. Being a successful manager of engineering teams requires both people and technical skills along with solid tools for assessing productivity, effectiveness, and quality. The best managers both inspire their teams and appropriately control them. They have integrity and persistence, and they understand how to get the best out of people. Successful managers ask, “What needs to get done?” and then organize activities and team capabilities around priorities. These are skills developed over time. Managing engineering teams is hard. If it weren’t difficult, it wouldn’t take professionals with years of experience to do it.
Georgios Ardavanis – 18/09/2023