The Red Hot Developer Model: Block Out Constant Distractions That Your Team Faces 

The Red Hot Developer Model: Block Out the Constant Distractions That Your Team Faces 

Let's face it: the larger, more complex and more demanding a project gets, the more distractions your various teams face. From various maintenance tasks, to "identifying the developer who's broken a build" type of tasks, to answering all those questions from different teams, that just keep piling up, to figuring out what's the deal with all those errors in the log files that keep coming up and everyone's stubbornly shutting their eyes to... these are all distractions that keep stacking up as a project grows. And which can grow into some major productivity drains. So how do you minimize them? By implementing the Red Hot Developer model.

Have you heard of this concept before?

...of passing around precisely these time-consuming, "petty" tasks with a significant impact on the entire team's productivity? 

If not or if you've just heard something of the RHD model, but not enough to stir your attention and make you delve into more details, here's:

  1. a brief, yet clear and comprehensive overview of this model for boosting productivity within your team by blocking out imminent distractions
  2. a few predictions on the reactions in your team, the results and the side-effects to expect once you've implemented this new model
     

The Red Hot Developer Model: How Does It Work?

The concept is surprisingly simple:

Each and every developer in your team gets to "walk into the shoes" of a red hot developer, on rotation. He or she gets to take a full day off from his/her regular tasks and focus exclusively on these maintenance tasks instead. "Small" process improvement tasks which, if ignored, risk to turn into productivity-killing distractions for the entire team.

He'll be:

  • the only one handling the incoming requests
  • the first one to run the needed "investigations" if something goes wrong
  • ... the one to identify the developer responsible of a build's failure, for instance
  • the first one to answer the questions and inquiries that teams from other departments might have regarding the given project 

And it's precisely this:

  • round-robin way of assigning the RHD role within a team
  • of distributing these maintenance tasks to a single person instead of having the entire team distracted by them all and the entire team risking to keep ignoring these issues

... that makes for the boost in productivity at your workplace.

It's this quite basic, if you come to think of it, type of working model that will eventually keep your team(s) more focused, more engaged.

Now let me briefly list a couple of other "maintenance" RHD tasks that the red hot developer will focus on the day that he's "on duty":
 

  • monitors the builds and, in case of a failure, "tracks down" the developer responsible for it; he notifies him/her and reassigns that issue 
     
  • goes through the previous day's RHD schedule and see whether there are any tasks to be handed over
     
  • sees that all the new questions — stacking up on Slack asked by teams from various departments — are answered
     
  • is the first responder and pretty much the main contact for anyone outside the team who risks distracting the team) with questions and inquiries
     
  • ensures that all the pull requests are handled correctly
     
  • sees that all smoke or unstable tests get fixed (by him, himself, or by another member of the team that he'll assign this task to)
     
  • closely monitors the build process and is ready to "intervene" if/when needed: to provide the needed documentation, to make sure that all the signaled problems are being handled properly, to apply necessary improvements to the code base etc.
     
  • monitors the code's performance metrics

In short: instead of having all the maintenance and improvement tasks carried out (or just postponed) by the whole team — leading to all the team members being constantly distracted from their regular tasks — you'd have just one person, each day, handling ALL these tasks.
 

What to Expect? Possible Reactions, Improvements, and Side-Effects 

First of all, you need to face the fact that you'll come across resistance from your team(s) once you implement the Red Hot Developer model.

I mean, let's face it: no developer would gladly allocate a full day to maintenance tasks, to "small" improvements, instead of focusing on the... substantial stuff. Some of them might even try to... skip a few RHD duties and thus gain some time to catch up with his regular tasks instead.

Now that you know which are the "less enthusiastic" reactions to expect, let's focus on the actual improvements (and "surprise" side-effects):

  1. with all your developers (except one), "safeguarded" from distractions — and thus with more time at hand to focus on their work — you'll be witnessing a significant improvement in the quality of your code base 
  2. with each developer directly involved in all the aspects related to your codebase — building, testing, deploying — you'll be witnessing a significantly improved flow of knowledge within your team

And this is quite predictable if you come to think of it:

  • you'll have designers challenged to learn how to use Gulp and Webpack if their RHD schedules include duties such as "improving the CSS and the JS bundles"
  • you'll also have front-end developers facing the challenge of configuring WCF so that the right security context is being used; or the challenge to handle RavenDB quirks

Having to step outside of his/her "comfort zone", outside the familiar technology that he normally uses on his daily tasks, the Red Hot Developer will need to... learn and thus to grow.

To enrich his/her skill-set...

And another thing to expect, once you've implemented this new way of working within your team, is:

Having to deal with RHD tasks that take more than just one day to be carried out. In this case, the 2 most suitable solutions  — other than the "hand them over to the next day's RHD" — would be:
  1. to allow the RHD in question to "block" the following day, as well, in order to focus on the unfinished RHD tasks
  2. to team him/her up with the next RHD in line and allow them both to work on the remaining tasks

The END! What do you think of this model? Do you think that the Red Hot Developer model be a good fit for your own team(s)?

Do you consider that the concept a "daily rotating dedicated developer" will manage to lower distractions for your team?