Unless you started building your product in the last twelve months, you’re likely dealing with a fair amount of technical debt.
As an engineering leader, you push your teams to keep iterating on features, user experiences, channels for distribution, and other experiments that will help drive your product forward. If you execute well, you’re likely to see success.
But when you reach this point, you need to reassess whether the system architecture and organizational structure that helped you get there are still enabling success.
At Wattpad, we had been building up our technology and product for over a decade when we noticed easy things were becoming hard to do. In a company that has a core focus on user experience, it was obvious we were having a hard time enabling our product teams to do the experiments and take the bets necessary to serve our audience. At the same time, our user base was growing to a scale that was pushing our ability to maintain and provide a platform our users deserve and love.
Identifying the problems
The signals were there for us to see, if not clouded by how our teams had evolved. We had full-stack teams working closely with our brilliant product team, in the hope it would enable them to make end-to-end changes to our products. But the reality was the surface area of technology they needed to change to do anything was simply too complex. The cognitive load of any specific team to figure out ‘how do I make this change?’ was too large.
The accidental silos this team structure had created made it hard for the collective pain to be seen. When teams touched any piece of the system, we’d lose any common-ownership view of any one piece of our technological puzzle. One team could take a system down one path with great intentions, only to have another need to take it down another for an equally great conflicting reason.
To compound the issue, this complexity surfaced another problem: a lack of time to prioritize investing in systematic technology-focused works. If all product work takes longer than it should, it leaves very little room for technically-focused initiatives. We could see the overarching symptom: our teams were slowing down, and our ability to be agile in product building slowly eroded.
We dug in. Our most senior engineers started exploring the why. Why is it hard to change our code? Why is it hard for us to maintain and move our systems into more modern engineering patterns? You can probably guess why. Ten plus years of building! We needed to take a breath and pause for a moment.
Essentially our current team structures required any specific engineer to be comfortable digging into systems and code they had never seen, several times over, just to make small changes. If they wanted to take on larger systematic changes, it was even more of a challenge, and they were unlikely to succeed at the level needed.
The way our teams were set up didn’t match how our systems had organically evolved. Even more so, the evolution of our architecture hadn’t lent itself to a structure that could work at scale. We had two problems: an organizational structure where engineers had to know more than possible to be successful and an architecture we didn’t believe would scale with our user base to begin with. Both needed changing.
Finding a solution through Conway’s Law
‘Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.’
– Melvin E. Conway
Conway’s law suggests organizational systems tend to mirror in architecture the lines of communication of the organization. We had strayed from our desired lines of communication and architecture.
To resolve this, we’ve designed a scalable and agile architecture that we believe will be our path forward. We got here through both technical deep dives and many individual sessions with our engineers. And now we are mapping our org structure to match what the architecture will be, and in essence, we’re shifting both at the same time.
As you can imagine, where we are today is transitional. We have new teams, new systems being invented, and old systems being updated or migrated away from. Engineering leadership, both in management and senior technical roles, is focused on the enablement of our teams, having the people closest to the systems help design and iterate on how we move from past state to future state. It is an exciting, if not sometimes opaque, time.
This phase is very empowering for our engineering teams. We’ve enabled them to choose what areas of the architecture they want to take on, with guidance from a still-present Wattpad vision. We’ve asked them what problems they know we had and need to deal with, and we are! Has it been perfect? No. We still have a business to run, revenue to generate, and ongoing projects that need to be addressed while we shift the systems around the product. But we’re moving in the right direction.
Reflections
‘Skate to where the puck is going’.
– Wayne Gretsky
As we navigate this transition and work out what we need to do architecturally and organizationally, we’re skating to where the puck will be. That means focusing on the present or future rather than the past, where the puck has been.
We learn and iterate on our learning daily. The architecture we think we need isn’t written in stone, nor is the org structure. We’ve designed both to intentionally be more nimble than our past versions, empowering those closest to the pain points to make the decisions.
Having full buy-in from leadership and across the org, in and outside of engineering is making it all possible. As teams form new working bonds and establish trust and new communication channels, we work diligently to build systems with the sole North Star goal of getting back to enabling product iteration and growth. Simply put, to make easy things easy again. If you’re on a similar path, I hope you can learn from our experiences and that you find similar success.
