Specialists vs Generalists

This weekend one of the teams I manage had to work some very long hours to resolve a severe customer problem.  (I got about seven hours of sleep over three days, and I'm getting a bit too old to recover easily from that.)  One thing that made it take so long was that we had to submit database scripts to be executed on the customer's behalf; for good reason, there are a lot of restrictions and approvals necessary to do that, but my team wasn't very familiar with the process.

Thinking about it, I realized this is an example of a systemic failure, and I'm on the cause side as often as the effect side.  I'll call the problem "specialist versus generalist."

The database administrators (DBAs) see dozens of requests a day for scripts to be executed.  Executing these scripts is a core part of their job.  They know their team and their communication channels are well established.  They know the proper approval process and they know what to expect in a properly formatted script request.  From the DBA perspective, script requests are a simple, straightforward process, that has been fine-tuned and improved over months and years; and they don't understand why developers so often screw it up, when it happens so often and is so important.

There are dozens of requests a day.  But there are more than a thousand developers.  Any individual developer might go half a year or even two years without submitting a request.  When they do, it is in a situation where they've been pulled off of their normal job in order to work an emergency customer issue in production.  They're under high stress and tight time pressure: by the time a problem is escalated through ordinary support and all the way to development, the customer has probably been suffering for several days already and is hopping mad and running out of time.  The developer doesn't know what a proper script request looks like, nor who to talk to in order to find out, and all they know about the approval process is that it probably changed since the last time they did it.

The DBA is the specialist in this scenario.  The developer is the generalist.  The specialist understands the rules and the problem domain so well that s/he can't see what it looks like to the generalist, who only encounters the situation once a year.

But this is not just DBAs versus developers!  The generalist in one scenario is the specialist in another.  One of the dev teams I manage owns an infrastructure that lets other developers license the features they develop.  We are deeply knowledgeable about how licenses work and how features are defined.  From our perspective, it's hard to understand why the other developers continually screw up their definitions.  We're the specialists.  But any given developer only defines a new feature every year or so.  They're the generalists, and to them, the system is confusing and every time they try to use it something has changed.

The more I think about this pattern, the more I see it playing out all around me.  When you spend all your time providing a service, it's hard to understand that to the people who consume your service, you are just an occasional thing, and most of their attention is elsewhere.