In 1965, a brilliant psychological researcher, Bruce Tuckman, came up with what became known as Tuckman stages of group development. These stages describe the distinct phases that a group working together, or in other word a team, goes through as they get more effective over time. The phases (or stages) are Forming, Storming, Norming and Performing. Each stage exactly reflects what it’s name means. Tuckman stages of team development became a hit with leadership circles. Most managers who went through some form of  formal leadership training know about Tuckman stages in one way or another.

There are tons of articles & papers on Tuckman stages, so I have no plans to re-explain them with a twist or anything of the sort. My plan for this post is to simply offer some insights, from my own professional experience, into the ‘little things’ that can help get a team to crack the performing stage, which is obviously the nirvana state for a team. This is the stage where the team functions as a well oiled machine.

A while back, maybe a year or two into my initial foray into engineering management, I felt like I was on top of the world.

By then, I helped build an engineering team from almost scratch. The team was highly functional, we delivered products, published popular internal papers, built a resilient roadmap, and even expanded to several offices. I found myself meeting with the higher ups more often, getting consulted on cross org initiatives, and hearing some praise.

I look back now, and I see there was a non-trivial element of luck that enabled this. I was lucky in two significant ways. First, the team I was allowed to lead was very critical. Second, the engineers & the leaders who decided to give me a helping hand were beyond competent.

One day, as I was basking in what I thought was a great success, my leader at the time asked me a simple question.

“What is your continuity plan?” She said

This gave me pause, and it got me to see the team reality with much more clarity.

I realized that we are functioning because we are all running on all cylinders, with little to no room for error, and were lucky to not hit walls early on. We were brute forcing our way to delivering projects without fully internalizing what led to success & how to make it repeatable. We were in a house of cards situation, where if any card tumbles, a dominos effect will ensue, taking away our ability to execute. A card tumbling could simply be a team member taking a leave,  a partner team slowing down, or even some surprise bug. This was definitely not a ‘performing’ stage.

On further reflection, I started to consider the question of what if I am the one who goes on leave, decides to work elsewhere, or even gets promoted? These scenarios are usually tucked under the “what if I get hit by a bus tomorrow?” scenario. Would my team be able to continue functioning productively till I come back? Or maybe till my replacement takes over? Who should be my replacement even? Should it be my tech lead? One of my peers? 

The truth was, I didn’t have an answer at the time that would have made any sense. That was the day I grasped the true meaning of what the performing stage of a team represents, and we were simply not there. Below are some of the techniques my team & I have developed to reach the performing state. Some of these techniques are useful for newer managers, others will be more useful for more seasoned managers. In all cases, I don’t believe in absolutes, so what works best for you might be a combination of some of the techniques below along with your self developed techniques based on your own situation & environment. 

The Why

If each team member truly understood the why, and how their work fit within the company, they would be able to make the right snap decisions when snap decisions are needed. Without consulting me or others. This in turn can save very precious time, and prevent me or a small number of team members from becoming roadblocks to every single decision that needs deciding.

Any manager worth his or her salt knows that sharing the why is very important. However, not many dive deeper into the meaning of this beyond having a quick conversation with their reports about why their particular projects are valuable to the company. For example, saying that “Your work will help save costs for the company” is nice, but not enough to make your engineers more effective on their own.

So, what does it mean to explain the “why”? It does not just simply mean to tell your reports why Their work is important. It also means to make them see how their projects map to org goals, workstream goals (if your org is big enough to have one), and ultimately to company objectives. It means to  share with them who the key stakeholders are in this work. The less senior the engineer is, the less he or she will be exposed to this without your help. This equates to saying something like this: “Your work will help save costs, it maps into goal/objective ‘xyz’ in our roadmap, which in turn maps into org initiative goal/objective ‘abc’. This is being driven across the org by ‘Jane’ the TPM & is supported by ‘Joe’ the product manager. Our project will capture the number of CPU cores not being utilized, whereas the work being done by ‘Jim’ from the capacity planning team will take this data and convert it to dollars”. 

This expanded context will not only expose your engineer to the bigger picture, but would also give them enough knowledge to make decisions on the fly. This includes who to approach for updates/questions other than yourself, or your tech leads. Simply put: The more your engineers understand how their work maps to everything else, the more they will be capable of unblocking themselves; especially when it comes to project decisions at their level.

Tech Leads

A second key aspect of building a highly functioning team is nurturing tech leads as much as you can & as early as you can. If you take a team with established tech leads, then lucky you! Otherwise you’ll need to groom & establish a TL or two for your team. If you are building a team from scratch, your first tech lead is likely your very first hire or transfer.

A good TL doesn’t just assist with complex project work, or drive cross collaboration within & without. Even though both tasks are obviously critical pieces of the puzzle that is their work! A good TL should also have enough vision ahead, to be able to assign new tasks & projects to his or her peers. When you start as a manager, you do a lot of this yourself. However, as you grow & evolve your team, You must have strong enough TLs to carry that mantle. Otherwise, you will never evolve your team enough to get to the next step in your leadership journey & will continue to be a first line manager for the foreseeable future. 

A new manager may assume that someone aspiring to be TL is also aspiring to be a manager. This is actually not true most of the time. Many folks who rise to become great TLs are rarely interested in management. They have neither the patience, nor the passion for it. This means that when you look to expand your team, don’t assume that your TLs will become your new managers. That is unless they explicitly share interest in a management career.

Internal Processes

A third driver behind turning your team into a well oiled machine, is the maturity of your team’s internal processes. A healthy team needs some well functioning internal processes to run with satisfying efficiency.

Let’s take onboarding as an example. Usually, there is a corp or org wide process for new engineering hires. This is where they learn The fundamentals, and the lay of the land so to speak. This does not waive the need for a working onboarding process that is internal to your team though.

Why? Because an org wide onboarding will not teach your new hires how to navigate the particular code or technologies owned by your team. In the case of a software team, it will not teach them the main packages, the internal architecture, or even the key external stakeholders for your team. Your internal onboarding process should be what teaches your new hires these things. Obviously, your internal onboarding Process should always be sequenced after all corp or org wide onboarding activities.

Another example of internal team Processes would be the interviewing Process.  If you work for an enterprise that consolidates the hiring & interviewing processes, then you don’t have to worry about that, because you just get plugged in whenever a successful candidate is available. However, if you work for an org/company where your team has to do the interviewing in order to hire, then a unified team interviewing process is essential.

The interviewing process that worked for me covered all the practical aspect of interviewing, like number of interviews, the names of interviewers, a selection of interview questions per topic, and even what to tell the candidates when they ask the recruiter about how to prepare.

Documentation

A fourth key to a performing team is documentation. I found it very rewarding to invest my engineers time & mine on sets of well maintained docs that cover all aspects of our work & processes. These sets include design docs, Training docs, onboarding docs, internal runbooks, and more. Up to date docs save everyone’s time as the team grows. It removes the time strain of having to explain things again & again. 

To be honest, it is challenging for an engineering team to keep sets of well maintained docs. Most engineers are builders; building things is usually what they enjoy spending their time on with varying degrees. In order to get your engineers to spend some of their precious time writing docs instead of code, you’ll have to get creative.

Commanding your reports to do so is out of the question. First, it is not good management to rule with fear or a decree. Second, you’ll get mediocre work at best.

I learned to employ several techniques to get engineers to write & maintain docs. First, I’d not put it all on one person. Instead, I’d rotate the responsibility based on who has recently done heavy coding tasks, so as to keep a fair system. Second, I’d get new hires, or engineers on the cusp of promotions to focus a bit more on documentation. For new hires, this allowed them to internalize what they are learning faster. Whereas for folks close to promotion, it gave them the opportunity to shed more light into their contributions, allowing  them to shine a bit more. This is because their names would go on the docs as owners , drivers, or reviewers.

Knowledge Sharing

Another critical building block of a well oiled engineering team is the concept of knowledge sharing. Knowledge sharing in an engineering team entails folks sharing knowledge of what they built & learned on a regular basis, shortly after they acquire said knowledge.

One might say: “Isn’t that what docs, or team onboarding processes are for?”. The answer is yes and no! There is nothing that will substitute team members talking to each other, sharing what they built & learned in a regular basis. It strengthens team cohesion,  collective knowledge, as well as overall team morale. From a business standpoint, it elevates the effectiveness of the team, as several members become capable of executing the same projects. This protects a bit against holes left by attrition.

Documentation, on the other hand, is what then mirrors this knowledge into a consumable medium. This medium can be shared later with new team members, and external stakeholders. Examples of external stakeholders would include other tech leads, product managers, technical program managers, and even leadership when necessary.

Project Groups

As your team grows, you’ll find it expanding to cover a wider scope that is not as easy anymore to share with every single team member on a frequent Basis. This is when you groom subject matter experts, combined with squads (or project groups). It is not uncommon for highly evolved teams that are on the verge of splitting & forming a nascent org, to contain several subject matter experts combined with a number of squads. Most experience managers have gone through this at some point in their career.

Subject matter experts are not necessarily tech leads. Tech leads help with technical direction of the team, the key projects, and the critical cross functional relationships. They also possess deep technical knowledge in the most critical areas of the software supported by the team. However, when the team’s scope is expanded -hopefully organically- over time to a fairly large size, the TLs can’t absorb information on everything the team does or owns.

Subject matter experts understand one area deeply more than others. For example, in my case I had SMEs who deeply understood data science integration projects. Other SMEs deeply understood part of our software stack more so than others, or deeply understood external services that integrate with our software, and so on.

Someone may ask: “well, what happens if an SME leaves?”. Enters the concept of squads or project groups. A key part of a healthy team growth, is the expansion of team objectives & key results (OKRs). If your team scope & objectives are not increasing, do not hire more people and grow your team just yet. Or else, you will find yourself in a bad spot when the next economic downturn rolls along.

As a side note, you bear some of the responsibility when it comes to expanding your team scope. Do not expect it to be handed to you. Whatever scope gets added to your team though should make business sense, and approved by your leadership. Avoid adding scope for the fun purpose of building your own mini Kingdom. You will not like what you’ll have to do later when times get tough. There is also the tried & true fact that fat teams are slow & sluggish. Anyways, that’s a whole other topic.

So as your team grows, you’ll need to start dividing your people into project groups or “squads”. This is actually a popular approach in the software industry. I see it sometimes as one of the evolutions of pair programming. Each squad can own a number of objectives & Projects. Each Squad hosts two or more engineers.

When you build squads, you Combine SMEs with knowledge sharing. A squad would have the SMEs in one area. If one of them leaves, you still have the rest of the squad to execute in this particular area. The objectives owned by squads add up to form the whole team objectives. In a healthy environment, squads evolve to birth new teams, and your original team evolves to form a mutli-team org.

Successors?

A relevant topic that is worth tackling here, is the subject of successors. This is not another technique to push your team to a performing state; it is ,however, an organic need for teams who have been sitting in a performing state for a while. That is especially true if your parent org is healthy and growing. 

Usually, successors are only considered & groomed if it’s for someone is very high up the food chain like the CEO, an SVP, or if someone is about to exit. Some managers may shy away from grooming potential successors, so as to avoid the drama of building up folks who may be gunning for their Jobs.

My experience is that if you are a high performing manager, then grooming a successor can help further your career along. There are several reasons for this. The most common reason is the fact that in the absence of a successor, your leadership may get reluctant when it comes to promoting you to move to higher roles. From their perspective, why rock the boat? Especially if the boat is currently floating with ease.

Another reason is that you’ll likely have folks in your team interested eventually in pursuing management. If you don’t provide them the support & the training, they will leave you for some other manager who will. Obviously, they can’t be all your successors at the same time, and they also can’t wait for you forever. In these cases, you offer them support to transition as managers of other teams with open headcount, because that is simply the right thing to do.