Building Better Teams
Somehow you have ended up in a technical leadership role and the first thing you need to do is build a team. Alternatively, you are looking to grow an existing one. But where the heck do you start?
This is a challenge I am facing in my current role as CTO of Higher, a SaaS start-up in Perth, Western Australia, where we are building a platform for digital freelancers to better manage their client relationships and projects.
I have also faced this issue a few times previously in my career, and it can be surprisingly nuanced based on the company, team, culture, economy, and locality in which you are situated. Having worked at large corporates and start-ups alike, I can honestly say that there are always new and interesting problems to get in your way. However, there are also repeated themes that, if handled in the right way, will lead you down a path of success. With that in mind, this article is an attempt to condense my experiences as a CTO/VP Engineering at start-ups, as a Senior Development Manager at Amazon, as an Engineering Manager at Betfair and Yahoo! UK, and overall simply as a hiring manager into something that somebody out there might find helpful.
Personality goes a long way
Remember you are hiring people. People just like you, with their own aspirations and concerns. Walk a mile in their shoes and remember that every person is fighting battles you know nothing about.
It horrifies me how often I have to bring this up, usually because someone has abstracted the idea of a team and its members away as a “resource” or “tool”. It might not be you; it could be your manager or the business as a whole. In this case it is down to you to bring back the humanity to the process. There are no excuses.
If you treat people with respect, honesty, empathy, and transparency, you will sow the seeds of success. Do not let an over-zealous leader or business process prevent you from representing both the candidates’ and the team’s best interests above everything else. Believe me, I have made those mistakes and they are some of my deepest regrets. Be open. Be approachable. Help wherever you can, even if that help is not in the best interests of the company but is in the best interests of the candidate. Strong relationships and respect are built on these foundations.
Next we need to do some preparation…
Understand the needs of the individual
Understanding the needs of the individual is important so that you can ensure you are meeting those needs, both as an employer and as a leader. My boss in a previous role—whom I’m lucky enough to now consider a mentor and friend—liked to re-purpose Maslow’s Hierarchy of Needs for this. (He liked to re-purpose it for customer/user interactions too, but that’s a post for another time.)
Maslow’s Hierarchy of Needs is a psychological theory that visualises five layers of human motivation in a pyramid with base needs at the bottom. Those motivations are, ordered from most needed to least:
- Physiological
- Safety
- Belonging
- Esteem
- Self-actualisation
For those able to see it, here’s a visualisation:
If we re-purpose these motivations towards a person’s job, we might better specify them as:
- Physiological: The need for income to survive.
- Safety: Security of job to protect income, family, health, property.
- Belonging: Liking the people we work with, friendship, team.
- Esteem: Confidence, achievement, respect by others, respect of others.
- Self-actualisation: Creativity, problem solving, freedom to make a difference.
If you want to build and manage great teams, it is imperative you ensure all of these things are available to the individuals that make up those teams. Often I find the first three (physiological, safety, and belonging) are taken care of, but the last two (esteem, self-actualisation) are over-looked or poorly managed. These are the basis of your working culture, not what you wear, or the music you listen to, or your out-of-work activities, and definitely not your propensity for consumption of food or drink (yes, I’m talking about after-work drinking, which many people do not enjoy, or cannot be a part of for various reasons).
It is important to provide definition for team members. They should have a clear understanding of their roles, their career progression, and the differences between each stage of that progression. It is these differences that will provide them with goals for individual growth, and allow them to understand why other team members are classified they way they are. This removes ambiguity and helps folks understand the expectations upon them and others, and sets-up clear boundaries and responsibilities.
What is my role?
Understanding what you do within an organisation is the foundation of those first two layers of Maslow’s hierarchy. Any form of ambiguity here introduces uncertainty, and uncertainty leads to a lack of security and potential employee churn. To avoid that, it is important we can show all employees—both new and current—that we have spent time ensuring they step into a well understood role, and that they also have room to grow and change however they choose.
Job specifications are required for all the roles in your business so that the individuals within those roles know how they are evaluated. Their use in hiring should be their secondary value. In my experience, actually defining the difference between an entry-level developer, a staff-level developer, and a senior developer—and discussing and amending those differences based on feedback from the teams themselves—will fix misconceptions and set the business up with a better understanding of roles and responsibilities. This is particularly useful where boundaries are muddied.
There are a lot of public resources available to help with defining job roles and expectations. I’m a big fan of the GovUK Digital, Data, and Technology Professional Capability Framework amongst others. I’m also a big fan of Performance Profiles as an improved method of definition. Use these resources as a guideline to define your own roles, and work with the people already in the business to better understand what they think their roles and responsibilities include.
What are my opportunities?
As stated previously, it is important that employees understand their room for growth within both their role and organisation. This means laying out clear career paths for progression, and allowing them to figure out what direction they want to take in their own time. This does not mean only moving down the paths they are on right now; they should also have opportunities to move sideways into different disciplines or specialisations.
When dealing with engineering teams, it is normal to see two career tracks; one for managers (e.g. senior -> lead -> senior manager) and one for individual contributors (e.g. senior -> principal -> architect—where there is no expectation of people management). This is fantastic when thinking in terms of moving up the ladder, but it doesn’t translate to specialisations such as front-end/UX/UI design and accessibility, client-side architecture and state management, data processing and consumption, machine learning, network programming, system operations, developer tooling etc. Most engineers will have one or two of these areas that they are passionate about and allowing them to become the subject-matter experts within your team or organisation is an equally compelling story for their personal development.
Most mature organisations will have some form of career path matrix that aligns completely across the entire business. Creating such a matrix is key to ensuring fairness in terms of compensation and benefit across all career paths within your organisation, and enables staff to understand levels of seniority. Mapping this matrix to your already defined job specifications then provides clear communication of the qualifications and expectations of each role, and how an individual might then change role or career path within it—even if they are jumping from being a junior sales person to a junior developer or vice versa. The key is to ensure your employees aspirations are only limited by their own choices and commitment, and that there is clear definition of requirements to support a move in any direction they choose.
Once you have done this, I recommend you map clear open salary bands to each level within your career matrix. The aim here is to make all salaries ultimately visible, thus limiting any potential variation that is the antithesis of diversity within a business and focusing very clearly on building trust with all employees. The best organisations have public salaries, because individuals are paid fairly within understood banding that maps to the requirements of their roles and responsibilities. Unfortunately, this isn’t easy to achieve, and requires constant market management to avoid problems of limited flexibility during new hire salary negotiations, and internal salary adjustments. Despite this, it is my personal belief that this model should be the aim of any mature organisation. The management effort is outweighed by the trust and engagement it inspires within the team, and it completely nullifies any whispered politics around pay.
Understand the needs of the team
The next thing to understand is the structure of your teams, and how you intend supporting cross-functional development and support. Often this will depend on the methodologies you are intending to use for project/programme management, with team design evolving organically from the way your business handles the flow of work from inception through to delivery.
By “team design”, I specifically mean how many teams you have, how many people are on those teams, what their individual roles are, and what those teams are going to be responsible for. Ownership and accountability will be defined by this, so it’s important you give it a fair amount of your time unless you’re able to grow an ownership model organically as your business grows. Disclaimer: This task can be really difficult. I have failed at this even recently, and retrospectively I think the changes I needed to make happen were outside the remit of my role—I needed to work more intensively with the wider business to achieve a fundamental change to the business operating model which could support a more successful organisational design within Engineering.
Function vs. product focus
In 1967, a programmer named Melvin Conway introduced the following idea (now known as Conway’s Law):
organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
To translate into slightly less impenetrable language:
Any piece of software reflects the organizational structure that produced it.
A study of multiple large codebases was undertaken at Harvard Business School to validate this particular law. The study took multiple examples of software created to solve a particular problem (e.g. word processing, financial management etc.), and compared the codebases of loosely-coupled open source teams, and those of tightly-coupled teams. They found that the often co-located, focused product teams created software that tended more towards tightly-coupled, monolithic codebases. Whereas the open source projects resulted in more modular, decomposed code bases. This illustrates the need to design your organisation backwards from how you wish to deliver code.
Having worked in several larger organisations, its interesting to me that the ones with the greater success of consistent delivery are those that allow autonomy within their product and engineering divisions based on direct access to customers. Amazon, as an example, encourages a technical leader to treat his organisation as its own start-up, creating an environment where a team is forced to consider their users as customers, even if they are internal, and to plan and deliver their roadmap accordingly. In addition, operational performance is constantly measured and assessed using specifically identified key metrics for each subdivision. You cannot have function-focused teams working for a customer/product driven business unless there is some form of further adaptation in place which understands how to divide work for each function.
Tech start-ups, on the other hand, are often intensely product-focused due to growth around a limited use-case or customer cadre. In this case, it is more likely that the team will make the mistake of becoming too focused on the needs of one specific big customer, in order to keep the business. This can result in a loss of grip on the boundaries of a product or service, or worse, it turns the team into an outsourced pseudo-agency development resource for that one controlling customer. Strong product management is important here, but that product management needs to be the adapter between customer demand and intelligent technical delivery. Knowing how to convert requirements into user stories that make sense for functional teams is an undervalued skill. However, that’s a topic for another time.
Avoid skill silos
Enabling autonomy in a team requires a reduction in the opportunities for blockers. Back in the dark ages we suffered through a divide between ops, back-end, front-end, and QA skills. By grouping teams by skills we created artificial walls between stages of development and delivery. This enforced waterfall working—even though we claimed to be agile—because we had to wait for dependencies to complete further down the stack. The end result was that iterations were focused more on getting work over these boundaries, rather than rapid feedback loops with users.
In my opinion, development teams perform better when they are truly cross-functional. However, it is also important to realise that no two cross-functional teams will be exactly the same. Cross-functionality comes from understanding that a good team is organically built-up around the skills of its members. If we imagine each skill “specialisation” as a circle in a gigantic Venn diagram, each team member will appear on that diagram in quite different places, dependent on their key specialisations and competence in other areas. With that in mind, it makes sense to balance skills using complimentary team members, allowing for some degree of overlap. If I do not have the skills to complete delivery of a specific task, it is important that I can rely on another member of my team to support me through it. A team of complimentary peers is a powerful thing, especially if each team member has a little imposter-syndrome—this is a sure sign they’re in an environment of learning and growth, supported by everyone around them and not just their mentors or leaders.
This also relates to the concept of “full-stack” engineers—or what Amazonians often call fungible engineers. These are engineers that are equally capable across the entire stack—from the toughest cross-device-and-browser front-end challenge, through API and system architectural separation woes, to the gnarliest operation tooling problem—therefore making them fungible or flexible to move around, solving the business problems with the highest priority. In my opinion, however, this is a recruitment-driven misidentification that belittles the unique talents and experiences of each individual. I have an entire other post in progress on this subject. There are plenty of jack-of-all-trades developers, but they will always have a tendency towards that one particular specialisation. Which means they are actually unlikely to be “fungibly” valuable (otherwise described as flexibly valuable) across a wide array of problems, and are far more likely to create more issues than they solve. Any capable engineer knows what it is to grow through iterative failure; to learn from their mistakes, and to lead others with this invaluable knowledge. The process of doing this will always result in a specifically targeted skill-set. Also, I believe any truly self-aware engineer understands the effect their team has on them as an enabler. As previously stated, it is cross-functional teams that become flexible. Do not move individuals between problem spaces; move the entire team. This means you gain all that valuable talent and working culture without having to rebuild relationships between team members.
An additional method to avoid skill silos in teams is to encourage cross-team expertise, either as working groups—where individuals in a team also work with like-minded specialists in other teams to create standards and improve quality—or as satellite teams who are specifically designed to provide support in a given proficiency alongside any team that needs it for a given deliverable. My best experience with this has been in testing, where a “roaming” team of test-automation engineers spend time seated with a given team, helping them ramp up their skills and quality standards before moving on to another team. I have also seen this employed as “tiger teams”, who are a cross-functional team with significant maturity who may not have any one specific area of ownership, but can be deployed to help solve high priority problems within your entire stack. This is the absolute peak of an effective cross-functional team, as spoken about before.
Team size
Despite being the topic of great debate, I believe Amazon have significant cultural maturity, driven in no small part by Jeff Bezos’s own pearls of wisdom. A good example is the “two pizza team” rule, which advises not to have any teams larger than can share two pizzas together. This rule is based entirely on the rapidly increasing number of relationships between individuals that need to be subconsciously managed with each added member of the team. This can be modelled with the equation:
l = n(n-1)/2
And if we visualise that with a graph:
Not only do larger team sizes make for significantly greater relationships to manage, but they have also been proven to make people overconfident. Teams have a tendency to increasingly underestimate task completion time as their size grows, due to the optimism of the group. In their paper, “The Team Scaling Fallacy”, Bradley R. Staats, Katherine L. Milkman, and Craig R. Fox observe that when tasked to build the same Lego kit, teams of two people took 36 minutes while teams of four took 52 minutes to finish. However, the larger teams were almost twice as confident about how long they’d take. That kind of error in estimation can be extremely costly for a growing business or team.
In my experience, the sweet spot is between 5-8 folks, but opinions differ—even within Amazon itself. Based on the equation (and graph) above, 8 folks is a maximum of 28 relations to maintain between the individuals in the team, which makes for about the right balance between delivery speed, accuracy of estimation, and efficient communications. At this point, if you need to scale further, add another team and divide up the problem-space so that each team can have very specific ownership, control, and accountability.
Seniority
The other question I am asked a lot is, “what does a good team make-up look like in terms of seniority?” Unfortunately, there’s no single answer to this. It really does depend on the people. As an aside, it is my opinion that seniority is usually contextual to a team and business anyway, and those that are considered senior in one company and role are unlikely to be senior in their next role. However, they will have a greater potential to excel and will likely rise in seniority faster than similar peers who have not been senior before.
So what is seniority? Basically two things:
- Autonomy; the less guidance an individual needs in applying themselves to delivering team and company goals (without creating confusion or ambiguity), the greater their seniority within a team.
- Altruism, support, mentoring; accepting that seniority relates to greater autonomy, it follows that more senior folks spend more time working with team members that need more guidance and support. Senior team members invest significant effort in making the whole team better at what they do.
It is also worth noting that seniority at one employer—in one position—is very specifically contextual. There should be no expectation to transfer seniority, earned through experience or longevity, to a completely different role and company. Seniority needs to be consistently demonstrated through action. With that in mind, it is important as a hiring manager to make real use of a probation period to ensure a new hire is meeting your expectations. This really isn’t something you can confirm simply through interviews alone.
In terms of team structure, my personal preference is to have one or two senior folks per two-pizza team. However, I can’t emphasise enough how important it is to ensure those two folks are mutually complimentary. Having two senior folks on a team who are often at odds with one another is going to be one of the most destructive things you can do to your business. The major aim of any team structure design is to ensure that every member is complimentary to their peers, and that each individual brings something new and lifts the performance of the team as a whole. With senior folks, this effect is obviously going to be even more impactful as they will spend more of their time mentoring those with less autonomy.
As another aside, whilst I was writing this post over the past few weeks I came across this great and relevant post on an anonymous blog/newsletter called LittleBlah (whoever you are, I’m loving your work). Needless to say, I’ve subscribed:
The right make-up of seniority across your teams is largely going to depend on how urgently you need deeper hands-on experience (like managing operational systems in production, as an example) vs. whether you have the flex to grow a team’s experience and skills organically over time. In my experience, organically grown teams perform better 80% of the time because they have developed together over time, and are more able to second-guess their colleagues and team mates. In comparison, if you hire too many senior level folks too early, you may have problems of contention and disagreement over the best ways to solve certain problems. It’s also worth noting that hiring more senior folks is going to take time, so you may not be able to have one or two per team at any given moment. In this situation, you need to ensure the senior folks are given flexibility to work at mentoring across all teams.
All that said, I’ve worked in very successful teams of both types. I do not think there is any one correct answer here, but I would always favour less senior roles and more entry-level. There are always more entry-level folks than seniors over time, and it’s incredibly rewarding to take folks on and help them “level up” before such time as they choose to leave your employment, for whatever reason. It doesn’t matter what your business is, or what you’re trying to achieve; ultimately it should always come back to the people you employ, and doing right by them. In many ways you’re setting an example as to how you expect them to treat other people, which will include your customers or clients too.
Understand the needs of the company
So now we understand the needs of the individuals we’re hiring, and the roles and team structures we’re hiring them into. We’ve also figured out that we need to be able to translate customer/product requirements into a set of well-bounded ownership teams with specific deliverables. But what about ensuring the teams are adding true value to the company? And how can we ensure we’re attractive and engaging as an employer? This is where company culture becomes important.
Many large organisations spend time defining the characteristics and culture they think make them successful, and share them publicly. This is an important tool in allowing current employees to understand what the company is expecting of them, but also in attracting new employees. A few good examples are:
- Netflix: https://jobs.netflix.com/culture
- Amazon: https://www.amazon.jobs/en/principles
- Facebook:https://www.facebook.com/careers/facebook-life/
The folks over at Tettra have also collated a whole bunch of culture decks here.
At a bare minimum, you should think about defining out a business summary, vision statement, and mission statement; even if you’re only generating them for a single internal ownership team. These will help you formalise the language and imagery you use to describe what you do, and what you’re trying to achieve as an ownership group. This also helps unify these ideas across all your team members, which is super important if you want them to work as a coherent delivery organisation.
This stuff can sound very “soft and fluffy” (for want of a better description) to development teams, which means they often overlook the immediate value. Believe me, I have never delivered this information to a team and not received feedback that they had somehow misconstrued what they were building, or that it had somehow bridged the gaps in their understanding. People like to have a strong grasp on what it is they’re doing day-to-day. Literally anything we can do to help formalise or realise that should be considered priority.
In the longer term, setting out a set of standard behaviours or values for the team will prove to be an important group task. It can be the difference that enables confident decisions and strong plans and avoids confusion and ambiguity. Moreover, it helps provide team identity which affects our sense of belonging, as discussed way back in Maslow’s Hierarchy of Needs.
Key Performance Indicators
Another important tool in helping a team understand their place in the wider business are key performance indicators. At their most basic, these are a set of 1-3 metrics that the team agree will be used to measure their success. It’s important these metrics are;
- well-defined and quantifiable;
- fundamental to achieving the team or organisation goals;
- applicable specifically to the teams affect on the business needs;
- communicated throughout the organisation and the team.
At a higher level, it’s usually better to ensure there are KPIs defined at the business level, and that they are then repeated and transformed down to more suitable KPIs for each team within the business.
Once these metrics have been decided on, the team should then set about constantly measuring and reporting on them, allowing an iterative feedback and adjustment loop. The sooner a team have this sort of process in place, the sooner they will be able to both grow in effectiveness, but also to learn from their mistakes and share that knowledge with the wider organisation.
All this said, I have personally found that trying to wrestle KPIs all the way down to the personal level is a lost cause. Personal goals can certainly reflect the premise of a particular KPI, but they need to be individually tailored to personal growth, rather than that of the business. KPIs provide leadership and direction to teams, but they are difficult to deliver against for individuals, who should be working to a slightly different but complimentary agenda.
Summary
So if you want to build better teams, you have a bunch of things to think about and deliver yourself:
- Generate a business summary, mission statement, and vision statement.
- Build a career matrix showing career paths and job specifications.
- Balance the skill and seniority split of your two-pizza teams.
- Figure out the ownership of those teams, to support the architecture of your product.
- Work together to come up with some company values.
- Define business and team level KPIs.
Generally, you’ll find once you’ve got all this sorted out, it will be much easier to sell your culture and brand during hiring activities, and your team will naturally attract like-minded individuals. By representing the best interests of the individuals, they are more likely to talk favourably about you as an employer in social situations which will spread through networks quickly.
In addition, by having this all sorted out in your own head, it becomes easier to provide documentation and points of reference for your team. This means they will feel better supported in their growth, and are therefore likely to be more engaged over time.
This is, of course, only the start. Once you’ve got this all worked out, you’re going to need to start writing performance profile job specifications; figure out a sensible interview process that allows you to identify technical skills, autonomy, altruism, experience, and anything else you come to value; and design a probation process and ongoing scheme of 1:1s that provides the right environment for goal setting and support, allowing your employees to grow significantly during their tenure with you and your business. But that’s a whole other blog post really, and I’ve already taken up enough of your time.
Finally, and unashamedly, if you like the sound of the above and you’re a React/RoR developer, and you’d like to come work with me at Higher in Perth, WA, by all means reach out to me via LinkedIn.