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:
·
Velocity
·
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