How to build a self-sustaining development team

by Francesco Cesarini

This is an excerpt from The route to the successful adoption of non-mainstream programming languages by Francesco Cesarini and Mike Williams.

So you’ve already built the prototype, failed forwards, and secured approval to move on with engineering the final product. It’s vital that you keep the team that built the prototype and use them to mentor the new recruits. In doing so, you need to make sure your team becomes self-sustainable.

It is best if the mentor can sit next to the new recruits, communication needs to be quick and efficient from both sides. As members move to new positions or get assigned new POCs, you need to be able to replace them, be capable of mentoring the new joiners, bringing them up to speed.

Our philosophy is to work with internal teams to grow the team’s skills, knowledge and capabilities. Create an environment to grow and foster the mindset for success.

If you are a small company, a minimal team should consist of 4–5 people.

If you are a large company, 10–12 developers and up.

Not everyone needs to be using or developing in Erlang, but they should be passionate about it, be able to jump in and be productive at short notice, and be capable of rotating other team members out.

Transferable skills

It is always a mistake to advertise for programmers with experience in the language you are adopting; you want good and experienced open-minded software developers who understand different programming paradigms and approaches. They do not need to know the programming language, but they should be capable of understanding what is meant by using the right tool for the job.

Erlang, you can learn easily. Good software practices, less so.

If you acquire a company, you will get a pool of great developers who already have the domain knowledge. Back in 2004, a company in Silicon Valley was advertising for Erlang developers with at least a decade of Erlang experience. They had adopted Erlang as a result of an acquisition at a time when there were maybe 20 developers in the world who qualified (including the authors of this blog).

Ironically, that company used to employ another ten, but had just shut down their Swedish operations, making them redundant. Don’t get too hung up on location. Focus on talent and productivity.

A team that grows with you

As your software project progresses, the focus of your work will change, at the start your focus will be on developers with good architectural and programming skills; later on configuration management, verification and testing; then deployment, operations, maintenance, and documentation.

Build a team of developers who can embrace the skills needed across the whole of the development life cycle.

You should avoid different people for each category, rather you should have people who themselves can embrace the skills needed for the whole of the development life cycle. Handing over knowledge from person to person is error prone and costly, when a person works across several areas this can be avoided.

Cut out the bad habits

Learning Erlang/OTP is easy, as it is a very compact language and framework. The difficult part is unlearning other programming language models and getting rid of the bad habits they bring with them.

This is where mentorship and code reviews become an essential part of the process. Review all code, not only code in the application itself but test cases, simulators and tools.

Code reviews should be led by experienced developers focusing not only on quality, style, and documentation, but also on educating developers on the system as a whole.

New recruits often get up to speed fastest when making changes to existing code. Be cautious and review new code written by new recruits carefully.

Ericsson did a study in the late 90s looking at the productivity of graduates and experienced developers in large projects after they had attended Erlang and OTP training. They concluded that a graduate straight out of university became productive after about a month, as they could easily pick up new programming models and handle change.

It took an experienced software developer who attended the same courses three months. They picked up Erlang easily, but had to spend more time unlearning their previous programming paradigms and embrace the Erlang way. Code reviews and mentorship in this phase were critical. When we say productive, we obviously mean productive in their respective levels of seniority.

Invest in training

When building your team, do not underestimate the value of training and study circles. Where there is significant change being effected within an organisation, there must also be adequate training and support provided to the those impacted, with an effective feedback path to ensure that issues with change do not turn into objections and resistance.

We often see companies give their developers a book hoping they will become productive. Why not? They are smart, well paid, and as a result, should be capable of picking up a new language on their own.

It might work for polyglots who have used other functional and concurrent programming languages, but never, ever, take it for granted. If you want to save money and get your developers productive quickly, invest in a proper training and mentorship, especially if you are ramping up a team of ten or more developers. It will allow them to quickly understand and embrace the new programming paradigm and reduce beginner mistakes.

If you go down the book route, don’t be surprised if the project runs into trouble. By being penny wise and pound foolish, you’ll scare away the Erlang/OTP experts, as they’ll burn out spending all their time refactoring and debugging bad code with no time left over to mentor those who really need it.

And remember, stakeholders outside of your core development team will need training to sustain the excitement and investment in the project. A tactic that has worked for us in the past is “boot camp” training; we’ve seen it create the right mindset and understanding of “change tools” within change leadership teams.

Erlang is just a programming language. That’s the easy part. Learning the application domain is probably the hardest task of any software project. This is where the vertical subject matter expert needs to come to the rescue.

Learning a programming language is the easy part, never underestimate vertical subject-matter expertise.

Accept the fact that you will have to train your new recruits in Erlang and maybe some of the other technologies you use, but also accept the fact that they might not be vertical subject matter experts. They might be shipping code after a few months, but it’s going to take them much longer to learn the necessary domain expertise.

Plan and act with long term adoption in mind

If you work for a large company and inherit a team, remember that you can’t force them to use technology they don’t like. If you are going to use Erlang/OTP or any other non-mainstream language, make sure the team understands the advantages and benefits, and receive the right onboarding.

One of the main reasons for projects moving from non-mainstream languages is their inability to make the team self-sustainable. Not having a recruitment pipeline and losing key members of the team puts pressure on the other members.

A key aspect of these kind of projects is changing individual mindsets and transitioning from established ways of doing things. This involves creating energy and enthusiasm by showing the way from small safe incremental steps to the new operating model. Incremental is key. I have seen the pace of change play a crucial role in change adoption. If there is too much change then teams can feel overwhelmed. It can turn a “change advocate” into someone who is passive or worse, actively resisting change. This behaviour can also be triggered if change creates more work or duplication.

The Kübler-Ross Change Curve is a powerful tool to understand where people are on the change journey. Those driving change will be further along the change curve than those who have change forced upon them. Prepare a toolbox of techniques to help trigger and stimulate movement through the change curve. For example, “town halls” as a vehicle for ensuring that objections to change are aired so that objectors to change do not get stuck in the “denial” region of the change curve. Remember: projects where the right tool for the job is used will often consist of multiple programming languages. Not everyone is expected to work on Erlang, but they should know it well enough to be able to help out when necessary. Don’t freeze out the naysayers, you may need them down the road.

Join the community

Take on summer interns and thesis students; this is an excellent way to evaluate developers. When they graduate, they might join you. Present at conferences and get your name out. Where possible, if there is a fit with what you are doing, join academic research projects. Your costs are often covered through grants.

If you are a large corporation, provide regular courses open to everyone in the company to recruit internally. Run hackathons and study circles and host meetups to generate interest and get a contact network. Use and contribute to open source projects, and where possible, release and maintain components others might find useful. Those who see what you are doing out of curiosity and like what they see, are likely to join the team when an opening appears.

† Shameless plug — I have co-authored two books on Erlang — Erlang Programming and Designing for Scalability with Erlang/OTP.

This is an excerpt from The route to the successful adoption of non-mainstream programming languages by Francesco Cesarini and Mike Williams.

Subscribe to Erlang Solutions’ newsletter for the latest Erlang and Elixir news, or contact us directly for more on how to introduce a new technology to your stack.

Originally published at www.erlang-solutions.com.