Early career developers
Almost all of our colleagues were in their first job after university. I consider this one of our greatest achievements, and it fills me with pride to see how they have progressed so fast in their careers.
It was a deliberate choice, and our reasons were very much of their time and the situation in which we found ourselves:
- Without investment, we didn’t have a huge amount of money at that time, and an excellent first salary is a lot less than an average salary for someone with 10 years of experience.
- They wouldn’t have any bad habits, which was particularly important as we were using server-side JavaScript, which (before node.js) was just something people hacked together on web pages.
- If we can make it possible for people early on in their career to be effective, just imagine what someone with lots of experience will do.
- We have a responsibility to the next generation. New developers need to start somewhere, yet other companies only seemed to want “experienced” people.
It worked so well that we never reconsidered, and kept on recruiting the best early career developers.
Our choice had many implications. We made this work through a combination of principles and actions which worked together, enabling our colleagues to reach their potential as quickly as possible:
- Our company was designed around learning.
- Our technology was designed to be easily learnt.
- We recruited people who wanted to learn.
- A supportive onboarding process enabled new joiners to be productive in a couple of weeks.
- Our processes meant mistakes were caught before they caused problems.
Everything in that list is a great idea for a software company, even if we didn’t have such a high proportion of early career developers. Making the company work for people new to the profession will make it a more effective workplace, and better for everyone. Even if they have years of experience.
A learning company
Our colleagues had a huge amount of potential, but not the knowledge gained from years of doing the work and learning how technology is used effectively.
Therefore, we built a supportive workplace which prioritised learning. As well as the specifics about our tech stack and applications, we taught the fundamentals of software engineering. If you get the basics right, they can be applied to anything, which means you can learn really fast.
Easily learnt technology
We had a unique tech stack, given the problems we were solving and the long history of the company. We were therefore in a position to shape the tools to fit the way we worked.
We build the Haplo Platform with these principles in mind:
- It should be hard to make a mistake. For example, there are many subtle ways you can break the security of your application when generating HTML, so we created HSVT, an easy-to-use templating language where these were syntax errors or simply couldn’t be expressed.
- The easy thing to do is the right thing to do. The APIs and the way you construct software should guide you into doing things the best possible way. We specifically designed them so that there was friction if you wanted to go outside the recommended path, without getting in the way of expressing unusual requirements.
- Prefer declarative APIs where you pass in data structures saying what you want to happen, rather than writing out the steps each time.
We found that this allowed us to help new developers to be productive very quickly. But it also proved effective for more experienced developers: an external software team was able to scale up quickly by hiring experienced developers to extend their Haplo applications.
Recruitment principles
Our recruitment process was designed to identify new colleagues who would excel in this environment. We looked for people who:
- wanted to prioritise learning new things in their career,
- had a basic familiarity with programming,
- were a strong communicator (but not requiring English as their first language),
- and were comfortable exploring unfamiliar topics.
We had a very high acceptance rate of our job offers. This was because we made it very clear how Haplo would help them achieve their goals, even if it was going to be a hard job. In particular, we made some promises to them:
- to give them the best possible start to their career,
- to teach them the foundations of software engineering,
- to give them responsibility as early as possible,
- and to support them in planning their career for the long term.
Of course, our colleagues needed to be active participants in this process. Those who advanced very quickly were those who took advantage of the opportunities and were deliberate in their choices.
The importance of onboarding
The onboarding process was critical to the success. By offering structured support, proactive guidance, and increasingly challenging projects, we enabled new colleagues to contribute quickly, and learn fast.
This onboarding process became more deliberate and considered as we grew. Early joiners could learn simply by being part of a very small team, and there was plenty of “easy” work to do. But later on, there was a lot more things to know, and the work more complex.
So, we thought about what was actually needed to do the job, and created a series of onboarding sessions. These interactive sessions covered the products, market, and of course, the code, with plenty of opportunities to ask questions.
The most important thing was that everyone understood that the time we spent helping a new colleague was an investment. Any time we spent answering a question, no matter how trivial it sounded, enabled them to help us sooner. Because we gave this help freely and respectfully, we would quickly have a new colleague who made everyone’s work easier.
Safety by expecting mistakes
It’s not very effective to avoid mistakes by relying on “experience”. While there are humans writing software, mistakes will be made, no matter how many times they’ve done this before.
When your team is talented, but fairly new to the profession, you can’t rely on experience preventing mistakes. This is a good thing, because it forces you to put in place technology and processes to catch mistakes before they get anywhere near production.
We did this through carefully designed technology, and two levels of review.
Firstly, a review of the proposed design. This was very lightweight, and didn’t hold up the development. We documented a large number of “approved” design patterns, and a typical design review would list the patterns to be used and be rubberstamped by the reviewer. Anything outside that would be more extensively written up and reviewed, but even so, you were permitted to start work before the review was complete.
Secondly, we did a more conventional code review before anything was merged or released.
If a mistake got through all this, it was seen as a failure of process, and we fixed the process.
The whole point of this was to make it safe for everyone to be able to contribute to all parts of our work. This meant we could give responsibility early, knowing that any mistakes would be caught, which enabled our colleagues to progress in their career even faster.
Most importantly, it enabled us to get out of people’s way when they were doing well, building a team of leaders.
How this can go wrong
This strategy enabled us to recruit the best colleagues who became the leaders we needed. It does, however, rely on all the components being in place. Missing any part would cause quality problems.
In particular, it needs to be safe. The technology and processes need to allow someone to learn by doing real work, safe in the knowledge that if they do something wrong, it won’t cause any problems. And it needs to be a supportive and psychologically safe environment where there is no downside to someone learning by making mistakes.
We built Haplo in this way from the start, and I freely admit our strategy was a bit extreme. From my experience, I would not try and retrofit this approach and expand an existing team entirely through early career developers. Instead, I would use this experience to gradually expand the areas in which early career developers could contribute and learn.
Good early career developers relish the challenge of early responsibility, but also want to learn from more experienced colleagues. While there was plenty to learn from those who’d been at Haplo longer, we didn’t have many colleagues with experience outside Haplo. We had hoped to make up for this by engaging experienced specialists for short projects as required, but didn’t manage to do this often enough.
It is possible to give someone too much responsibility by letting them be too independent. Software is written by teams, and individuals do their work supported by others. Any responsibility must be matched by support from colleagues and processes.
Our approach would have worked better if we’d had more professional services colleagues to take some of the burden off the tech team, such as project managers, implementation consultants, and product managers. In hindsight, we were expecting too much across too broad a range of responsibilities too early, and you had to be a generalist to get the most out of Haplo.
The Haplo approach relied on recruiting really good colleagues, the sort of people who would learn things the first time, and then apply them quickly in novel situations. To recruit people like this, you need to have a compelling offer for them, and in the recruitment process, show them that you’ll deliver everything you promise.