Go teams: On the development of products at issuu
Previous posts have talked broadly about issuu’s culture and our company’s approach to hiring and onboarding. Building on this foundation, we want to discuss how we design software that connects readers’ interests to publishers’ content, and particularly how issuu transitioned into a structure that unleashed delivery teams to innovate, as well as fix bugs and pare down technical debt.
Development at issuu, like at many other firms, was based on a shifting product road map — which by definition didn’t have ample room for small-bore, experimental ideas or improvements that could have a specific impact, only the massive undertakings. While we were launching new features and initiatives, people had to turn to the next big thing on the road map and weren’t always able commit more bandwidth for iteration. At one point, we heard some people say “We really need to work on A and B, but are tied up with X and Y.” Rather than be exclusive to projects with set release cycles, teams were eager to devote time to what they felt deserved attention.
Stand and deliver
What we’ve done to address this is alter the company’s structure to create self-sufficient delivery teams. Taking Product, Engineering, Design and other teams out of silos means that concepts and iterations are no longer detached from each other. By reorganizing into teams containing all the necessary skills, they are ready to deliver functionality and get rid of waste. You’re no longer trying to clump little features to try to make them worthy of the road map, and where you’re going to receive limited feedback on what did or didn’t work. Plus with more well-rounded and independent teams, ideas can come from anywhere — empowering people to have impact and uncovering proof that their contributions are successful.
The teams have at least 50% autonomy, meaning control over time that isn’t filled with projects beyond their rubric, to work on features, fix problems and deal with their tech debt. Each team as a whole, not the product owner alone, decides what will be the best use of its resources. (At the same time, there’s never 100% autonomy for a team, because each team is accountable and also instrumental in delivering an overall experience for customers, not a bunch of unrelated products. The last thing you want is to lose scale, coherence of design and UX and so on.)
We have sought to create a balance, giving the teams the autonomy to do features and improvements as part of their commitment to the company’s priorities. The teams figure out how to direct their autonomous efforts, drive toward the agreed-upon KPIs and devote themselves to top-level issuu goals. The road map can now honestly lay out the game-changers and how they’re being handled, with smaller sprints and campaigns being run inside teams.
Give it at least 95%
This process was a bit eye-opening for teams in the company. Once restructured and left to their own devices, some had to re-examine how they work on their KPIs. Most drilled their indicators down to around five; the team devoted to the Reader didn’t see a need for that many. One team with a lot of balls in the air is allotting a good chunk of autonomous time for measuring KPIs.
As outlined before, our engineering culture is based on trust, but you have to give trust and earn it too. Other parts of the company have to see the results of time used wisely. In resetting issuu teams as self-sufficient delivery units, our target is for the new groups to deliver the vast majority of their backlog items — 95% of them — to production without dependencies, minimizing handoffs. (They might not always get to 95%, but that should be the exception and not the norm.) The teams are also measuring the impacts of their work. Not every release will have a positive impact, but it should be expected to and it should be followed to understand what happened. We’ll talk about that more in a future post.
This is where we’re making a significant step toward unlocking product development: Instead of casting aside whatever isn’t laid out on the road map, the issuu teams are free to build, release and adapt in the context of accountability.
Let’s say some people in a team have an idea about something important to issuu. They try to distill it to a minimum viable state, the smallest thing that can be turned loose for potentially valuable feedback. The team saves some time for listening and measuring, and then gets to the scary part: It can’t actually plan for the unknown feedback! The team doesn’t know whether the idea as conceived and produced will catch on, and if so how quickly. What’s important is identifying something that could be innovated upon, creating a focused hypothesis, proving or disproving assumptions and finally demonstrating that to others in a defined period of time.
You can understand how some organizations might prefer a rigid, tested and predictable software stack. But for startups and many companies like issuu, developers want to make use of whatever tool or process is best for executing their product idea. This speaks to what’s perhaps the hardest part of building software, definitely the hardest to describe: It’s not writing the code that’s hard, but the communicating.
Communication in product development is about coordinating with teams and sorting out how different information and agendas can be encapsulated in one place. What are the objectives? How do you convey to designers that the direction they are pursuing is going to be very expensive? What has to end up in the code is shared understanding of the software’s capabilities and the business objectives.
As issuu team members come together and decide what to work on, they have to have empathy and consideration for their abilities as well as for the needs of others. We’re doubling down on the notion that when people figure out how to take ideas and ship them, they develop understanding for each other’s needs, and that this can and will produce great products.
John Sturino is VP of Product Management and Operations at issuu. Follow him @jcsturino.