When a business grows in size, processes that once worked great can seem to lose their lustre. What worked when you were a team of 5 might not work when you grow to 25.
Willingness to change and adapt is an important element of any business if you want to scale successfully. Just because something worked for years, doesn’t mean it will continue to work, and sometimes things you’ve done for years can be done even better if you’re prepared to analyze, experiment, and improve.
“Progress is impossible without change; and those who cannot change their minds cannot change anything.” – George Bernard Shaw
We’re a boot strapped small business and we’re also ambitious. We are always challenging ourselves and improving our processes. In our 15+ years of being in business, we’ve learned the importance of change and the need to adapt in a fast-paced industry.
Here is how we’ve applied our this mentality to our development process and restructured our teams.
Our old way
Our engineering department used to be grouped into teams by their function: Design, Client Development, and Cloud Development. The Design Team handled the UX and UI of Daylite, the Client Development Team coded the Mac, iPhone, and iPad apps, and the Cloud Development Team coded the backend, syncing, etc. side of Daylite.
Our old way of working – the way we had worked for over 10 years – was similar to that of an assembly line. The design team worked on their component of the feature, while the Client Development team worked on their component of the feature, and the Cloud team worked independently on their component of the feature. Once that component was done, they’d start to work on the next component.
Sounds like a smooth process, right? Well, only sometimes.
The problem with the old way
The problem with our old style of working is that things rarely go as planned. Problems found in components of work from one team sometimes have to be sent back to the other team. Because the Client and Cloud teams worked simultaneously, but independantly on features that required client and backend interactions, it meant that if the Client team found an issue, it could take a while for the Cloud team to resolve, or vice versa.
In other words, work sometimes had to be sent back up the assembly line and this caused problems. When things got sent back up the line, everything was delayed. Each team needed to either reshuffle their priorities, or wait while a project was reworked. This made work stressful and created more delays. It also created a bit of chaos because it meant a bunch of things were worked on a little bit, but not fully completed until much later.
This caused a delay in production time and resulted in a a culture where projects lacked real ownership. It wasn’t that employees intentionally avoided collaboration, it was just the environment that this style of work created organically. People were too busy in their own work that they didn’t want to be distracted and have to switch gears to come back and change something they had already finished.
Analyzing and challenging our process
What we needed was a collaborative environment where people worked together to swarm and solve problems – challenging and debating decisions before moving forward. We needed team members from multiple departments to work together on focused projects so they could make changes and complete them together before moving onto the next piece of work.
What we needed were cross-functional teams.
Restructuring our teams
We looked at our development process and experimented with working in project-based teams. A cross-functional team that focused on one feature at a time and collaborated to solve problems as they come up.
We now form a project-based team that includes whatever team members are needed for that feature. For example, a project team may need a designer, Mac developer, iOS developer, and a Cloud developer. This way decisions are made collaboratively and the turnaround time for feedback from one “department” to the next is much faster.
While a feature is being designed, the team can decide how the backend is going to work and how the Mac or iPhone app will behave. Decisions can be debated collectively among designers, client developers, and backend developers so everyone is on the same page about how things work and the best way to execute. As problems arise, they can be solved together by people with different technical perspectives.
The result of changing our habits
Now that teams have team members with multiple functions, everyone is more aligned. With cross-functional teams, we are more focused, improvements happen much faster, and deciding on priorities is easier.
Another benefit to this new style of working is that it supports creativity and teamwork – two of our core company values. Cross-functional teams encourage more collaboration and creative problem-solving together. Team members can challenge each other’s decisions and work together to find the best solution, improving the end product.
Summing it all up
Adding cross-functional teams to our process is just one example of how we’ve had to analyze, challenge, and improve our process as a growing business. Will there be more challenges and changes? Absolutely. Will our experiments always work? No. We’ll have to analyze, challenge, and improve again and again. What’s important is that we take on new challenges with a willingness to learn and improve so we can continue to grow our business in the future.