What are the challenges when scaling a dev team from one to two?

Question

I work for a small-medium sized startup with a development team of 20 people and a very strong engineering culture. Engineering itself is split into smaller sub-teams and I am the only person responsible for a particular component (which is quite critical to the whole organisation).

We have now finally managed to hire another engineer to start working with me, which is great and will help me a lot, but comes with the inherent challenge of moving away from a solo dev team.

What are some of the challenges that exist when adding a second engineer to a team? I've already had a look at this question where the accepted answer suggests having a good onboarding process but doesn't really go into the details of what that actually means. I'm more interested in understanding what kind of things I should change on a day to day basis to make sure that this transition is a success.

Answer 1

Essentially, it all comes down to communication.

If you're the only one working on a project, you don't necessarily document the project the way a team would do it. Either you don't write documentation at all, believing that you will remember everything two years later, or you do it from your own perspective. This creates several challenges for the newcomer:

• Formulations which may be clear for you may not be so clear for another person.
• Assumptions may be completely undocumented. For you, those assumptions are natural. Another person may not find them natural, or may consider them completely wrong.

• Choices that you did in terms of design or architecture may not be clearly documented, because you were the only one taking those choices. When a choice is made by a team, it is discussed, and from the discussion, it is relatively easy to write documentation explaining why such thing was done in a given way. You likely didn't have a discussion with yourself, so you probably documented just the choice itself, but not the reasons of the choice.

• Things which are obvious for you in the code may be left undocumented. If those things are all but obvious for another person, that's a problem. This may happen, among others, when you know something other person doesn't know. For instance, if you're amazing at reactive programming, but the other person is not, he would expect all reactive expressions of more than two lines being documented, while you absolutely don't see the point documenting something which is so easy to understand from the code.

Additionally to that, the newcomer will be faced with one more difficulty:

• Historical elements. Your project evolved because of the events which happened at some point. You know that, and therefore there are a bunch of things which don't require any explanation for you. You know that you used XML instead of JSON because that other service had a buggy implementation of JSON serializer and it made your production crash on the New Year's Eve two years ago. But a newcomer knows nothing about this traumatic event and may believe that there is no reason to use XML, and that one can easily switch to JSON.

Your goal, therefore, is to work close with the new developer and to be open to any question, no matter how stupid this question looks to you. The success depends in large part on your ability to answer clearly, and to take time to properly document things which were surprising the most for the newcomer.

Answer 2

In addition to Arseni’s answer: Make sure that all the documentation that should have been available and correct before on boarding is at least available and correct after onboarding. First job for the new person.

You may have to get more organised with code reviews, task lists, deciding who starts what job etc.

Answer 3

First of all, regard everything Arseni already wrote.

Another point I'd like to throw in, is the personal way of doing things: as I assume that you are a human being, you have your style of solving problems and your style approaching your work and your style of writing code.

And up to now, the software has been 100% the way you would do it.

Now, another person will have his style and his approach and so on. You would already be used to coping with other people's approaches, if you had been a member of a 7-person team all along, but you'll have to cope with the project not being 100% you anymore.

So, please don't frustrate the new colleague by assuming that there is only a single way of doing things. Cope with other approaches. Resist the urge to rewrite everything he does to fit your personal way. Only reject solutions if they are blatantly wrong objectively (not e.g. because he uses a loop where you'd use a stream or the other way around.)

Answer 4

It should be clear who owns the product on a technical level. You may have the idea you will get a sidekick to help you get the work done. The other guy may have the idea they brought in a real developer to fix what you messed up. There is little as destructive as suddenly shared responsibility. Going from 1 to 2 is likely the biggest change that will ever occur to the development team. You need clear expectations and technical ownership should be carved in stone.