Chris Kirk and Aaron Verones are two members of our Software Development Leadership team at Wrk. They have both worked for small and large companies alike, and have been part of scaling up development teams from one to hundreds of developers. In this post, they talk about how Wrk is putting developer and client experience first as the company grows.
Scaling Up: Teams, Silos, Communication, and Movement
In the early days of Wrk, our development department might as well have been one team. We were one homogeneous organization without well-defined boundaries. We had meetings with the entire development team at least twice a week, and we would frequently reach into other teams’ code to make changes.
This, of course, is a classic startup story (minus the ping-pong tables—we’re fully remote!). But then something weird happened: we started growing.
Growing will change your company. First, as you scale your team; then, as you scale the delivery of your value. Scaling up can enable wonderful things for your product and for your customers alike. Companies will aim for better service levels, higher security, and wider markets. However, this can lead to teams getting siloed, losing track of what other teams are doing, and even losing touch with the customer’s reality.
How Wrk Fits into the Growth
At Wrk, we’re getting ahead of this. One of the anti-patterns of the startup is that everyone talks to everyone. This becomes unsustainable as the company grows.
However, if communication channels are too tightly controlled, the needed communication doesn’t happen at all. This enterprise trap is siloing. We are avoiding this by creating well-defined interfaces between teams, just like we do for software systems.
A team interface includes:
- A wiki to read about the team.
- Documentation about what services and API endpoints a team exposes.
- At least one public Slack channel for getting in touch with a team.
This way, answers to common questions can be found immediately in the documentation, communication is reduced to mostly new questions, and new learnings can be immediately added to the documentation so the team interface gets stronger over time.
Another way we help avoid siloing is to encourage movement between teams. Both authors have changed teams since joining Wrk (Chris once, Aaron twice!) and several other developers at Wrk have changed teams as well. Developers report this to be a highly positive experience.
At Wrk, our teams are aligned to different areas of the business and teams have the freedom to choose the technology best suited to serving their customers.
This means that when developers change teams, they learn about a new part of the business and are able to build skills in technology they may not have otherwise been exposed to.
Developer experience
A common reason we’ve heard that our developers choose startups over bigger companies is the opportunity to solve a customer’s problem end-to-end. They are involved directly with the Product team and often directly with the customer as well, then they get the opportunity to build the entire solution.
This is, for better or worse, typically a necessity in startups. Team members with specialized skill sets are usually not hired until later in a startup’s lifetime. However, When they do, they are often put into separate departments that result in too many handoffs.
When development teams have to hand off to QA, infrastructure, database, or security teams, developers no longer get to work on solutions end-to-end. This pattern can also lead to platform teams that cause blockages in progress.
We invert this pattern at Wrk by making development teams cross-functional so that they have the skill sets to work independently, and making supporting resources available in the form of consultant-style specialist teams or self-serve platforms that are complementary instead of blocking.
With our model, developers love that they are still able to take a problem and run it end-to-end just like we could in the startup days, and we benefit from the additional resources available to us now that the company is scaling up.
The focus of our product vision
When Wrk was younger, we were in a great unknown world trying to build our core business values. Picking and choosing what to work on felt like the wild west; it was an exciting time of exploration, but it resulted in a lack of focus. Features built one day would be removed the next, and developers were always pulled in a number of different directions.
As Wrk grows into an enterprise, we are staying fast by using product-led growth. This means, among other things, that we shift design autonomy to the front lines, experiment, collect data about our experiments, and use those data to inform our next ones.
Compared to our startup days, our product decisions are much more data-driven now than they used to be. This helps avoid “volume-driven development” where the loudest opinion is the one executed on. It also allows development teams to collaborate more with product and customer teams rather than having a waterfall-like handoff interaction.
Our software development processes are also much more data-driven now. More investigation happens before features are built, which gives developers more confidence in the quality and longevity of the systems we build.
This reduces downtime and after-hours callouts, as well as increases the percentage of time we spend building new features. Our design process helps us think about scale and security before implementation, and also helps us protect ourselves and our customers from regressions.
We view each feature as a promise of a solution to a customer. Our increased focus on our product and commitment to being data-driven results in more solutions being delivered to our customers, less rework, and an overall better experience for all.
Scaling up with intent
Our software development department is open to new technologies and new ways of doing things. Not in the wild-west way where anything goes, and not in the slow enterprise way where the cost of innovation is discouragingly high. We have a fast, reliable way of justifying new technology choices that lets us move quickly while maintaining discipline. We don’t have a culture where only the most senior people get to work on the coolest things. Everyone is on equal footing, right down to our most junior engineers. We have had effective continuous integration and continuous deployment from day one.
Even though we have multiplied the size and value of our company many times over, deployments can make it to production in less than an hour, and we still release code multiple times per day. As we continue scaling up, we will continue to stay fast and avoid the common pitfalls of the enterprise by putting developer and client experience first.
