Building Rapport with a Team of Junior Engineers

Question

At a past job, I started working on a team of all senior engineers and did some great work. Management recognized this and asked me to join a team of, mostly, more junior developers to help guide them (without being made a manager).

Unlike my old team, they hadn't yet established a protocol for how their code reviews or standups would work. They had no formal leadership structure, as the manager was also fairly junior. Interestingly, all 5 existing members of the new team were close friends outside of work.

I thought my job would be to write quality code that could help lead by example. But as time went on, I noticed that getting code reviews signed off by the more junior team members happened slowly, or sometimes not at all. It got to the point where they were making comments on my code that were seemly innocuous, I'd obligingly make those change, and then they'd make more suggestions, with the review never finishing because there was no protocol for that.

Over time, comments on reviews would pile up and management would get concerned that tasks were taking too long. I eventually escalated up a couple of management levels and red flagged the situation to get them moving. However, I feel that this was a missed opportunity to try and convince these engineers to work with me without needing to involve senior management.

Later in my career, I find myself in a similar situation. I'm again being asked to help guide a more junior team of engineers (without being made a manager) many of whom are close friends outside of working.

Since they'll be the ones approving my code reviews, I want to make sure that I can build good rapport with them. What steps should I take to accomplish this?

In the past, I've tried team lunches and team building events, but these seem to have short lived effects and don't really build the kind of team dynamic I'm looking for.

Answer 1

You can't join an established team and start dictating terms. They'll see you as an outsider, and worse, someone they can't really connect to.

If management wants you to be a mentor for these guys then they need to give you the authority to implement certain procedural changes. Perhaps, after a few weeks of observership you could take your recommendations to the team manager, and with his support, implement the new processes.

However, there needs to be an explicit agreement between you and management that you will have their support in implementing these changes, and that they will follow your recommendations.

Perhaps you could be introduced as a technical expert assigned to review the team's processes and "enhance" them. But as "just another dev" your word won't carry much weight against the established team order.

Answer 2

Without a correctly defined role, you're fighting an uphill battle. Get that first, with or without a manager definition. Then define the coding and style standards that everyone will be working to, including yourself, and open it to discussion. Once everyone agrees with the standards, code reviews should be measured against those standards. You're there to be a mentor, not to be their newest best buddy.

Set review points where you meet as a team and discuss the code moving through the system (or not). If you're using Agile, this would generally happen after a sprint deploy. Have a project manager chair the meeting, so that you're not both driving the meeting and being the target of discussion (if that's the case).

The best way to build a great team is to do great work together, and be recognized for it. Cater lunch after a successful deploy, and give gift vouchers occasionally for great efforts. For many people, especially introvert developers, 'Team Building Events' do exactly the opposite.

Answer 3

My suggestion is on the assumption (I know, dangerouos to do...) that the team know you are there to help with these processes. If not, you'll need someone from management to let them know that you have authority to review their processes. (Note, not manage them, just review, from the outside).

I would suggest you need to do something like the following:

1. Establish Code Standards. They may already have these in place. They may not. The exercise in establishing these is a group one. Establish what quality controls you want in place. This needs to be definitive, so no open ends or anything like that.
2. Establish Code Review process A code review should be a finite task. Either the checkin met the standards, or it didn't. Establish the procedure with the team. You aren't their manager, you are their equal (with some valuable experience). Again, involve them in fleshing out how your code reviews go. Set a script if you need to, a checklist to follow. Whatever your group agrees is needed for an efficient code review.
3. Lead By Example Once you have the Coding Standards and Code Review processes in place, start using it. Champion the practices that your group have implemented. If you can, ensure there is always time to code review. Praise people when they perform code reviews. Praise them more when they re-review code and it meets the standard. If your work gets reviewed and needs improvement, thank them for pointing it out. Code Reviews are there to make people better developers as well as ensure code quality.

Ensure these are their processes, not your processes. You will get more buy in and be more influential if you get the group to implement structures that they are happy with. The structures will avoid the endless review (if the structure is created correctly), the group method of creating them will ensure buy in from your colleagues.