I’ve been in IT for quite some time already and had a chance to, as they say, wear different hats. It was a few years ago - the first time I was given a team. Even though guys had a lot less experience than me it was me who was sweating while meeting them. Managing a team is hard. Especially without prior experience in it. After some time back then I thought I got it. But now not so sure anymore. Last few years I was working with seniors only, but recently I’ve been given a non-senior team member and it’s “fascinating” how many stupid mistakes I’ve made so far. This would be a blog post about my (re)learnings on the hiring matter.
Planning
Prepared means ready. And I wasn’t prepared at all - the first problem occurred at the very first step - initial project setup took far too many hours. Usually, senior devs have “bigger fish to em… fish” and then care about the cold start of the project. It’s a piece of cake for them and they are working on the project already anyway. So lack of proper documentation and/or setup scripts becomes painfully obvious when a new team member (not of a senior level) appears. And, of course, especially hard if new team members haven’t been introduced for quite some time.
Seamless project setup is just a part of a bigger idea - planning. Of course, I should have everything before the new developer’s first day. It’s impossible to plan absolutely everything, but we should plan as much as we can at different scales. Onboarding must be planned, each consecutive week and month should be planned, and meetings should be planned. Doing homework makes things drastically easier.
Documentation
Probably only devs on Mars (hard to say how many are there) haven’t heard the saying “code should be straightforward as possible and the document itself” and “comments are bad in general”. Well, that’s still valid from the developer’s perspective. But the team lead’s perspective is shifted a bit to the business side and documentation is pretty crucial there. I’ve mentioned “comments” just because an average full-time dev usually equals comments to documentation, but I’m talking about a different kind of documentation - from what problem this software you are working on solves to a convention of commits naming. Having that kind of documentation saves a lot of ‘air time’ for other team members - they don’t need to explain concepts over and over again. Don’t get me wrong - communication is still vital, but, at minimum, a lot of far too trivial questions can be avoided.
Also, there is such a thing as the bus factor. What will happen if developer X will be hit by a bus? Will the project go on? How easy it would be for new developers to work with the project if there will be no other devs to do the explanations? Documentation is for that too.
When is a good time to write documentation? Now! Bit by bit. But, I must admit, - the best moment for writing onboarding documentation is right after new team members have arrived - you just follow the hot trail.
So, another take of the article - form a habit of writing high-level documentation little by little each week. Try to be concise and informative.
What exactly team lead is responsible for
Dunno how about you, but I thought that the team lead should try solving every possible problem of team members. Why is he there after all? If he is always needed and solves problems nicely then he is worth the money he gets, right? Wrong.
There is a very nice book by Roy Osherove - Elastic Leadership. It gives a nice theoretical introduction to team lead responsibilities. Here is an example of a dialog from the book:
- team member: I have an X problem.
- team lead: what did you do to solve it?
- team member: what do you mean? I’m telling you about it. Shouldn’t you solve our problems?
- team lead: you should learn how to solve problems on your own.
At first sight, such a team lead seems pointless. But in reality, this is what ‘Yoda-type of level 9000’ team lead sounds like. Main responsibility of a team lead is to enable the growth of team members and to teach them how to be self-organized. The best state of a team is when a lead is just staying out of team members’ way when they are doing their job.
By the way, there is much more in the book and I definitely recommend reading it.
Summary
There you have it - my musings & 3 (so far) (re)learnings on a hiring matter (when dealing with juniors) - plan, document, and strive for self-organization. It is refreshing having a non-senior team member - for me, it turned out to be not “riding a bicycle”.
P.S.
But for the article to be honest and full it requires one more fact. Have you heard the saying “hire slow, fire fast”? I’ve heard about it. But still that time we hired fast. It just didn’t work out. And to be consistent we didn’t fire fast - we were very serious about testing “hire fast, fire slow” (sarcasm, cap). So in the end it was kind of “fire fast”, but only after a point where it was obvious that it was “far too late”.