More on this book
Kindle Notes & Highlights
Read between
March 10 - April 11, 2018
first-time parents) feel woefully underprepared for their new responsibilities. And, frankly, most are.
When converting an engineer to a manager, make sure you don’t describe this as a promotion, but rather a significant change in role and responsibilities.
So, consider setting a cap on the percentage of managers that you will hire from the outside. This will encourage investment in potential leaders on-staff and help alleviate concerns with hiring from the outside in general.
Regular meetings with an experienced mentor provide a forum for raising difficult questions or simply validating that what the new manager is doing makes sense. Ideally, this mentor should not be in their management chain, since this can make it harder to be open about any struggles the new manager is having.
Establish a learning program for managers This can be as simple and lightweight as a monthly book club meeting, or a more formal management training program.
Team members can no longer keep track of everyone at the company, so they start to establish stronger ties and even tribal identities with the people they work most closely with. Short-sighted managers sometimes even encourage this pattern as a way of bonding the team together.
As with ICs, managers need to know what is expected of them. Start by asking your managers to own the long-term effect their team has on the business. Everything a manager does, from hiring to coaching to communicating and so on, is ultimately in service of the long-term health of the company. But because these effects are often indirect and the team’s overall impact is hard to measure, you typically need to combine multiple second-order indicators, such as key business or operational metrics, team morale, NPS surveys from customers, and so on. Document and share these so that both your
...more
Make a plan for covering the manager’s responsibilities, whether that means rolling things up to the manager’s boss, or merging temporarily into a peer’s team, or asking a team leader to take on the manager’s role.
we described a key function of people management: “Ensuring the team is happy and productive by providing motivating work assignments, appropriate compensation, learning opportunities, and career guidance.”
If your company values bottom-up innovation and independent action, it’s important that you make this clear in your cultural messaging.
It isn’t practical to try to prevent all mistakes, so instead focus on improving how you react and learn from them.
One caveat, however, is to make sure these efforts are not just “innovation theater.” Unless there is some path for projects to actually make it to production, the employees that participate may end up feeling demotivated rather than energized.
As many founders have noted, startups are more a marathon than a sprint. Being able to set a healthy pace for yourself and your team will help preserve the team and give you the reserves you need when you truly need them to push to meet a critical deliverable.
if you decorate your office with Star Trek memorabilia, posters of flashy cars, and foosball tables, you might trigger a negative effect on retention of female employees, even if they happen to like those things.
New team members from underrepresented groups might have a harder time building these social connections, leaving them at a disadvantage to their peers. Better to spend the necessary time to create and maintain on-boarding docs than to demotivate a good engineer in their first few weeks on the job.
In other words, what makes great teams great? One of the key factors turned out to be the extent to which teams shared “air time” between members during meetings, or “equality in distribution of conversational turn-taking.” This tendency raised the collective intelligence of the group by promoting shared ideas, but also raised morale by increasing engagement of the entire team.
Don’t shower praise on the “heroes” who stay at the office past midnight every night; instead, understand why they feel the need for such long hours and take corrective action if needed.
Advocates for private levels tout the fact that private levels cannot be used to influence debates or decisions — everyone is publicly the same level, so a more junior engineer will be less intimidated by a principal engineer when discussing the technical merits of a proposal.
The following are some additional resources you can refer to: Alexander Grosse’s “Creating a Career Path” Urban Airship’s tech ladder on GitHub A different take from Rent the Runway
The purpose of organization is to reduce the amount of communication and coordination necessary. Frederick Brooks, The Mythical Man-Month
Pink argues that for people to feel intrinsically motivated, they must have three things: Autonomy The freedom to control how they do things and how they achieve goals. The goals might still be set by the company, but the staff are not micro-managed. They are able to make their own decisions on how to solve specific problems. Mastery The ability to regularly perform tasks that challenge them and are at the same time achievable. This contributes to a sense of ongoing mastery of their work. Purpose The knowledge of how their work contributes to the company’s goals. This can also mean believing
...more
Conway’s law states that “organizations which design systems...are constrained to produce designs which are copies of the communication structures of these organizations.”
Move fast and maintain the nimbleness of a small organization. The goal of hiring more people is to get more things done, and you want to avoid diseconomies of scale. Connect the employees closely to the product and its success. Your employees are more motivated when they see the impact of their work — successes as well as failures.
Also, whenever possible, a delivery team should sit in the same office, in the same room. As the Agile principles state: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
Some teams go a little bit wild with the idea of autonomy. When team members believe “I have complete freedom to do whatever I want,” there are likely to be problems. This is why we emphasize autonomy within certain constraints such as business priorities, organizational goals, or the team’s charter.
We have encountered quite a few organizational setups in which managers claimed their teams were autonomous, when in reality the teams were micromanaged, with endless product reviews and corrections from all parts of the company (also called “product management by committee”). It can be really hard for managers to leave teams alone. But for a specific and measurable outcome (like “increase number of page views by x%”), the team should have the freedom to design the solution.
This bears repeating: no one has a better view of a product or feature than the team who works on it every day. If leadership can provide them with the bigger picture, they should have enough context to make the right decisions.
In this chapter, we discussed five organizational design principles: delivery teams, autonomy, purpose, continuous delivery, and continuous learning.
When organizing delivery teams, you should choose a top-level approach for your team structure. Assess the situation and consider these four perspectives: Platform Do you prefer that your delivery teams have a shared understanding of technology? That would mean that all your iOS engineers, for example, should work on the same team in order to make sure that technical alignment is high. Features Do you prefer to build delivery teams that have a deep (and maybe even cross-platform) understanding of the main features? Company Do you prefer to build delivery teams focused on specific business
...more
the value stream map (Figure 7-5). Through a combination of informal interviews with different engineers and gathering data from our multiple automated systems, we were able to draw a map of our actual process, as opposed to the process we thought we had.
Sharing a person between two teams means you now have the same point of failure for two teams instead of one. Wait times increase, and it takes longer to deploy new work to production.
For example, in order to achieve a common approach in design, designers could spend one day/week working together — in the same room, if possible.
Average cycle time within a delivery team is the average time it takes from the start of a product story to the point of shipping it to production. A lightweight method is to note the time you start working on a story and the time when the story is in production. You then enter those times into a spreadsheet. After a few iterations, calculate an average cycle time. The number itself is not that important; what is important is to look at how the number changes over time.
For instance, if for three retrospectives in a row reveal heavy coordination with marketing, you should consider adding someone from marketing to the delivery team.
For the purposes of this chapter, we define team culture as: The expression of what we believe, as shown in the things we do and the way we do them.
Instagram: “Do the simple thing first”
“Culture gives us the ability to act in a loosely coupled way; it allows us to pursue a diversity of tactics. Uncertainty is the mind-killer and culture creates certainty in the face of the yawning shapeless void of possible solutions that is software engineering.”
Start by meeting with the founding team. It’s likely they already have well-formed opinions on what the team’s core values should be. Ask questions like: What brought us together to found this team? What are the qualities, behaviors, and practices of this team that we value most? What is our team like when we are doing our best work? What is the most important quality to look for in our new hires? What aspects of our team do you hope will still be present in five years?
The enemy of cultural cohesion is super-fast headcount growth. Companies that grow faster than doubling their headcount annually tend to have serious cultural drift, even if they do a great job of on-boarding new employees and training them.
Open communication, critical thinking “What should we do to improve our interview process/product/business?”
Empathy, emotional intelligence “Tell me about a professional conflict you had at your previous job. How was it resolved?”
Curiosity, continuous learning “What skills are you most interested in learning?” or “What is the most interesting problem you’ve wrestled with?”
Collaboration “Help me work through this specific problem...”
Factions forming: certain teams don’t seem to work well with others, teams blame others for failures. Not hiring for values; allowing teams to diverge cultures.
Encouraging your team to work on learning new job skills and giving them the time to do so not only improves their morale but increases their effectiveness as well. And building a culture that emphasizes learning can make teams more resilient to common scaling challenges like finger pointing and politics. For example, one of the reasons blameless postmortems are effective is that they emphasize learning over calling out a particular person or team that might have been at fault.
“War stories”/“tribal knowledge” Old-timers often have a trove of interesting tales to tell about the early days of the company, how they survived the tough times, and why things turned out the way they did. Creating a forum for this can help avoid veterans feeling marginalized by newcomers, a common problem during hyper-growth.
Performance feedback and promotions Include teaching and mentorship as key elements of the feedback and promotion process.
“Google’s data indicated that psychological safety, more than anything else, was critical to making a team work.” First introduced in a research paper by Amy Edmundson, psychological safety is defined as “as a shared belief that the team is safe for interpersonal risk taking,” or, more simply, “a sense of confidence that the team will not embarrass, reject, or punish someone for speaking up.” This confidence comes from team members trusting one another, learning through words and actions that it is safe to voice opinions without fear of retribution.
As with any significant change, cultural or otherwise, the first step is to prepare the team by explaining the motivation for the change, the “why” behind the “what.” In the absence of a clear, well-communicated rationale for the desired change, employees may fill the information vacuum with incorrect motivations, such as “this is just leadership posturing” or “they’re trying to get rid of our startup spirit!”
Zuckerberg took a significant chunk of their 10th anniversary F8 conference to explain the motivations for the shift: “What we realized over time is that it wasn’t helping us to move faster because we had to slow down to fix these bugs and it wasn’t improving our speed.”4

