Andrew Kippen's List: Canary - Reading List

• Every day, people form impressions of brands from touch points such as advertisements, news reports, conversations with family and friends, and product experiences. Unless consumers are actively shopping, much of that exposure appears wasted. But what happens when something triggers the impulse to buy? Those accumulated impressions then become crucial because they shape the initial-consideration set: the small number of brands consumers regard at the outset as potential purchasing options.

• “One of the most scalable organizations in human history was the Roman army. Its defining unit: The squad — eight guys. The number of guys that could fit in a tent.”
• When you’re small, everyone sits in one room and everything works. As you grow, things start to break. “That’s when you need to take all your engineering knowledge and apply it to your team, and you want to end up with a modular system where teams become the unit of scale
• Build strong teams first. Assign them problems later.
• Keep teams together.
• Go modular. Remove dependencies.
• Establish a short, regular ship cycle.
• Fry is big on the importance of stability. In tech’s culture of growth and failing fast, it’s a quality that is too often sacrificed for the sake of speed. But stability isn’t just about consistency — it’s about resilience, distributed knowledge, optimal performance.

• When most tech companies are just starting out — and Twitter is no exception — everyone does a little bit of everything, and almost all actions are reactive. Projects pop up, and you have to quickly rally a team around them so that things don’t fall apart. This gets you into the habit of staffing projects fast for short periods of time. This is fine at first, but it’s a habit that eventually needs to be broken.

   

  At a certain size, two things become clear: 1) Many people are working on too many teams at once and get stretched too thin, and 2) as the leader assigning people to teams, you’ve become a huge bottleneck of information. You start accruing technical debt because there’s no time to slow down and fix all the little cracks in your products. At the same time, you lose your ability to innovate.
• This is one of the key reasons to keep teams together. Trust is a much bigger deal than most people think in this context. But trust breeds healthy communication, and that’s ultimately what boosts you into that high-performance zone where teams tackle problems with all cylinders firing.
• To achieve this level of flow, Fry recommends keeping teams together for at least six months, and ideally a year or more.
• A big part of building long-lasting teams is protecting your people. Too often, Fry says he sees startups failing to treat their employees as well as their hardware. “Would you run your data center at 100% utilization all the time? No. Not even 80 or 90%.
• Instead of looking at how hard teams are working, you should focus solely on how much they are able to produce, Fry says. Teams will never perform optimally if one person is doing all the work while everyone else sits around. Same thing if a hardworking team is stymied by one non-performer. Ensuring that everyone is working evenly and sustainably is the best way to get the most done.
• Getting teams to sit together: “It’s one of the most powerful things you can do to fix issues when things aren’t working.” This is obviously harder when you have a large, global team, but when you’re just entering your growth-phase, it’s critical.
• Making someone responsible: Anoint a great, communicative leader who will be responsible for the output of any given team. Maybe it’s the engineering manager, maybe it’s someone else. But you have to have a point person who is encouraging everyone else to perform and communicating progress to the broader organization.
• Clarifying mission: Every member of every team should be able to tell you immediately what their group’s goals are and why they are important. It’s the only way to fuel momentum.
• Knowing your role: If teams at your company are performing well, your only role as a top executive should be to make sure they have all the resources they need to deliver on their mission. “This is often the hardest thing you face as a leader, but it’s also the most important,” Fry says. A lot of startup founders have a hard time letting go of the details, but to get the most out of your teams, you often have to accept a supporting role.
• Establishing and respecting the sanctity of teams gives you several advantages. They become self-healing and self-correcting organisms. When a stable team encounters a glitch or misses a goal, it regroups, knows how to run a tight post-mortem and adjusts for the future. At the same time, you give people a chance to distribute important information.
• When strong teams (instead of individuals) become the basic unit in your organization, you can build faster, distribute authority, and still do astonishingly original things
• The first rule of thumb: Good modules are cross-functional.
• “Training people so that they aren’t hyper-specialized is one of the best ways to prevent bottlenecking,” says Fry. “That way, you never have to wait on an answer from that one guy who knows how to do Android. You can do so much more on your own.”
• Once the company had this highly-skilled mobile force, it distributed these engineers among feature-based teams, each comprised of a product specialist, a designer, and others needed to make that feature a success. This gave each engineer control over their own work and made them a central pillar of a strong team at the same time.
• This modular structure naturally eliminates dependencies. When people have broader skill sets, they don’t have to depend on other people’s knowledge.
• o shake things up, his first order of business was to restructure the engineering organization — at that time about 40 strong — into small, nimble teams. He also added more milestones and shortened testing phases. Eventually, the company was able to release data-driven products every four months while also growing to over 600 engineers.
• “You always want the shortest development cycle.”

22 more annotations...