R&D organizations can accumulate a lot of tech debt and thus suffer from low engineering velocity and quality issues. Software, though, is extremely malleable. It doesn’t mind that you refactor it or throw it away entirely. Your employees—your hardware, if you will—are not as flexible. You can A/B test a feature, but it is a lot harder to A/B test a reorg or a promotion to management.
Mistakes in your organization's formation are expensive: they are not easily undone and sometimes can take months or even years to fix. In this chapter, we will list principles and guidelines for shaping your organization to help you avoid pitfalls and create a robust team.
Structure Principles
As time goes on, the organizational structure will have to change. New teams will need to be created, merged, or shifted. More layers of management might be necessary. Some people might ask for specific titles or responsibilities. The principles in this section should be considered whenever you are faced with these sorts of decisions.
Teams
A team is the smallest organizational unit. As the basic building block of your org chart, it is a foundation that should be solid enough for the rest of the business to rely on. Creating the right teams will help with productivity, autonomy, communication, and ownership.
Team Role
First and foremost, each team should know what it is responsible for. In Chapter 6, we discussed organizational structures that help with achieving more impact, mainly cross-functional teams. When you just start out, you have one team, and that team is responsible for everything. As you grow, you default to splitting into groups by profession (e.g., backend and frontend).
That’s not ideal because those teams are incapable of delivering tasks end to end, almost by definition. It also encourages a mentality of “doing my part” as opposed to complete ownership over a feature or product. How many times have you heard someone say “The backend is done” when you inquired about a feature not being done on time? If the backend is done, but there’s no UI to make the feature available for users, does it really matter that it was done? Cross-functional teams have less synchronization overhead and so can finish things faster and own them wholly.
Team Size
People with an engineering background sometimes treat organizational structure like they would treat software: they look for concise definitions and borders. The problem is that you cannot easily undo a “refactoring” when it comes to teams, and so the Extract Team refactoring should not be executed carelessly.
Ideally, teams should have about six members. It can be a bit smaller when the team is being formed (more on that in a bit) or a bit bigger if needed. An experienced manager with a relatively independent team can manage up to ten or so people, in my experience. More than that, even if it seems fine, often results in lower performance over the long term. I am not a proponent of “flat teams” for anything but relatively small organizations comprised of senior people.
The same number of direct reports is also a good rule of thumb on all levels of the organization. One level up, when it comes to how many teams leaders (or engineering managers) should report to the same directors, how many directors report to the VP (or to a senior director), and so forth. This rule has an added bonus in that it saves on the overall number of managers you need to recruit. Thirty engineers, in six-person teams, require five managers. The same in four-person teams means eight managers: almost double.
Examples of Organizational Charts
Forming Teams
Given our rule of thumb for team sizes, the best-case scenario for forming a new team is like natural cell division: the team grows to about ten people and can then be split into two separate teams. If you are able to create a clear division between those different teams so that each has its own role and autonomy to accomplish things end to end, then you are on the “happy path” here.
A lot of times, though, the split will not be straightforward. Many executives reach for the refactoring prematurely, spinning out of the bigger team a one- to three-people team. As long as possible, I would refrain from doing so. These smaller teams, primarily when bigger teams already exist, tend to introduce more overhead than is worth it. If the existing manager can manage the team a bit longer, until it grows a bit more, that would be better.
Another thing to keep in mind is that sometimes when teams are split prematurely, you might be pigeonholing them to a role that’s too small. When that happens, the team’s scope will never justify growing, and with time you end up with a lot of tiny teams, requiring more managers, syncs, goal-setting, and so on.
The matter of who manages these teams will be covered next, but it is first essential to take care of the teammates themselves. Be clear about the changed scope of each group. Talk about any transition period where they will still have to do some cross-team work. Share the revised objectives for the team. As we covered in Chapter 6, the goals should be tailored to each group for maximum impact and so might need to be updated and not merely split between the new teams. As these teams are created, ensure that the process will be adjusted fast: meetings updated, Slack channels created, and so on. The team should feel like a real team and fast.
Lastly, these principles apply when you consider splitting a group into two groups or merging existing teams. It’s important to communicate your reasoning and, in general, treat such changes as the change initiatives covered in Chapter 7.
Managers
One might assume that any change that applies to teams also applies to managers, but reality tends to be a bit fuzzier. When you create a new team, likely, you will also appoint a new manager for it. However, that’s not always possible or even the right thing to do, and in those situations, you should be aware and make conscious decisions about the path you take.
Ideally, you will have a great candidate for promoting or stepping up when a new team is created or when someone switches positions. When that is not the case, you should avoid doing what many think is the next best thing: prematurely putting someone in charge of the team.
Make sure that the person is likely to be a good fit for the role, including expectation setting and painting a picture for them to envision how their day-to-day will look like.
Take timing into account. I do not believe that a new manager should only be appointed after whatever current rushes are settled and the team is in a lull. Timing is about the availability of the support system the new manager will need to succeed (covered in the next section).
Consider other likely changes that are imminent. No organizational change is going to be your last. Nevertheless, if you know of some that are overdue and will be decided on soon, it might be best to wait with introducing a new manager (e.g., if you are going to change a director for that group or move the team to be under a different director, you might decide to wait to get their input on the appointment as well).
When you take these aspects into consideration and realize that appointing someone right now would be a mistake, you have to buy time. That often comes down to having an existing manager in charge of that team. It is not uncommon to have a good team leader also be the interim manager of another team. Similarly, it is possible to have the group’s director be the interim manager. Either scenario is not ideal, but it is often better than the other options you have. Looking at the bright side, this temporary solution allows members of your management team to get acquainted with groups they wouldn’t have otherwise. That often has a positive long-term impact.
Another possibility, more common in larger organizations, is having an interim manager who’s not currently a manager. If you have someone who’s considering becoming a manager, you can make them an interim, with responsibility for some, but not all, the aspects of the team. The rest of the responsibilities, as well as oversight of the interim manager, are kept at a different manager (similar to what was described earlier). After a predefined period, you and the interim manager can decide whether this was a success and formally promote them or roll this back for various reasons. For example, you might realize they are not ready yet, or they decide management isn’t what they thought it would be.
I once started working with a VP of R&D about a week after he had decided to create the first two teams in his organization and promote two engineers inexperienced with management. Unfortunately, he instinctively skipped all of the steps I recommend: he didn’t wait for the right timing, didn’t correctly help them assess their fit for this role, and went along with it right before a big reorg. While one team lead was doing great with some coaching and guidance, the other struggled from the get-go.
We worked together to create a mentoring and coaching framework for the struggling lead and do the expectation setting (better late than never). The VP himself needed some coaching on coaching, and we made sure becoming a manager in that team was not merely “flipping a bit.”
These steps made everyone understand quite fast that the excellent engineer was not a good fit for a manager in this organization (at that point in time). The VP was able to reverse the promotion while retaining her and dodging a near-miss that could have significantly harmed team morale. Knowing to deal with your mistakes is important, but some mistakes you can avoid.
The Management Bit
How do you create a new manager in your company? Is there any specific process? When I worked at IBM, we used to joke that being in management was merely a matter of having someone “flipping a bit” in an internal system. You kneel, someone clicks a button, and you rise again, dubbed “team leader.”
Joking aside, that’s not far off from the way many companies end up handling these promotions. You have a few discussions with someone who wants to become a manager (most often, along with discussions with their direct managers and HR). The day arrives where you have a single meeting with them about “management practices,” and off they go. Management, though, is not like Neo plugging into the Matrix for training. You cannot go through a single meeting and emerge from it a manager (not a good one, at least).
Teams sometimes go to great lengths to create smooth and elaborate onboarding courses internally for their technical people. Rarely do the managers get a similar treatment. You can do better.
Manager Onboarding
You wouldn’t give someone who just finished reading their first programming book commit access to your repositories and wish them good luck. The same goes for managers. Manager onboarding can be as elaborate as you’d like it to be, but it boils down to two key elements: knowledge transfer and an ongoing support system.
Knowledge Transfer
You obtain a lot of information about the way the organization works, how managers are expected to behave, what the managers will be measured by, and so on. This might all seem self-evident and obvious to you, but the truth is that it is not straightforward to others. Even if they are not new to the organization, some of these aspects of their roles can be ambiguous in their minds. For this reason you should make knowledge transfer explicit when promoting or hiring managers. Plan to have a series of discussions about the topics in the following checklist over a period of a month or so. Remember that it takes time to think and practice what you are discussing.
One-on-ones and feedback: Talent growth is the most crucial aspect of a manager’s role in the long term, other than generating impact. Being explicit about the company's standards for conducting these, the needed preparation, and even simulations are immensely helpful. This often ties to the way that performance management is done.
Metrics for success: Communicate the way managers are evaluated in the company. Without aligning goals and objectives, they are likely to focus on different things.
Boundaries: New managers might need to be told what exactly is within their purview. Are they allowed to talk about salaries and raises? Are there issues that have to be escalated immediately?
Situations and responses: A standard part of all worthwhile training programs. There are typical scenarios that managers face. Providing your new managers with guidelines can significantly help to set them up to succeed. What do they do when things go off schedule, an employee is not delivering up to standards, or hearing someone on their team is looking for a new job?
Partnerships: As covered in previous chapters, managers can greatly increase their leverage on the organization by having trusted relationships with colleagues and counterparts across the company. Introduce them to the critical people they should be working with. If needed, provide them with basic training about those worlds and help them set up working relationships (e.g., regular sync meetings).
Transitioning to management: The move from being an engineer to managing a team is not always straightforward. Discuss whether they are expected to be involved in hands-on delivery, how their schedule should look like (similar to the time allocation covered in Chapter 3), and how to be informed of what the team is doing with micromanaging it.
Coaching: Another vital part of the manager’s toolbox is the ability to coach one’s team effectively. Good engineers often make for lousy managers at first. That is because they are so acquainted with the intricacies of the job that they become too involved, never really letting go. Learning to delegate and provide the team with autonomy to make their own calls and mistakes is vital. Coaching new managers in coaching is important and will likely be an ongoing part of their support system.
Support System
As time progresses, managers will benefit greatly from having others whom they can share and consult with. A reliable support system is a must, not just for first-timers. Putting these in place at all levels of management is a catalyst for managers’ growth.
First, there’s coaching, either from their direct manager or an external coach. This is especially useful for matters that cannot be easily shared with others in the organization, such as their teammates' personal issues.
Similarly, there’s mentoring by a peer, for example, assigning a more experienced “buddy” to new managers, so their questions have an address. Depending on the seniority and availability of your managers, this can be a great tool to speed up onboarding for new managers.
Another tool is management forums: regular meetings of managers at the same level and the same part of the organization (e.g., all engineering managers who report to the same director). Just as engineers can sit down together to tackle a technical issue without involving their managers, managers should have a team that they can rely on—without supervision. This approach has an added bonus where the managers learn to work together better, making their manager less of a hub.
You can pick and choose from these options if you are just kicking them off. However, all of them are immensely useful, and as a rule of thumb, all should be implemented by the time you have two directors or more.
Premature Organization
You’ve likely heard the old adage (attributed to Donald Knuth): “premature optimization is the root of all evil.” Indeed, when it comes to creating software, nailing down details and decisions prematurely is error-prone and often a costly mistake.
The equivalent for management and leadership would be rushing to create clearly defined lines in a forming organization. A widespread occurrence in startups, other than the straightforward premature promotions covered earlier, is the tendency to provide titles, allocate responsibilities, and create a zero-sum game. I refer to this as premature organization, and it frequently creates a structure that’s too rigid to change as the company grows.
As an example, I once helped an R&D organization of a young startup. Even before they had ten people, three were promised managerial roles, and technical responsibilities (e.g., backend architecture) were assigned to three others. Those early commitments ended up tying the executives' hands as the team tripled in the next 18 months. No one wanted to break a promise, but as they grew, they realized that some of those early decisions didn’t make much sense. Furthermore, having already “assigned” responsibilities to some individual contributors was harming their efforts to hire more star engineers and capped the ownership of others in the team.
You may feel pressure to make promises to some of your team as well. Currently, the industry is in a state where any half-decent engineer can find a new job quickly. Still, if you give in to this instinctive urge, you will be slicing your team into fiefdoms much too soon. I’ve heard that “titles don’t cost anything,” but they do. They have the cost of organizational debt that is harder to overturn. If you think that technical debt is hard to keep under control, wait until organizational debt prevents you from hiring the people you need.
Organizational Growth
Many executives set up a hiring strategy that boils down to “get the best and most experienced people we can afford.” Others, especially as organizations become bigger, have to accommodate the vast demand for senior engineers in the industry and hire more junior people with a lot of potential. In both cases, helping your team members’ self-growth is paramount.
Some growth comes naturally, with the challenges of the job. Highly motivated individuals notwithstanding, you will have to take active measures to induce ideal growth.
Peter Pan Count
Every year, you can purchase Bordeaux wines at a very early stage—often before they are even bottled. Bordeaux futures are cheaper than buying the same wines five years later. That’s because you make the buying decision based on some inputs that suggest the wines’ potential, and that’s it. The wine then needs some investment—time and storage in a proper cellar for a few years. If you can afford that investment and you know how to spot the high-potential vintages, you get a bargain.
Similarly, I recommend that most of my non-tiny clients start recruiting more medium and junior engineers. That is because there are more of them; they are cheaper and are more malleable. Yes, they require an investment in getting them to grow, but that investment has a tremendous return if done right. Further, your senior people should constantly be growing as well. They might be so good that they only improve by 5% a year as opposed to a junior who often advances 20–30% in that same time period. Still, 5% of improvement in your best people’s output is worth a lot.
How do you keep track of growth across your entire organization? For that, I suggest that you keep track of Peter Pan employees. Peter Pan was a boy who never grew up—he remained a junior indefinitely. Most companies have Peter Pan employees—those who, even though they’ve been at the company for quite a while, have yet to improve their performance substantially.
My rule of thumb is that individual contributors, except for the most senior ones, should make a discernible “level-up” once every 1.5–2.5 years. For example, most junior engineers should not still be seen as juniors after two years on the job. On the other hand, if an employee makes a leap within a year or less, they are ahead of the curve.
Along with your performance reviews, keep track of the “leveling up” your employees do over time. At some companies, this is entirely subjective and at others is a matter of moving up the engineering ladder (see next). If you have too many Peter Pan employees—employees who are “stuck” in the same place for too long—it is likely that you have a training or a hiring issue.
Keeping track of your Peter Pan count (the number of stuck people) and of those who are on a trajectory to become so will be of help to address these issues on time. The best way to do so involves asking direct managers for their assessment, as well as tracking the progress individual contributors make along the different traits covered in your organization’s engineering levels. It’s a lot harder to justify demanding behavior change if you’ve only realized there’s an issue after two years.
An organization with a healthy Peter Pan count will see the vast majority of people move up the different engineering levels (explained in the following) routinely. There’s no specific number to hit, but if you were to plot how much time it takes employees with the company for more than a year to “level up,” you should see a bell curve—the vast majority advance regularly, and on the edges you have a few exceptional people who do so fast and a few lagging behind. If the lagging becomes too substantial, you have a Peter Pan count that’s going out of control.
A CEO approached me to help his company’s struggling engineering team. Business was going great—prospects were urging the company to let them use the product. Unfortunately, things weren’t that easy to get done technically. Schedules were continually being postponed, the quality was suffering, and the general feeling for the other executives in the company was that of working with a slow and antiquated team. Bear in mind this was a startup that was only a few years old.
As we started looking into it, everyone agreed that the Peter Pan count was not looking good—other than the CTO and maybe one lieutenant, no one was capable of taking on responsibility. The CTO had to spend the vast majority of his time helping the team, making decisions, and acting as a hub and puppeteer (things were not moving unless he was involved). Some more digging revealed that it was due to the CTO having trouble letting go of things and genuinely delegating them to others.
Realizing the company could not survive even six more months in this mode, we acted quickly: first, personnel changes and restructuring the organization to provide the team with more autonomy; then, tight coaching to key people along with incorporating the principles of impact-driven engineering and timely feedback. These allowed the team to make a sharp turn and start delivering.
Career Ladders
Career ladders or engineering levels are names for a framework that defines the growth path individual contributors have in your company—the “professional” track. They initially gained dominance at larger companies but are becoming more and more common across the industry. The main benefit is that by having a clear description of the different levels an engineer can go through, you create a path forward for the vast majority of your talented people who cannot or will not go into management. This relieves a lot of pressure to perform premature organization: not every good engineer will demand to manage a team as a way to progress.
Most organizations already have the beginning of a definition of engineering levels, though often very weak and ambiguous. It is likely that you already have “regular” engineers, along with junior or senior positions. A healthy career ladder will require clearly defining the distinctions between each rung on the ladder, along with more resolution: you will want to add more levels.
Crafting the right engineering ladder for your organization is serious business and will require effort as well as regular adjustment: as your team grows, you will realize that some previous definitions are not good enough or that an extra rung should be inserted somewhere along the way. Nevertheless, a good ladder makes hiring easier, creates a path for motivated engineers to follow, and removes a lot of cognitive load from your engineering managers.
Cover multiple aspects: Good engineering ladders should not be based solely on the technical proficiency of your people. For me, a senior engineer is about more than cranking out code. Include requirements for topics such as mentoring, evangelism, supervision, innovation, and communication.
Have enough resolution: A ladder where everyone essentially gets stuck in the same level quickly or that has levels that require only a small effort to cross is not defined correctly. It might require some trial and error; however, this aspect of gamifying people’s growth can genuinely help them achieve goals faster. That is only possible, though, if they feel like the challenge is fair and makes sense.
Ladders should be transparent: The definitions should be widely available, as opposed to the tendency of some companies to try and keep them obscure. Similarly, consider making the information about who has what title/level available as well.
Feedback Skeleton
A vital part of growth for everyone involved is to have quality feedback given continuously and in a timely manner. The feedback skeleton is an invisible structure that holds together the entire effort of advancing your team individually. It comprises the regular one-on-ones held across all levels of the organization, performance reviews, and peer feedback.
It is very rare that I talk about regular feedback and one-on-ones and hear a clear objection, such as “We don’t do those.” Just like testing, everyone “knows” these are good ideas, and so everyone claims to have them. Digging deeper, though, frequently uncovers that is a void statement: one-on-ones take place very rarely and without any depth or underlying structure.
As part of the manager onboarding described earlier in this chapter, you should make your expectations regarding feedback clear and share the way feedback is conducted in your organization. For example, one-on-ones with direct reports are expected to take place every one or two weeks instead of merely being a vehicle to perform work syncs.
Encourage candidness and open feedback from peers across the organization. The best teams I’ve seen are those where teammates could put egos aside and speak their minds frankly.
Providing Feedback Regularly
A major problem with some cultures is the radio silence: you toil away, hearing nothing bad about your work, only to find out 6 or 12 months later during the arduous yearly review processes that you are underperforming.
Getting feedback in such long intervals is akin to getting your code reviewed 3 months after it has been deployed to production: you no longer recall what exactly was done, it doesn’t really matter anymore because things have changed since then, and you are biased to think that as it’s been a while it’s no longer valid.
A healthy organization should make it a habit to share feedback. I believe it is best to start, as a tech executive, by putting in place a laid-out process for management to follow about regular feedback and performance evaluations. As with code and product development, where we strive to get feedback and iterate fast to not waste time, the same can be reached with attention to your organization’s talent. Helping them see where they are having issues in timely fashion means they are less likely to burn out or simply give up when they realize there’s some hard work ahead.
One-on-ones are the regular meetings a manager has with their employee in private. They should be performed regularly. The cadence can vary, but for direct reports I recommend starting with weekly and maybe stretching it to biweekly. I’d be very wary of a longer interval. Assuming that your organization already has some loose structure of 1:1s in place, you should start with setting expectations with all managers to perform them in a timely manner from this point forward.
In case parts of your organization don’t already do these or they were performed poorly, you will need to walk through your managers in starting to do these right. In one-on-ones, we want to focus on both positive and negative feedback. Note this isn’t all what the meeting is about. It’s a place for the employee to speak up and share, but we’ll discuss that later.
This does not mean that after 9 months of radio silence your managers should merely send the invite for a one-on-one, get into the room, and start blasting away with all that needs improving right now. Anyone would feel blindsided by such a tactic and will not be likely to change or even take it well.
Managers should tell their employees that one-on-ones will now happen regularly and why, before sending the invitation. Otherwise, people tend to get needlessly worried, thinking that this new meeting is a sign of trouble.
At the first meeting, the manager should come ready with an overview of the employee’s accomplishments so far (meaning since the previous proper feedback was given), as well as a list of issues they will work together on improving.
As this is likely the first time the employee hears the feedback, I recommend giving them a day to digest it. If needed, devote the next meeting to further discuss these.
After this “sync” has been performed, the one-on-one handshake should be complete, and the process can now continue happening regularly.
Soliciting Feedback
As mentioned, one-on-ones are not just for providing the employee with feedback, but also about being a platform for the employee to speak up. Managers should actively solicit feedback from their employees in these meetings. Doing so is not always easy and requires effort, as some employees are not used to voicing issues or do not know how to do it in a constructive manner.
First, ensure that your managers make it clear that they expect employees to come to one-on-ones with their own agenda items (e.g., by starting the meetings by saying “Here are the two things I want to discuss. What are yours?”). If employees still come to the meeting unprepared, teach your managers to ask for feedback and sit there, not rushing to fill the silence.
What can I do to help you work better?
What do you wish that I did less of?
What has frustrated you in the last sprint?
Responding to Feedback
Once feedback has been successfully solicited, the worst thing possible would be to disregard it or shoot it down. Do it once and you are guaranteed to no longer hear candid feedback from that person again. You and the rest of the leaders in your organization have to treat incoming feedback with care.
First, managers should repeat what they have heard in their own words. This “mirroring” has two purposes. First, it helps the side giving the feedback to feel heard. Second, it helps handle the fact that words are tricky. We are trying to validate that both parties are talking about the same thing.
Next, accept the feedback and thank the employee for speaking up. I mean it: literally say the words “thank you.” Do not rush into a “but…” or a “no…” response automatically. Thank them and think about it.
Only then, after you’ve stopped whatever knee-jerk reaction you might have had, should you act. Either discuss the issue with them further, or tell them that you will get back to them. Follow-up is important: if the manager decides that the feedback is invalid, they should not merely ignore it. They should get back to the employee and tell them why they have decided against the suggestion they got. Otherwise, again, you run the risk of team members learning that these are black holes: you provide feedback and nothing comes back.
Organizational Knowledge and Support
The bane of organizations, as they grow and bring on more and more people, is the formation of silos. It is tough enough to fight against silos forming between your department and others, such as cooperating effectively with the marketing or sales department. Allowing such thinking to occur within your organization can be a death blow to any team trying to achieve nontrivial goals.
I have a litmus test for spotting whether you already have silos forming without your knowledge. Consider the different teams in your entire engineering group. Are there any that behave differently than the rest of the organization? A team that has a slightly unique culture? It can start with small differences in ceremonies, using their own tools, or avoiding some overarching changes in the group. Once those start creeping up, silos follow swiftly.
To fortify your culture and reduce the chances of siloed thinking manifesting, you should take steps that ensure knowledge is shared across the entire organization.
Peer Forums
Everyone in your organization, no matter whether they are individual contributors or managers, should have at least one forum of colleagues that they can rely on. For managers, we’ve already covered management forums. These, when run across the organization, can help in increasing cross-group communications and creating healthier relationships.
For engineers, it is natural to assume that their teams are their peer forums. However, encouraging discussions across teams can result in ideas that have a bigger impact and better cross-pollination. Holding engineering forums (or sub-forums for different specializations, like mobile development) that involve all relevant engineers in your organization is a great way to cultivate openness and collaboration.
Professional Leadership
The other side of the coin for peer forums is direction. Committees rarely create innovative ideas, and so peer forums are best suited for tackling specific problems and knowledge sharing. However, some technical leadership is essential for calling the shots when it comes to leaping forward, setting standards across the organization, and similar.
Peer sub-forums are often referred to as guilds. Professional leadership would be the guild masters. As you grow, assigning this responsibility (even on a rotating basis) can be a catalyst for improvements and challenging the status quo. It also reduces the chances that a team will drift apart from organization norms and form a silo.
Horizontal Development
Another option for increasing cooperation is to leverage your organization’s size for personal development. Often, talented employees are limited to growth within whatever team or group they originally joined. Keeping them in the same group has advantages, such as increased specialization. Additionally, managers hate “investing” in a teammate only to see them eventually move on.
Nevertheless, I strongly believe in natural movement between teams and groups as a developmental opportunity. For example, after 18–24 months in one team (and likely an engineering-level bump), encourage members to switch to a different team in the engineering organization. Constant swapping of experienced people between groups has positive long-term effects.
First, it becomes harder for culture pockets to take shape. The swaps “average out” a lot of the differences. Second, a fresh perspective is incredibly valuable, and a fresh perspective from someone who already understands a different aspect of the company is even more profound. A third advantage is that it creates better relationships between those teams and improves communication, thus resulting in easier collaboration when necessary.
One last advantage is that it is plainly good for your employees. Having to move out of comfort zones and readjust does wonders for motivated people and also supplies more interest to keep attrition low.
Your Personal Upgrade
Shaping your organization is hard work—some say it’s the most challenging part of the job. The principles and tools described in this chapter should save you precious time, efforts, and relationship capital. You can leverage your new knowledge to create teams that will perform better in the long term and help your engineers be the best they can.
After all is said and done, your team is your greatest asset. Helping it operate smoothly is a necessity, and organizing it efficiently is granted to give you an advantage. Another surefire way to increase your chances of success is to foster product mastery across your team, which the next chapter will cover.