Scenario Your startup has met with some success, and is now a team. (If you are in an enterprise, you’ve been promoted to team lead). You’ve moved out of the garage into a more professionalized environment. The team has a single mission and a cohesive identity, and you don’t need a lot of overhead to get the job done.

Even with a few new people comes the need to more clearly establish your product direction, so people are building the right thing. You’re all in the same location, and can still communicate informally, but there is enough going on that you need a more organized approach to getting work done. Finally, this great thing you’re building doesn’t mean much if people cannot understand how best to use it, or if it’s not running and the right people can’t get to it.

Things are getting larger and more complex. You have a significant user base, and the founder is increasingly out meeting with users, customers, and investors. As a result, she isn’t in the room with the product team as much any more; in fact, she just named someone to be “product owner,” and what is that all about?

The practices and approaches established at the team level are critical to the higher levels of scale discussed in Sections 3 and 4. In this section, we discuss small, cross-functional, outcome-oriented teams. We discuss product management, work management, shared mental models, visualization, and systems monitoring. We discuss collaboration and customer intimacy, and the need to limit work in process. And we discuss blameless cultures where people are safe to fail and learn. All of these are critical foundations for future growth; scaling success starts with building a strong team level.

Special section: Systems thinking and feedback One of the most important aspects of DevOps and Agile is "systems thinking," and even a small team building one digital product can be viewed as a system. We talk of information systems, but what is a "system"? What is feedback? There is a rich body of knowledge describing these topics, which we will touch on in this special section.

Chapter 4: Product Management

You (as the startup leader) are spending more time with investors and customers, and maintaining alignment around your original product vision is becoming more challenging as you are pulled in various directions. You need some means of keeping the momentum here. And the concept of “product management,” you’re finding, represents a rich set of ideas for managing your team’s efforts at this stage of the game.

Chapter 5: Work Management

Even with a small team of five people (let alone eight or nine), it’s too easy for balls to get dropped as work moves between key contributors. You probably don’t need a complex software-based process management tool yet, but you do need some way of managing work in process. And you start to understand that work takes many forms and exists as a concept at different scales.

Chapter 6: Operations Management

Since Chapter 3, your application developers have been running your systems and even answering the occasional phone call from customers. You’re big enough that you need a bit more specialization. You’ve got dedicated support staff answering the phone calls, and you are finding that, even if you rotate operational responsibilities across developers, it is still a distinct kind of “interrupt-driven” work that is not compatible with heads-down, focused software development. You’ve probably seen by now that complex systems are fragile and tend to fail; how you learn (or don’t) from those failures is a critical question.