Watching your software startup mature into a more sustainable midsize company can be a very exciting time. But this growth comes with a whole new set of challenges. How can a startup anticipate and take action on what lies ahead?
To answer this, we asked Sean Doran, Director of Technology at Wave, about pain points they experienced while growing from a small 7-person startup in 2010 into the 70+ person midsize business it is today.
Here are five challenges Wave faced that you can keep in mind as your own software startup grows:
Challenge #1: Transitioning from working at speed to working at speed with discipline.
Most startups are focused on coding, iterating, pivoting and delivering as fast as possible. But when you migrate from a small to a larger engineering team, things like dependency management and your continuous delivery pipeline will be put under stress. There are simply more engineers delivering into production.
One solution to maintaining the speed and frequency of delivery is to introduce more discipline into how your engineering team works. Agile offers a good framework for this and everyone these days has some form of iterative development process. But Agile is only a toolkit – scrum and lean don’t have much to say about actual engineering practices. You need to decide which practices to apply so that the team is continually delivering and improving at the same rate as you did as a startup.
For Wave, this meant structuring work around smaller teams that they knew worked together effectively so that the frequency of releases didn’t slow down, as well as cycling the members of the team that completed bugs to maintain efficiency.
Challenge #2: Maintaining the high quality of your engineering team as you grow.
When you’re an engineering team of two to eight people, the hiring process is usually informal. It’s easy for everyone to meet any potential candidates and have a say in whether they’ll be a good fit technically and culturally. As a midsize company, you’ll need a more disciplined hiring process, since meeting and deliberating with every member of your now 10 to 20 person dev team isn’t realistic.
How do you tackle this? Wave’s approach involved adding more structure, established evaluation criteria and formalized tech evaluations, while also maintaining certain informal aspects.
For example, they invest heavily in the interview process and make decisions on new hires within 24 hours of an interview to not miss any opportunities. Their candidate pipeline is built in a number of ways, from driving excellent referrals and ensuring good job descriptions from the get-go, to more informal tools like maintaining a presence at Meetups and conferences where the team might interact with great potential hires. Once a new employee has been added to the Wave team, they also continue integrating new hires through exercises like pair programming and group lunch and learns.
Challenge #3: Growing from launching products to maintaining and delivering new products
Startups deal primarily with initial product launches. There are no assets to maintain, since you’re always focused on whether you have a marketplace. Projects are usually individually owned, building up silos of information.
But when you have assets in place and are scaling your business, you are not only launching new products but also maintaining existing ones (and trying to balance your engineers between both activities) since you now have an existing user base that relies on your software.
How do you assign resources and accountability in this environment? One way, Sean suggests, is to give ownership of features and products to an entire team. “As we’ve scaled up, we’ve focused on team ownership of feature sets and projects, since there’s too much knowledge for any one person to have across the whole application,” he says. “If you can get ownership from the team, you can inoculate yourself a bit against any one engineer leaving [and leaving knowledge gaps].”
You should also look at automated test suites to provide test coverage from the beginning that in the long term use less QA resources and are more reliable for new releases and for getting patches into productions. This approach also protects you from individuals (dev or QA) leaving the team and leaving knowledge gaps in how the system should be tested.
Challenge #4: Introducing structured leadership into a flat hierarchy
Most people want to work in an organization with a fairly flat hierarchy, since we all value agency and control over our work. But as your dev team grows, structure becomes increasingly necessary. This might be an especially difficult transition if employees are used to working closely with founders.
How do you engender structure as you grow in a way that is organic and still gives team members a sense of agency?
Sean found that making team-based decisions has worked for Wave. One example is how they handle Architecture decisions. In place of a single Architect, architecture decisions are handled by a dedicated Platform Team. The Platform Team has a consistent core of hands-on engineers (they still do some coding), but rotates member of different Product Teams into the Platform Team depending on the product being worked on. This gives everyone the chance to feel empowered, learn from a variety of peers, and share the responsibility for overall architecture of the application and components across multiple delivery teams.
Challenge #5: Your values become less transparent as you grow
It’s easy to know your startup’s values when you’re a five-person team. But as you grow, it’s more challenging to maintain transparency and consensus on the values of your organization.
What’s the solution? “First off, don’t fall into the micromanagement trap,” Sean warns. “The goal of values is to enable people make decisions effectively for themselves on a daily basis.”
Wave has addressed this issue by undertaking an exercise of formally agreeing on a set of values across the whole organization, anchoring how they work with one another.“There are certain values that come from our founders, but the team needs to feel connected to the process of creating our company’s values. The outcome of this process is a very transparent set of principles that we can reference and make part of our language, and use to provide feedback to the whole organization.”
By engaging the entire company in generating and documenting values, you have an opportunity to make sure the culture you loved as a small organization is sustainable as it grows. The difference is that you have to engage a wider set of people to formulate and embrace those values.
It’s also important to consider how you put values into practice in a way that creates a sense of understanding about what they actually mean. For instance, your organization’s values should be part of an employee feedback cycle that connects good behaviours with fulfilling organizational values and areas of improvement with not fulfilling certain values.
Most importantly, the management team must always lead by example: “Nothing’s more debilitating to a value exercise when you put those values up on the wall and the management team doesn’t live up to them,” Says Sean. “Why should anyone else?”
Has your company experienced any of the same growing pains mentioned by Sean? Are there any additional issues you’ve come up against while scaling? Share your thoughts with us by leaving a comment.