‘Graduated!’ by Ralph Daily

One day I received a phone call:

“We’ve just hired a highly experienced developer who can join your team next week. There’s one catch though, you’ll have to give up your new graduate developer. What do you want to do?”

To give you some context, this took place in a consultancy. It’s normal for developers to spend 6 months to 2 years at one client gig then move onto a new one. These sort of conversations happen all the time, but this one is different. The budget stretched to a certain size, and to get the new developer, we’d have to sacrifice the graduate.

This team had been going for around two years already. Full of experienced senior developers and some developers with a few years experience. Yet, during that whole time we’d never had a graduate on the team.

This was a large team, and I hadn’t spent much time with the graduate to figure out their mindset and impact since they’d been there for just two weeks. But here I was on the phone with pressure to make a decision straight away. The new experienced dev could be on the team within days if I wanted, and the graduate would be going back to head office to work on our corporate website instead.

With lives at stake and not much time I decided to stall:

“Wow, that’s a great opportunity. Please give me a three days to think about it and I’ll get back to you at the end of the week”.

What to do next.

Whenever I’m posed with complex questions like this I seek out advice from my mentors and other folk I respect. Every one I phoned gave the same answer:

“Take the strongest team you can get, it makes your job easier”

It didn’t look good for the graduate. But I wasn’t about to take that advice straight away, the team was already strong, so I decided to spend the next two days with the graduate developer, figuring out what they are about.

When I’m considering graduate developers I’m looking for three traits:

  • Energy
  • Enthusiasm
  • Desire to learn

After spending an hour with the grad I could see they had that in spades. But then I noticed something which I didn’t expect to see or go looking to find. The grad was having a cultural impact on the team. Before they joined only the senior developers were answering questions, but now all the other developers were getting a chance to teach and coach.

Crucially the grad was asking ‘why’ are we working this way. That gave opportunities to coach, but also it shined a light on some old assumptions which were no longer valid. The team had forgotten that we worked a certain way because of a constraint that no longer existed. I remember this working effectively when one ‘why’ question ended up in us being able to release to production 30% faster then we could before. That was massive for us.

By the time Friday had come around I knew my decision. I thanked our staffing folk for the opportunity but I’d like to stick with the graduate developer instead.

You are probably asking yourself a question now: Should I take on a graduate developer?

Don’t worry, I’ve asked around and got this question covered for you:

It depends – [All consultants]

It’s the only honest answer sorry. But I think it depends on two questions:

  • How strong is your team?
  • What is the culture like?

On a team of strong developers you still have some disparity between them, meaning most of the coaching opportunities are going to one or two individuals. If this is your situation you want to consider what the culture is like on your team. Would you like to give those opportunities to your other developers?

Are folk still asking ‘why’? Are you challenging your assumptions, rather than saying “we’ve always worked this way”. If so then you will benefit from having a graduate come in and improve the culture there, cleaning away some of the pessimism with an optimistic personality.

Again though, if you don’t have a strong team, you might want to avoid adding more inexperienced developers. I’ve once made the mistake of hiring too many graduates into a team at one time. The culture suffered resulting in cliques, escaped defects and ineffective communication.

You might choose to hire a graduate now, but whatever you choose to do please remember this:

Whenever you add or remove a person from your team. You have a new team. The previous team is gone.

Each person brings principles, practives and role specialisations. When they leave the values of the team change. How the team likes to work changes, how they communicate will change. The change is not always for the best, but if you watch your teams culture then you can make better decisions about who to bring into your team next.