When I joined Wix in 2010 my job was to rebuild the back-end engineering team. The previous team that took the company to where it was back then was scattered to other projects and except for one developer from the original team I had a completely new team.
A couple of months after I arrived and started to figure things out with my new team we decided to move to continuous delivery methodology. Since we faced many challenges in both moving to continuous delivery and the need to re-write the whole back-end system, we needed very good software engineers to build a new framework and to be the first ones to lead the company's Dev-Centric culture.
We wanted to create a culture based on quality in terms of software engineering and people responsibilities. Since every person in a growing company has a profound effect on the company's culture, it sets the tone for the recruitment process. Ever since I got to Wix I have never stopped recruiting engineers, however recruiting is a big challenge. I was looking for exceptional software engineers. The standards for passing the interview process is very high and very few actually succeeded, but that is a price I’m willing to pay in order to build an "A team".
The interview process
Our interview process had two technical interviews. One by myself and the second one by our chief architect. In addition to that a candidate also had two more interviews with HR and VP R&D. After a while we changed the process a bit to include a written test on a computer as part of the second interview, where a candidate needs to solve and write a program on a computer just like he would do at work. It is very important for a candidate to write code because we saw many times that even though candidates can talk the talk, when it comes to actually writing a code, which is the job they are expected to do, they cannot do it even after they know the solution to the problem and explain to us before they write the code what they plan to do. Sometimes when we see fit, a candidate can choose to have a pair programming session with one of our developers instead of the written test. A candidate can be dropped at any stage by anyone who saw him. We learned the hard way that every time we had a doubt about a candidate and decided to give him or her a chance it did not turn out well.
DevOps Culture
As part of continuous delivery culture change, developers were expected to do DevOps and for that we had to make our production environment visible. So we put big LCD screens in all the rooms and developers could finally see in real time how their application behaves on production. On the monitors we see the application exceptions application performance and also system metrics. Once the developers see this data live they started to fix and improve the application based on data they did not have before. They fix errors, improve the application performance and make the system quality much better.
Daily Meetings
Quality also affected our daily standup meetings. Instead of talking about “what I did yesterday” and “what am I going to do today”, in our daily meeting we discuss production issues we solved or encounter, interesting engineering problems we faced and enhancements suggestions we need to make to our framework.
Quality Thursday
Everyone will agree with me that software engineering is a craft, however in most companies I've been there is almost nothing being made to improve the engineers craftsmanship. In order to do just that I initiated something I call Quality Thursday. A software engineer works 4 days on his project with his project team, but on Thursday all back-end developers stops working on their designated projects and conduct quality enhancing activities.
Bug Hunt (one hour)
We start every Thursday with a weekly meeting and a bug hunt. We pick a service running on production and the service owner goes over our monitoring system in front of all the developers and explain each and every exception the application throws in production. For each exception we discuss if there is an action item associated with this exception in order to eliminate it. At the end of this session the service owner goes with a list of action items to fix the service. This process does not just improves the quality of our services but also teaches the other developers about services they do not own.
Retrospective (1 hour)
During the week developers encounter issues they would like share and to open for discussion with the rest of the group. We write these topics on an internal message board (daPulse) and it sets the agenda for the week's retrospective. In the retrospective we discuss both issues and lesson learned we had during the week and also suggestions on how to improve our team, quality, process and effectiveness as an R&D organization.
Presentation (1 hour)
The third hour of Quality Thursday is dedicated to a lecture. Every developer (in turns) presents a topic he is an expert of. This creates a knowledge sharing cross teams and cross people. The topic can be technical, present a new project or any other topic the developer is passionate about. Sometimes we also invite people from outside of the R&D to talk about what other departments in the company are doing. These talks are not limited to the back-end group. We opened a meetup group that all the people in the R&D are members of, and publish the week's topic. Anyone from the company who wants to join and listen to the talk is invited. This also creates a knowledge sharing between groups.
Thursday Tasks
On the second half of the day developers do not usually work on their own project. We have what is called a Thursday task. A Thursday task is a technical debt or small task (up to two days of work) with relatively low priority. Every project have these kind of tasks, that usually do not get done because lack of time and priority. On Thursday we actually do these tasks, but it is not being done by the developers who work on the project on a daily basis. These tasks are being made by other group members who work on other teams and projects. By letting people do tasks on projects they do not own or know serves several purposes:
Developers learn other projects, and by doing that can help out if needed and already be fairly familiar with projects they do not own.
External developers look at a code they are not invested in and can reveal issues or suggest improvements the people who work on the project daily missed.
Developers learn about problems and solutions other teams faced and solved. This way in case a developer encounter a similar problem what was solved in another project he will know who to consult with and will not have to re-solve the same issue that was already solved by others.
Find repeating patterns cross projects and move it to the framework if it is common enough.
May find interesting projects they may want to move and work on permanently.
Leave the code in a better shape than they got it.
As part of Quality Thursday developers also do one on one mentoring with other peer members with specific expertise. Also developers are encouraged to read and learn new technologies or even work on their favorite open source project.
Quality that drives innovation
Since engineers have one day a week where that are not racing to push products out this gives them time also to innovate. “Quality Thursday” is a drive for innovation. All the activities from bug hunt, retrospective, tech talk and Thursday tasks are a catalyst for discussions and ideas from the whole group. We have done many innovative things based on ideas we discussed on Thursday.
I strongly believe that in order to have better engineers you need to invest in enhancing their quality and craftsmanship. By investing in your engineers you will get better products and better productivity.