Practical Empowerment of Engineering Teams

Photo by Chang Duong on Unsplash

Empowerment is widely acknowledged as valuable, but many resources lack actionable guidance on achieving it. In this brief article, I aim to provide practical tips for effectively implementing empowerment with teams and individuals.

Oxford’s definition of Empowering — giving (someone) the authority or power to do something; making (someone) stronger and more confident;

Here’s my definition: Empowerment involves giving teams or individuals the authority and resources to lead and solve problems using their experience and creativity.

Empowerment can be seen as the opposite of micro-management. No one likes micro-management, where individuals are instructed on precisely what they must do and then carry it out — that is so demotivating.

Empowered groups or individuals will eventually be working on solutions that they suggested, and therefore they will feel more committed, accountable, and fulfilled during this process.

Prerequisites

When a team receives a task or a problem to solve, it is crucial to ensure that they comprehend the objective, the “What”, and, more importantly, the rationale behind it, the “Why”. (not to be confused with Simon Sinek’s why/how/what, though it is closely related)

If the “Why” is not understood, the team may not relate to the “What” and may be less committed. Moreover, if the “Why” is properly understood, then the team may even be able to suggest a different “What”, meaning suggest to the higher management a different objective that will serve the “Why”.

Here’s a simple example from one of my past experiences to explain the above:

The product that my team was building was a type of lead generation tool. Product management wanted to add a few fields to the application forms to have the users feed in their location — the “What”. Why? because they wanted the users to be able to find leads in their vicinity. The development team understood the “Why” and suggested changing the objective so that instead of having the user feed in the location, the app will automatically detect the location of the user’s device.

So how do you practically empower teams?

To achieve the “What,” the team needs to find the right solution, the “How.” This is where empowerment comes in.

To practically empower the team, they should be given the required resources (time/people/tools) to suggest a solution (the “How”) based on their experience and creativity, and have some leeway to be able to work autonomously.

Throughout the process, managers must provide the following for their teams:

1. Support — ensuring that the team has access to appropriate tools, a conducive work environment, and necessary consultation when required. Collaborating with the team to fulfill their requirements and enable them to achieve their objectives.
2. Guardrails — ensuring that teams stay on track and don’t deviate from the defined path is crucial. Guardrails act as a safety measure to mitigate the risks associated with implementing the “How.” Business risks can be in various forms, including solutions that exceed the timeline, budget constraints, non-compliance with regulations, security vulnerabilities, or solutions that pose a risk to the product’s quality in the short or long term. This is where your expertise as a manager comes into play by setting the necessary guardrails to minimize business risks.

Setting the guardrails (source: Wild Africa Trek, Trip Advisor)

To solve the problem at hand, it is necessary for the team to suggest one or more potential solutions. The managers are responsible for ensuring that the chosen solution is aligned with the end goal and does not fall outside the established guardrails. Managers should foster a supportive atmosphere for problem-solving, enabling the team to come up with and implement their own solutions. This is the essence of empowerment.

The scope of empowerment

It’s important to define the scope of a task accurately. If the scope is too difficult for someone’s experience level, they may struggle even with support and proper guardrails. On the other hand, if the scope is too narrow for experienced people, they may feel unchallenged and lack a sense of accomplishment, growth, and motivation.

So how should the scope be defined?

We all know that growth happens when we step out of our comfort zone. To achieve this, the task at hand (the “What”) should challenge the team or individual to stretch beyond their comfort zone, but not too far. The degree of challenge should be tailored to the abilities and potential of the team or individual. Managers should evaluate and discuss with the team/individual to determine a reasonable limit for the challenge. The limit should define the Challenge Zone, which is just out of the Comfort Zone and below the Frustration Zone.

The scope of a task should fall within the Challenge Zone of the individual.

Empowerment and decentralized command

If you ask any experienced Navy or Marine Corps commander, they will tell you that empowerment comes naturally when you decentralize command.

Jocko Willink, the ex-US Navy SEAL officer and the author of the best seller “Extreme Ownership” (along with Leif Babin), describes this best in the first 7 minutes of this interview:

The concept of decentralized command is not new, as it has been in practice since the time of Alexander the Great.

Scalable organizations foster a culture of empowerment

For organizations that aim to scale, innovate, and keep up with the pace of change, decentralizing control is crucial. Failure to do so can impede progress and growth. Empowerment is at the base of control decentralization. Give teams the resources and some leeway to plan and operate autonomously and take a step back to ensure that the team operates within the guardrails.

Small organizations can also implement decentralized command, which would naturally lead to the empowerment of teams.

Empowerment in hierarchal organizations

Here’s how the process can be implemented in a hierarchical organization:

• Define the “What” and “Why” (W&W) — if anyone cannot understand the “Why” then (a) understand why they cannot because maybe there’s a justifiable reason or (b) refine the “Why” to make it clearer. The “Why” rarely changes. It may change if the company pivots or adjusts its offering for whatever reason. The “What” are the requirements — depending on the type of team that you are leading, it may be product requirements or infrastructure requirements.
• Each division/group manager receives the W&W, derives the “What” for each team, and explains the “Why”. (again, the teams MUST understand the “Why”)
• The sub-divisions/groups/teams will now define the How — that’s where empowerment comes in. The manager must then examine the suggested solution/s and check that it does not fall outside the guardrails and that it provides a proper answer to the “What”. If so, the manager approves the “How” plan, and the team can start building.
• As soon as managers have received and approved the “How” from all their teams/members, they may aggregate all these “How’s” into a plan which he presents to their manager, and the process continues up the hierarchy chain.

For companies in the growth stage that require rapid scaling, adopting a hierarchical empowerment approach is the optimal solution.

Enabling a hierarchical empowerment model can ensure that both teams and individual contributors are given the authority they need to excel, leading to a more dedicated, responsible, and motivated engineering organization.

A few things to keep in mind

(1) You need to let your team figure out the solutions — that’s why you hired the best people for the job so that they would find the answers, not you. It is fine to share your suggestions and experience with the team, but make sure you do not subconsciously lead them to your suggested solution. You’d be surprised how creative and diligent teams can devise solutions you have never considered.

(2) Empowerment is motivating but may have a counter effect when you have employees who are not experienced enough for the task at hand. They may find themselves dumbfounded as they haven’t got a single clue on how to approach the problem. As a manager, you should assess whether the problem at hand fits the employee’s current experience. If they lack the experience to suggest possible courses for a solution, then they are more on the learning side.

The less experienced employees are, the more time they would spend learning than solving the problems.

(3) If you have an experienced employee that comes to you and says, “I received this task. Just tell me how you want me to solve it.” then you don’t want this employee on your team. You are not hiring people just to build but also to solve — to define the “How”. Employees that need to be told what to do will drain you — solving problems requires time and concentration, and your energy and time will be drained if you cannot delegate problem-solving to your team.

“It doesn’t make sense to hire smart people and then tell them what to do, We hire smart people so they can tell us what to do.” — Steve Jobs

I hope you found this article insightful and enjoyable. If so, please show your appreciation by adding a few claps. Don’t forget to follow me for more articles on team building, software engineering, and technology.