How do Small Teams have a Big Impact in Large Companies?
Sometimes it feels like we are swimming in a giant sea of products, people and teams. Other times we forget that there are oceans of activity going on all around us.
Developing software in a large company comes with a unique set of challenges. For a small engineering team, having an org-scale impact can be intimidating. If you are leading a small team in a large organization, it helps to have some heuristics to guide you.
In my own experience with navigating the seas of large-company life, here are some of the things that have helped put wind in the sails of my teams:
- They Value Relationships
Relationships are the most durable thing in our industry, which is otherwise characterized by a fast pace of change. They survive re-orgs, resignations, product pivots, budget cuts, rapid growth, acquisitions, layoffs, downturns, you name it. But they need to be formed early and nurtured — they are built over time, not the week before you need something.
No team is an island. To be successful, you need to work with a network of teams that delivers value together. It helps to take the time to think through your partners, dependencies, and the value stream of your product: you will discover the key people you need to work with now and in the future. These are the people to invest in building relationships with.
Development gets most deeply and intractably stuck when something is needed from somewhere else, but there is no relationship in place (or maybe a bad one). Many of the most significant slips and falls I have seen result from teams that go deep into the darkness of development, meanwhile forming unreasonable expectations of entities on the outside. Then they are surprised when no one is aligned with their needs when the time comes for help. Don’t be that team — make friends in far-off places and be sure you are prepared when you need help.
2. They Ruthlessly Prioritize
Identifying high-value work and staving off distractions is a cornerstone of good product development. This requires us to be realistic when making trade-off decisions. Fear should not be part of the decision-making (“If we don’t do this now, we might never do it!”). Hope should not be part of the decision-making (“This better work out!”). Small teams need to make smart decisions about where to focus, and then maintain that focus despite all the things that can throw them off the path. Measure twice, then cut, cut, and keep on cutting — use continuous prioritization throughout the development lifecycle to keep the team on track.
For an engineering (i.e. not product) focused discussion of what this means, John Ousterhaut has a great chapter (page 17) called “Decide What Matters” in the new version of his book, A Philosophy of Software Design.
3. They work as an Integrated Team
Big impacts need big ideas, and the best thinking comes from diverse teams. This means integrating a diverse set of roles into the development process and team rituals right from the early stage. This is whole-team, “customer in the room”-style thinking. People in roles like product management, design, SRE, customer support can regularly join your stand-up, your milestone demos, and/or your amigos meetings.
Any time you can embed someone from that “other” team into your daily development cycle, it makes collaboration strong and the inevitable product phase transitions much easier. Armed with fast feedback and diverse thinking, you can make sure that what you are building will actually make a difference.
4. They Build Quality In
This phrase, which dates back 50 years to the days of Lean in manufacturing, will never be a cliché. When we continuously deliver elements of a quality strategy throughout the delivery process, we ensure that our system will hold up across the various stages of the development lifecycle. For example, in the early stages, we need design partners to come on board and get a reasonable experience. We want valuable feedback, not “you lost my data again” or “your system is down again.” Overall, as with point 3, this will make your product phase transitions easier and builds a lot of confidence with the people that are funding your product.
5. They Put People First
Putting people first means creating an environment with trust, transparency and alignment. It means creating circumstances where people can bring their best selves to work every day, operating with psychological safety. It does not, however, mean coddling or treating each other like spoiled children. We work as a team, not as a family (Reed Hastings). In reality, we put people first when we hold each other accountable — that is part of our responsibility to each other and our path to success as a team. Align on a shared set of values, help people put those values first, and create a culture where we feel good about holding each other accountable to them.
6. They Show Their Value
To have an impact, you need to know what value you are creating and be able to show that value to others, so they know how to leverage what you are building. Small teams need to find big ways to show what they are doing and get people excited about it. This means having a clear, always up-to-date articulation of your system and it’s part in the greater whole.
You are building something that needs to integrate into other systems as part of a larger product story. Get to know those systems and that story really well, because what you are a part of is more important than what you part are building.
Take the time to understand your adjacencies and how they work — go read their docs, deep dive into their architecture, walk through their code. Generate your own mental model for how everything fits together, don’t rely on someone else to do that for you. Create your vision, articulate it in docs or slides, and take every opportunity to get feedback on your thinking. You can use that as a great way to build relationships (back to point #1). You may not sell anyone on it, but you might get a seat at the table.
