Developing Engineers At Redbubble
Maintaining a culture supportive of growth and learning
Software Engineers are an interesting group of people. As maker of things, we always strive to work on the next big opportunity. We learn a new technology with the hope of using it day-to-day. We are looking for new, exciting projects to work on.
This is in big parts driven by our desire to learn and improve. Great companies fuel this passion by providing an environment where learning is part of the job.
However, the environment has to be different depending on the size of the company, its culture and other factors. In a very small startup, it is quite reasonable to have a share everything policy. Bigger companies will need to approach it in a more structured way.
Redbubble, The Startup
I joined Redbubble about 5 years ago, when there were less than 10 engineers in the team. Learning has always been a big part of the culture. And our approach was to share as much information as we could. Most of the time, this happened in public channels — like chat and email — or in all-team meetings.
This approach worked really well with a small team. It allowed us to jump in and out of projects fairly easy. It was also very obvious at which rate the whole team was growing and at what areas we were learning about.
Time went by, and being a successful startup, meant that we were able to bring on new people. Before we knew it, we doubled in size. We started to see cracks appearing in the way we shared information. This had a direct impact on the development of engineers.
There was simply too much happening for people to keep up. We also split out into different focus areas which meant that the knowledge was not easily transferrable anymore. The outcome was obvious: Sharing of information grind to a halt and most of our initiatives stopped because attendance dwindled.
Learning In A Medium-Sized Team
Earlier this year, we decided we had to do something. Our team size is now about 50 engineers. We have a variety of levels and skills, ranging from true specialists to all-rounders. Only one (quite new) learning initiative was still going. We lost the culture of sharing information and there were few opportunities to grow ourselves at work. We set out to change how we approach the development of engineers.
Forming a Task Force
One thing we always knew — through our focus on it in the hiring process — is that our people are eager to learn and grow. Our learning environment did not falter due to a lack of trying. Lots of people were starting initiatives over the years, only to shut them down soon after. What was missing is a coordinated effort to set us up for success.
To start from scratch, we formed a small task force. In it were engineers with a spread of skills and experience to make sure all areas of the wider group are represented. The brief for this task force was to re-think how we can structure the development of engineers. That was it. No artificial goals or metrics set from the outside. The idea was to have the task force work this out themselves.
Vision and Metrics
And so we did. Over a few sessions, we managed to come up with a vision, a goal for the year and some metrics. At the top level, we want to
Establish a culture of continuous learning and teaching, to make Redbubble best in class in growing engineers.
And we decided to measure success through a series of surveys, containing a self- and peer-assessment part. Here are the key questions we ask:
- On a scale from 1 to 10, how would you rate your personal growth?
- On a scale from 1 to 10, do you consider Redbubble an environment supportive of development and learning for engineers?
The results for the initial survey were — as expected — pretty bad. On both questions, our NPS score was worse than -30 (i.e. more than half the people are not able to learn the way they would like).
Effective learning initiatives
The good news was, the result of the survey confirmed our assumption: We have a group of people who are eager to learn. We also have lots of knowledge worth sharing. What is missing are channels in which the knowledge and skills are transferred effectively.
We still believed in learning initiatives driven by engineers themselves. But we decided to put some structure around it by asking a few key questions of the organisers:
- What do you want to achieve?
- What does success look like? How do we know we’re reaching our goals?
- How will it work?
For starters, this ensures we are really thinking through the ideas. Instead of trying something and hoping that it works, this will weed out unpromising initiatives. Either because we do not have enough interest from engineers or time to run them.
More importantly though, by asking organisers for their goals and metrics, we can evaluate the success on an ongoing basis. Once a quarter we then figure out whether we want to continue, change or stop a learning initiative. This ensures we have an extremely relevant and up-to-date pool of growth and learning resources.
Software engineers are always eager to learn and improve themselves. Great companies support this by providing an environment which makes learning part of the job.
At Redbubble, we had to rethink our learning culture due to our team growth in recent years. We put some structure and support around our learning initiatives. This allows us to match our engineers up with great and relevant knowledge resources, even as we scale.