In this blog post I’m going to cover how we are scaling our engineering department at Leaseweb: where we started, the lessons we’ve learned, and how we are hoping to move forward.
Leaseweb was founded in 1997 and we currently have over 350 employees throughout the world with the majority working at our headquarters in Amsterdam. The engineering department currently has about 100 employees and manages 65,000 servers in seven locations (with more to be added soon).
In the past development was based on shifting priorities rather than planned business cases. Developers weren’t able to concentrate their efforts on thoroughly building, testing, documenting, and presenting a demo for one project before another more urgent one was moved to the head of the line. Operations and Development were working on different schedules and weren’t able to meet each other’s requirements to their mutual satisfaction. We wanted to change this.
Set goals
The development department had already been doing some aspects of agile in the form of scrum but the problem was there was no one coherent scrum in the company. Everyone had started at different times with scrum and teams were working on different sprint numbers so that no one knew when a feature would actually be done. In order to address this confusing situation and to become more agile and more productive we decided to set some goals:
- Fully autonomous teams that are empowered
- Predictable development
- Priorities based on value for the company
- Transparency on development/roadmap
- Responsive organisation based on market needs.
Once we had set our goals we had to convince the company that this would be the best way to move forward. We had two competing mindsets: ‘we need to be ready’ vs ‘let’s get started’. There was friction between the two and initially we started to plan and prepare but halfway through an executive decision was made to move forward with the change.
Engage and empower teams
The first thing we wanted to do was engage the engineering teams. We came up with a simple way to boost creativity by organizing a quarterly hackathon. For two full days every quarter engineers would have to opportunity to build whatever they wanted and this could be something personal or work related, there are no restrictions. The event starts off Thursday morning with a kickoff where everyone is invited and everyone gets a t-shirt. People then go off and work on their projects until the evening where we take a break and do something fun like laser gaming or trampoline dodge ball. At the end of the two days the engineers are able to demo something they are proud of and a prize is given to the best developer.
What we noticed coming out of these sessions was that engineers were able to work on projects that weren’t getting management or department support until they had the chance to do a demo and show exactly what they had in mind. Many times the engineers were given the green light to finish the project.
The next thing we wanted to do was to empower the teams. We did this by making the entire team responsible for their own product from development to production. We also set up an on-call rotation within each team. The result of this was to make the engineers care about the product and want to fix it so they aren’t woken up in the middle of the night. Also, we wanted to ‘eat our own dogfood’ where each engineer could choose a product whether it be a virtual server or an actual piece of hardware so that they can play with it and give feedback.
Streamline goals and define done
We also developed a maturity model for teams so that we could get everyone to a standard level and have everyone working the same way. Sander Poelwijk goes into detail about this model in his blog post.
In order to get teams to be responsible for their projects you need to have a definition of done. This is a document created by each team and is a checklist you go through so that nothing is considered done until all the boxes have been checked. This could include logging, monitoring, does it have documentation, a successful build, review from team members or cross training. Whatever is needed and it is different for every team. If they launch a product and something goes wrong they go back and update their definition of done so it doesn’t happen again.
In the next part I’ll go into detail about we use Scrum at Leaseweb as well as how we identify our goals and develop products from planning the business case to staging a demo.