How to Make Software Team Deliver More, Faster and Better #1 - The Team Toolset

Every engineering manager, VP or CTO demands their teams to push for more - quicker delivery, more features and with better quality. On the other hand side the guy with the project manager hat can simply laugh - up to those the delivery is a simple math and a balance between the scope (features, the More), the time  (the Faster) and the Better (or the Worse, say - the quality). Based on my experience as an engineer and an engineering manager I still think that there is a big box of tools that can be used to break the project management triangle and simply push things further - for more, faster and better. In the given article I will start with toolset#1 - the team.

Managers do not deliver themself, they deliver with their teams. So, the goal of the engineering manager is to make sure that their team deliver. And the toolset that you have is as follows:

• Clear goals and priorities
• Transparency within the team
• Communication
• Decisions
• Roles and responsibilities
• Team morale
• Team dynamics
• Team culture

Set Clear Goals and Priorities

In order to achieve a particular goal you need to know what it is. If the team needs to deliver for a particular achievement then they need to know what it is. Easy and obvious, right? Not exactly. Setting a clear goal and set of priorities is not just one sentence in the daily meeting, nor a one-line-phrase in a mail. As a leader, you need to provide proactive answers to potential questions that simply clarify everything around the goal - as follows:

Where We are Now: Environment and Context 

• Say, where we are now - as a company, organization and a team. 
• What are the external circumstances - either opportunities or crisis? For example - it could be AI as an enabler or as a threat, covid - as an opportunity or as as risk, and etc
• What are the limitations that we have - economic cycles, market situations and etc.

Why: The Order of Priorities

Once we know where we are we need to know why we are there - why we exist as a company and a team, what our overarching missions on the market is , what our added value is. On the bottom line we can see the opportunity of what our goal should be - exactly the what. Not just that, the answer to the Why provides a clear list of the ordered priorities we are having ahead of us. Every leader should be in the position to say why the given priority list exists in the given order, why particular items are not in the list at all and why other go up higher or down lower.

What: To be or Not to be

The one-line sentence for a goal is just the beginning. The hard work of the goal clarification is made afterwards through series of answers to another question - what the final goal is NOT. All these answers are crucial and the more the better because they simply trim the scope, they clarify the interpretations and set healthy limits and boundaries with a stream lined direction. A simple explanation from the physics - basic particles move randomly (Brownian motion) however, If set in limits and boundaries i.e. given a direction they can be an immense power as it is the case with directed motion of electrons i.e. electricity.

Who - Who is going to use it

A client, a stakeholder, a company, an open opportunity in the marker. This is the Who. Simple, right. For sure not... Because, without intending to be cruel through the creation of an infinite recursion - the Who have their Where-Why-What too... and their Who, who as you guess, go in the same loop of where-why-what-who... And if you as a leader put yourself and the team in the shoes of all these answers, then you will be having a better 360-perspective of what we need to achieve when and for whom.

Transparency and Communication

Once the goal is set the team will have the clarity from the team out. As leaders, our next step a comes for making sure that the team moves towards it. Imagine that the team is a machine - all parts of the machine do their job in complete synchronization to what every other part is doing. So the end goal is the synchronization which comes through transparency and communication about it. 

I will go again with the same simple pattern again - Who does What When (How and Why). If the team has the conscious answer to this question and does not have a better idea for each of the questionable words within it - then you are good to go. If not - you need to make a decisions (next paragraph) or fix the team culture (another paragraph). The given examples of transparency and communication ensure that everyone is doing the right things the right way at the right time and order - i.e. you are not going to produce waste.

Decisions

The end goal of a decision is to provide clarity on the execution path and should come with the commitment of the team. The path to the end goal is the how and basically there can be multiple how-s. In order for the team to commit for one and single solution they need to have the proper information and constraints. Then they have to make a balanced choice between the possible options for decision. The decisions should be made with the awareness and by the whole team so that the needed transparency is on place and so that the commitment by everyone is set. Each voice should be heard, all minds should be said so that the point of view is made as wide as possible. 

Here comes the challenge between the pace of taking decisions and the quality of them. A decision by a single person is always fast however, may not be the best. Also, making all the team aware about everything is costly and timely. Therefore a practice I recommend is to grant the authority to a person or a small working group (a pair of two) for providing potential options and to present them to the team. 

So all the team can criticize the solution, can take part in the decisioning and improve the decision. On the other hand side this approach also spares time and saves the focus to the majority of the team. On the other hand side you grant autonomy to a particular individual to dive deeper into the problem and become and expert in the subject area.

Team Morale and Dynamics

So far so good - clear goal with clear execution path and a clear example with a machine. But we are people and as such we come with personality perks that may create advantages (sometimes) or disadvantages (more than just sometimes). So the risks are usually more and bigger and come with features of ego, fear, anger, lack of motivation and etc. And if any of these appears it may hit the team invisibly, cause damage to the communication, break the transparency and make uncoordinated moves of the machine. As a leader we need to mind this, namely - the way the team and individuals behave. Support them, enable them, provide them with the needed level of autonomy for making decisions, researching, breaking things in controller environment and move forward. Recognize them, price them and move on. 

However, sometimes things may not work despite all your effort, so you need to make tough decisions and this will be better for all - the team and you, even for the individual. Based on my experience so far, all cases of people that I had to let go have been on mutual understanding and respect and have always been cases of a win-win. It all sounds like a dream but it comes with continuous feedback, mutual understanding and in the end - a balanced choice between the external opportunities and the the damaged internal such. Do not be afraid to make this step - that's your job as a leader.

Roles and Responsibilities

Another level for moving a team forward is through the maximization of particular strengths in an engineer and through minimizing their weaknesses too. I personally am quite keen on the T-shape model of expertise where everyone can do everything but only ONE particular area at best. Providing experts of UI, security, quality, devops, database within the team will create:

• Focus for individuals to grow and contribute to the team
• Go-to person and subject matter experts that can boost the team expertise through their own
• Gatekeeps on particular area

Again the real world example - all football players can kick a ball and make a tackle. However, in the end you have defenders, midfielders and attackers. And the defenders are center-backs and full-backs. So what you need is a strong profile for a particular problem - the area of the pitch you want to place someone and the tactics for the given game. And so with the tasks in the team.

The Execution

There are several tools to use in order to accelerate the delivery on a short basis through execution as follows:

• War or coding room - no need to explain the term of a war room and as proven on incident basis it is quite useful in crisis cases. A similar approach can be used in order to kick out a particular progress. Actually in a similar manor the hackathon teams work and are quite quick in providing a working solution in short period of time. So why do not we make it on the backlog as well? However, keep in mind it's exhausting and can quickly burn out the team - so do not make it every day, rather let the team set the frequency.
• Focus time - nothing else is more destroying for the productivity than the distractions. 3 meetings of half an hour can kill the day through killing the focus if placed in the wrong intervals in the day. As leaders we need to ensure that the team has the needed and optimal level of focus time. Here is how I do it - meeting free days, meeting free periods in the day. Make team long meetings and ceremonies right after or right before lunch breaks on order to keep focus for the rest of the day. Make 1-1 meetings fit the schedule of an employee and make them flexible within the day so that they mind the employee focus. If the distractions for the team come from external stakeholders - make extensive documentation or tools for self service. You can also introduce duty shifts so that people on duty can shield the team to perform. Last but not least - as leaders stay in front and face first and alone each of these distractions, shield the team through their your own time and thus lead by example. :) Leaders eat last, stand till end and go first for the first step.

Conclusion

Neither of these steps however is a silver bullet for any kind of problem so before applying any of them mind the context, the team and the environment. And do not be afraid to make mistakes and fail - stay the human you are, confess them to team and commit for better.