Our Frontend Guild
Published
How we work with self-organizing teams and keep improving our craftsmanship.
For building user-friendly and appealing digital interfaces we currently have a growing team of about 15 frontend developers and in general, they run their own projects with their own teams. About ten years ago we started getting together every three months for a full day in a conference-like format. We had somebody who made sure we had speakers, prepare a timetable and organize the whole thing. We ourselves did the talks on that day. This way we could learn from each other and set some code quality standards.
This format has changed quite a bit over the years, and this article outlines where we are now in our search for more agility, software craftsmanship and self-organization.
Self-organization
Instead of four times a year, we now get together every other week, all of us frontend devs. We call this the Frontend Guild Day (more on the guild days later). We like to keep the involvement of managers in a guild like the frontend guild as small as possible. That means frontend developers are in charge of their own guild. The self-organizing character of these guilds carries a long way.
Measuring growth and setting the bar
Mirabeau has a growth-focused culture — growth in both behaviour and craftsmanship that is. Personal development is at the center of this thing. Individual growth feeds the development of a guild and the advancement of the different guilds feeds the whole. There is a reason Mirabeau has been at the top of its game for all these years, you see ;-)
We have a simple structure in place through which we measure individual growth. Well, simple in theory, quit a challenge in practice. Remember, no managers. So you are in charge, this means that together with your colleagues, organized in small groups of about four people, you set your goals for the year. With those same colleagues you keep track of your accomplishments during the year and at the end of the year your performance is evaluated by your colleagues, including your pay raise!
In order for us to be able to keep track of one and other we get together with our guild every two weeks for four hours: the previously mentioned Frontend Guild Day. It gives us some time off from the pressure of the projects. We can talk with our colleagues about our guild, about our ambitions, about our successes and failures, to share experiences and learn from each other. But most of all we are there to talk about code, and have fun while we’re at it!
How we go about our code reviews
In our projects we do a lot of code reviews as pull requests, these are cross-discipline; so a C# Developer will do a review of some JavaScript code. This might sound counterproductive, but it’s actually really good for a whole range of things! It improves understanding of a user story from various perspectives, it decreases handover time, and any kind of programmer is good at reviewing your train of thought, whether they have a solid grasp of a specific programming language or not.
For our guild it turned out doing a code review with a group is harder than we thought. Not in the sense of how you explain your solution to a group, but in our ability to receive feedback about our brainchild. Luckily, receiving feedback is a skill you can master. Code reviews are still done one-to-one in projects, but now we call our one-to-many reviews code walks, and they happen every guild day in the smaller groups.
Good /code (reviews|walks)/ are all about separating the mental model and actual implementation. And then comes the hard part: to shut up and listen. It’s easy to start defending your solution, but the right thing to do is to really absorb the feedback and try to see someone’s perspective. That’s how to learn.
Mentorship
We want to improve ourselves, get better at what we do. Inspired by the apprenticeship model from software craftsmanship, we started a mentoring program. Every two weeks two people get together to dive into some code and feed off each others knowledge. In the beginning the mentor is mostly responsible for determining the vision and topics of the sessions, and when the time is there the mentee will naturally claim a more equal position. These sessions are as beneficial for the mentor as they are for the mentee.
In these mentoring sessions the mentor is responsible for raising the bar. Somebody may or may not have learned in their career what a unit test is and why you would want one. But we like to have our code tested. Same goes for using the full potential of your IDE instead of using a text editor, and many other topics. In the beginning they will touch a lot of different subjects on the surface to get a feel for the personal development path they have in front of themselves. Later on they will go in-depth, to gain true understanding on all the different perspectives of writing code.
The means at which these subjects are learnt best is having a few pet-projects to try new concepts and ideas, and to review the code which was written for the projects they’re currently in. We started doing this because we wanted to learn from each other by talking about code.
This eventually outgrew the frontend guild, and being a mentor or mentee is now a possibility for anyone who writes any kind of code in any organizational unit. We now have around 10 mentors and 30 mentees.