Specialists are a Pain

Posted on by

Specialists are very useful. They are also a pain. It is great to have the experts around when we need them. But specialists are also add painful management overhead. I accept I have to do it but I wish I didn’t.

I’m going to look at three situations where I’ve had to deal with specialists and explain what I did:

  • Drowning in specialists
  • Front / Back end developers
  • Part time external specialists

Drowning in specialists

I have worked in an highly unionised environment and one of the side effects of this is that there are many specialist job titles. In one department I have worked with job titles included:

  • Information Architect
  • User Experience Designer
  • User Experience Developer
  • Client Side Developer
  • Software Engineer

These roles were responsible for, in order, wireframes, graphical design, html and css, javascript and finally server side code. So the software development workflow had to go through at least five pairs of hands for any user story.

This is not, by any stretch of the imagination, efficient. And the real irony is that the people in those roles knew they could do the jobs of some of the other roles, but they weren’t allowed to. Crazy. But even crazy is workable. Those specialist roles reflected steps in a workflow so I made that visible with a Kanban board and went from there.

Despite the fact you can make anything work more general roles are much better. You are, however, unlikely to find somebody who can do all of the roles above well. But I have, for example, had “front end developers” who were responsible for the user interface from wireframe to html and css. They also sometimes dabbled in javascript as well but tend to leave that to the software engineers. Essentially the front end developers concentrated on the “look” and the design of the “feel” (i.e. behaviour). The software engineers implemented the “feel”.

Front / Back end developers

Despite my hope for universal developers I always find myself with two types: front end and back end. The skills are different and as time marches on the skills gap just gets greater. They are different types of developers.

I could have a process that separated out front end and back end work. But which goes first? My observation is that sometimes the front end is first. Sometimes the back end. Sometimes they start together. And regardless of who starts the card always bounces between the two types of developer. I could try and model that in my process but that would be, well, painful.

So despite that difference in skills I ignore the difference in my process. It makes it less painful. So when a card is in “Development in Progress” I don’t care whether it is a front end developer or a back end developer. The card moves to “Development Done” when both types of developer are finished with it.

Part time external specialists

Then there are the part time specialists. You’ve got a team of developers but every now and then you need a skill that isn’t in the team. For example, you need a UX person occasionally. Or you need a database expert at certain times. They are a scarce resource, kept in a central pool, and you have to go begging to get hold of them. That is a pain.

Generally I try to become self-sufficient in these skills so I don’t have to call upon the central pool. There are a few things I recommend trying:

  • Make do with a lower level of skill. If the scarce resource is UX I’ll try to get enough UX expertise in the team to get by without a specialist. This is more possible if the system already exists and the developers are just producing “more of the same” in terms of UX.
  • Use existing skills in the team. You can find that people on your team already have the scarce skills – they might be as good as the specialists. For example the tech lead often has adequate database administration ability.
  • Hire your own. In one case I ignored the central team and hired two specialists to be full time on my team. Happened to be UX folk. Ironically this suited the central UX team as they were already busy and my project wasn’t interesting to them.

But often I don’t have a choice and have to use those externals. In this situation I try to use them in a way that doesn’t slow down the team. Normally that means including the specialist’s intervention as part of the heartbeat. For example

  • One of my teams has a part time UX guy who is available on Friday. The team makes sure anything with a critical interaction goes to him before the developers get to it – but it has to happen on a Friday.
  • In another case one of my teams had a strong interdependency with the business intelligence (BI) team. Most of the features coming out of my development team had an impact in BI land. BI could block my releases. So we agreed that when tickets got to a certain point in the development process then BI would start the work to handle / process / accept the ticket. We brought that point as far forward in the development process as we could. The formal touch point became part of the heartbeat for the wider development organisation.

You cannot, and should not, do away with specialists but do try to minimise which parts of your process demand a specialist.