Empowering software engineering teams

Software engineering is a creative role. As software leaders we aspire to hire great engineers who can solve complex problems. How can we craft a culture, and implement practices to support empowering software teams and pushing as much decision making down to them as it makes sense to do so? Below are 10 approaches that can be utilised to accomplish empowering software teams.

1. Be clear your objective is to empower engineering teams

If empowering engineering teams is something new to the group, you need to articulate this change. Teams need to be aware what is changing, and why it is changing. Most importantly they must understand the value this change will bring to their role. In small organisations, with well formed teams, this could be orchestrated through a simple team meeting to explain the change and being open to feedback. For example:

"Our objective is to ensure teams own as much decision making as possible as they are closest to their products and platforms. We are going to achieve this by bringing outcomes to teams, and empowering you all to own the solution. Hold us (leadership roles) accountable when you notice this is not occurring."

However, in a larger organisation with many software teams, momentum often needs to be built before wide spread change. It can be beneficial to have early conversations with engineering leaders to understand thoughts/feedback, to locate early supporters, as well as to resolve major concerns before wider communication to the group. This will ensure you have enough support from your leaders regarding the change. You can also start the roll out with a small subset of teams who are open to the change as way to build early momentum and get a few wins on the board.

2. Bring outcomes to teams, not solutions

If you're an expert in your domain, or a seasoned employee, it's can often seem easier to unintentionally direct the team on exactly what needs to be done to solve a problem. For example:

"We need to support Bitcoin as a new payment method. You can implement it into [platform x], just extend [component x] and deploy it into our K8s stack. We can re-use the existing reporting features, and the UI should be pretty similar."

You might have implemented this capability before and believe you're fast tracking the teams progress. However, instead you could be limiting the teams problem solving capacity, and encouraging a culture where they will rely on you as their manager to always bring solutions. This results in an increased risk of losing high performing engineers, and creating a team of doers, not thinkers.

Instead, practice articulating the problem in the eyes of the customer, and let the team solution. For example:

"We need to support Bitcoin as a new payment method for our customers. As a business we need to convert all transactions into FIAT (not hold Bitcoin) so it integrates into existing workflows. We have a timeframe of 2 months to deploy a PoC."

After this, pause and let the team digest. Then ask:

"What questions do you have? What isn't clear? What more information do you think you need?"

If you have solved this problem before, state that. For example:

"I've solved this problem in the past, which may or may not still be relevant. I'm happy to share that experience with the team now or after you have had time to do your own research."

By explaining the situation in this way, you are setting context and boundaries, and allowing the team to dive into the implementation specifics. The benefits here are you are empowering the software teams to own a solution, and investigate options that you may not have even envisaged. You are not constraining the teams thinking. As a result, they may choose to implement this capability into a new standalone service to ensure functionality is more maintainable and more easily testable. They may deploy into a serverless architecture instead of K8s to simplify architecture and reduce running costs.

3. Coach stakeholders on how to bring outcomes, not solutions

An extension of the above that I've experienced many time the past which is harder to solve, is business experts coming to the team with a pre-defined solution. These are individuals outside of your direct line of control. They may be product managers, pre-sales engineers, knowledgable domain experts etc. It can sometimes be presented as, we signed up a new [customer X], and we need [API X] to be adjusted to have new fields [a, b & c] to satisfy their requirements, we have told them we can implement it before they integrate. 

These requests are typically not malicious in nature, however, can be problematic and time consuming to solve. Stakeholders tend to do this because they genuinely feel like they know the right solution and are saving the engineering team time. However, what they are missing, is software engineering teams can take a holistic view and more than likely solve the problem using an alternative approach. This alternative approach could be made relevant to all customers, or be solved in a more maintainable way to reduce technical debt.

Below are 3 approaches to coach stakeholders to bring outcomes to teams, instead of solutions:

• Coach stakeholders on how to bring outcomes to teams
• By actually investing your time to run training sessions to coach stakeholders on how to bring outcomes to teams (coupled with the 2 points below) will create significant process. Explain how to define an outcome, the benefits it has to the team, and importantly to them as stakeholders.
• I've found that you need to run these sessions continuously throughout the year, especially when you identify stakeholders are reverting back to old habits.
• Template out how to bring outcomes to teams
• Bringing an outcome to a team requires a stakeholder to think about the problem they are trying to solve. By defining a template on how to document this in a succinct way can allow a stakeholder to quickly define
• Document a DoR (Definition of Ready):
• A well documented DoR can clearly articulates how an item of work should be presented to a team and in a format the team can work with.

4. Define what success looks like (how will the team be measured)

With more empowerment, comes more responsibility. This requires teams to understand how they will be measured on the success of their work. This could include a combination of:

• A specific scalability metric is met (eg: TPS for an endpoint or service)
• The solution brings the team 1 step closer to an architectural target state
• The solution must be less than a specific monthly cloud hosting cost
• It must meet a specific reliability or redundancy measure (eg: can support 1 datacenter going offline)
• The work needs to be delivered within a specific timeframe

Whichever measures you choose, it is important your measures are defined and communicated to the team who will be owning this work.

5. Be upfront and transparent on boundaries

Boundaries and constraints always exist, it is your role to communicate them to the team early. Delaying will almost always cost team cycles in re-solutioning, or re-developing. Boundaries to think about could include:

• Is there a specific technology that needs to be used?
• Are their resource constraints in another team that need to be worked around?
• Are there specific internal/external platforms/APIs this project needs to interface with that have rate limited thresholds?
• Is a specific platform being deprecated in the near future that teams need to be aware of, so as to not make unnecessary improvements to?
• Is this a short term solution that will be replaced in the near term, hence not requiring teams to architect and implement a long lived solution?

6. Be transparent on known timeframes

There is nothing worse than empowering a software team to solve a problem, only as a leader to simply make the decision for them 2 weeks later when they have missed an unknown deadline. This will almost certainly erode trust. As a leader, it rests on you to clearly, let me repeat, clearly, articulate any known deadlines that exist when briefing your team. You should communicate if a deadline is a hard deadline (eg: marketing campaign launch), or soft deadline (eg: an internal deadline that could possibly shift).

Even if deadlines seems too short, still communicate them to the team. This doesn't need to represent a negative, it can be used to allow the team to solve a short term tactical outcome to meet a deadline that cannot move, while working on a longer term solution without the added time pressure.

7. Evangelise and drive end-to-end ownership

Ownership of a product, a user journey, a platform, a business domain is in my view fundamental to empowering a team. A team needs to be accountable for as much of the SDLC as makes sense in a specific organisation. This represents teams owning their software architecture to development, their testing to deployment, as well as supporting their products in production.

When teams have end-to-end ownership, it encourages them to continually improve their platforms and processes as they know the buck stops with them. They are the ones who will be woken up at 2am if the application crashes, they will be the ones who will have to resolve technical debt due to a decision made in the solutioning phase, they will be the team spending effort manually deploying an application. These risks all work as motivators to deliver scalable, maintainable and reliable products into production.

8. Provide teams the time to solution to a problem

Whether it's the team, a technical lead, a stakeholder, an architect, or a CTO, someone needs to invest time to understand the problem, explore possible solutions and devise a plan. I've witnessed organisations develop a perception that teams spending time solutioning to a problem is too disruptive, and would rather a role outside of the team do this work - leaving the team to "just cut code". This however, goes against empowering a software team to own their products and platforms. When teams solution together, they understand their products better, which makes future solutioning more efficient. It also encourages knowledge to be spread amongst the team, not held with a specific individual. Approaches to provide teams time to solution can include:

• Encourage teams to leverage spikes. Spikes are used to provide time for teams to look at multiple solutions, explore in more detail and ultimately arrive at a more accurate next step and work effort estimate. Word of caution, in general, a spike should avoid creating additional spikes for teams. A spikes output should be a work effort estimate. Spikes should also be time boxed.
• Encourage Proof of Concepts when there are too many unknowns. It is advisable to time box PoCs and have clear outcomes of a PoC.
• Run team solutioning sessions (or solution review sessions), and encourage team members to prepare by bringing potential solution ideas to the group

9. Ensure teams have the right skills and roles

Although any team can be empowered, to setup a team for success you need to ensure the team has the right skills within the team. Every team could have a different makeup of skills and experience based on their remit and the organisation. Areas to think about include:

• Do you have the right balance of graduate to senior engineers within the team?
• Do you have the right skills needed within the team to satisfy QA as part of DoD?
• Do you need a dedicated role for cloud infrastructure in the team?
• Do you have experienced individuals who can guide in complex software architecture decision?
• This doesn't have to be a software architect, perhaps a principal engineer or staff engineer
• Do you have product management or product ownership within the team?
• This can be matrixed in to avoid organisational structure changes

10. Keep your hand on the pulse

Ultimately as a software engineering leader you are accountable for your teams effectiveness and delivery. Just because you are empowering teams, doesn't mean you can sit back. Your roles is to be aware on when your team is spinning wheels, becoming distracted, or solutioning to the wrong problem. Your role exists to jump in and provide guidance, be there to help unblock, be a decision maker when teams are in deadlock, or sometimes just connect the right people within the organisation. Below are 5 techniques that can be utilised:

• 1:on:1s: You will often hear about blockers or frustrations in 1:on:1s without even asking. However, if not, always probe just incase your team member is holding back
• Attend demos: End of sprint demos, or product demos in general are a great way to stay in the loop in a casual environment. If teams are not running demos - encourage them to!
• Show a genuine interest: Being a leader that is genuinely interested in your teams projects (typically by just asking questions), will craft an environment where members will more openly discuss what is going on in their day-to-day.
• Follow relevant JIRA boards: Replace "JIRA" with whichever application the team uses. Following status updates on JIRA can provide you great intel on project statuses in an asynchronous way.
• Follow the documentation: Most teams use a wiki or similar. But following the relevant pages/spaces you will often be able to stay up to date on high level solutions and architectures. If you aren't noticing documentation, this may be a red flag to begin asking questions

Building a culture of empowering software engineering teams is a rewarding opportunity. It will allow you to scale your team and your role as a leader within the organisation. If you found this post useful, check out my book "Leading software teams with context, not control" on Leanpub as well as other online stores like Amazon in eBook or print format.