200 OK Work Flows Up: Effectively Distributing Work on a Team of Engineers


Sometimes junior technical staff are starved for interesting work while senior staff are overworked

This is Part 2 in my Series on Supporting/Managing Engineers

If a team has lots of technical work to do, and only a few brilliant engineers available, how do you get work to the right people?

In this article, I discuss methods for managing work in IT and technology teams, such as those doing Network Operations or Engineering, Devops, Security Management, System Administration when you have a mixture of skill levels, including "star engineers"  with 10+ years of experience. I would give different advice to a team focused on developing software.

Call the Brain Surgeon!

A hospital is full of medical staff.  But when a life-threatening case rolls in, you want the most experienced physician available to handle it.  And if you're doing important, high-profile, mission-critical technical work, you might want the most experienced technician to do the work.

But if the problem at hand is to restore the telephone service for the hospital, or to enable a failed 911 Emergency calling service, then it makes sense to put the best available people on it.

...to suture this wound

Yet often, the risks are not so high, and the need is not actually so urgent. You really don't want your most-senior staff doing relatively low-risk simple work. Escalating all work to the most-skilled person robs the lesser-skilled staff of experience and deprives the organization of good ideas.

How do you prevent all the hard work from being done by the best and brightest?  How do you prevent all the work from flowing up to the highest-skilled people?

  • Make junior staff work at the highest level possible
  • Make senior staff support and include junior staff in strategy and planning
  • Define the barriers between junior and senior staff
  • Define the workflow for projects

Excelling as a Junior Engineer

Suppose you're a junior engineer in a team, and all of the challenging work goes to the senior engineers. You know you could do that work, but it's always going to the senior guy. How do you get the chance to work on hard problems?

It's possible your management is fumbling, but be sure you're doing a great job on the problems you have. It's easy to dream about solving challenging problems, but you have to be sure you're doing fabulous work in your current tasks:

  • Technically:
    • Are you doing as well as anyone in the world?
    • Are you aware of how other people solve this problem?
    • Are you documenting your methods?
    • Are you listening to the ideas of your colleagues?
    • Are you clearly explaining your results?
    • Are you recording your questions and other unknowns, then working to get answers to those questions?
  • Organizationally:
    • Are you confounded by how difficult it is to make progress?
    • Are you losing track of a detail, date, times, or meetings?
    • Are you recording results of the project so others can benefit from it later?
    • Are you making progress before the deadlines, so that you have substantial progress to demonstrate, and questions to ask?
  • Inter-personally:
    • Are you communicating clearly, with the requester of the work (the "customer") and others with whom you collaborate?
    • When you have a chance to talk about the project, are you engaged? Are you contributing ideas?
    • Are you doing what you can to be pleasant, even fun, to work with?

Make Yourself Available to Hard Problems. Find out how the interesting projects come in, and look for ways to be involved.

  • Try to make sure your work environment isn't too hidden and isolated.
  • Ask to join conference calls on interesting projects
  • Take notes in meetings, and offer to provide those notes to other people.
  • Ask questions about everything you don't understand.

Senior Engineers Plan Projects

What is the role of the Senior Engineers?

  • Make design decisions.
    (Anything that can be done either better or worse is a design decision.)
  • Analyze the problems and projects
  • Write plans for the projects
  • Guide the solutions toward doing the best thing ("what should be done"), minimizing involvement in method chosen.
  • Solve problems when no-one else will handle them
  • Mentor the Junior Engineers

The distinction of a star technician is perspective and context: they know how things are done and why. They can consider pros and cons of various options for change. They know potential for risks. They should know the organization's strategy and mission.

With this context, a senior engineer should be planning projects:

  • What are the objective and the goals?
  • What are each of the phases of work along the way?
    Tip: keep each phase <4 hours of work
  • What kind of data needs to be collected before proceeding?
  • How will we know when we're done?
  • How long should it take to complete each phase?

A star technician is as mature as the plans they can provide to others to execute.

Define the Junior/Senior Boundary

What kind of work should be done by senior engineers, and what kind by junior engineers?

Senior Engineers are obligated to:

  • Maintain or improve architectural unity of the system.
  • Provide opinions based on mature technical aesthetic
  • Research the available options for solving problems (i.e., not just their favorite options)
  • Write plans for accomplishing the work
  • Determine which things to do (E.g.: Install Apache on a Linux VM, or buy an F5 Local Traffic Manger?)
  • Answer questions raised by junior staff
  • Review and approve the work done by junior staff
  • Be aware of the skills and capabilities of the junior staff
  • Do the work that no one else is able or willing to do

Junior Engineers should:

  • Follow the plan to accomplish the work
  • Debate and question the plan if they see better ways
  • Ask good questions to fully understand the rationale behind the plan
  • Discuss the problems with Senior Engineers when they find something interesting or unexpected.

Define the Workflow

Send all work to the Junior Staff?

A popular remedy for Work-Flows-Up Syndrome is to send all problems to the junior staff. For example, all tickets come in and start at Tier 1, then the hardest 80% escalate to Tier 2, then only the worst get escalated to Tier 3.

Hacks.  My experience with this method for actual problem solving is poor: Junior staff are prone to develop Workarounds, Tricks, and Hacks (collectively known as "WTH Solutions") without adequate context or insight into the best way to solve problems. Without knowing the long-term risks, WTH Solutions make the system more fragile.

Blockages. Just as a star engineer can be a bottleneck, junior staff can block the successful completion of work. To know when to ask for help is a learned skill, and junior staff are often prone to keep poking around the edges of a problem. They can tend to sit on interesting problems too long.

Lack of Senior Insight. Senior staff need the insight on the real-world problems with their system. When every problem starts at the junior staff,  the senior staff may be unaware of the problems.

For example: In one case, the network had a serious, but minor issue, occurring  that could be worked-around through an easy procedure. The senior staff gave instructions for the junior staff in how to solve it, expecting the junior staff to need to do it no more than weekly.

But the problem grew more frequent. The junior staff were using the workaround dozens of times per day, faithfully following their instructions. But the senior staff were unaware of the scope of the problem because the junior staff were dutifully executing the procedure.

In this case, the senior staff needed to be aware of the scale to develop a more permanent solution. In that case, when a problem was mostly-delegated to the junior staff, the senior staff couldn't see what was happening and rethink their proposed "solution."

Plan Before Proceeding

Rather than "fill all the work from the bottom" skill levels, projects should be planned from the beginning. The first step in processing every new problem should be writing a project plan.

What's a project?

Anything that has several steps is a "project" as I'm using it here.

What should be designed?

A design decision is anything that can be done incorrectly but still appear to work. For example, you could build a network using one large subnet in one big ethernet, or you could set up the network with routing and subnets. Both may appear to work, but one will be better for the situation.

Writing the project plan may require 10% to 20% of the total work time on the task, and should be done by Senior Engineers. The Senior staff is thus responsible for considering options and maintaining architectural and conceptual integrity of the system.

After the plan is developed, the project can be assigned to somebody at the right skill level.

  • Could the execution of the project affect architectural integrity of the solution? Senior Engineers
  • Does the junior staff have the skills to do it, or can they learn? Delegate to Junior Engineers

Senior / Junior Followup

Senior engineers need to routinely follow-up with junior staff to talk about their projects.

Most projects cannot be completed start-to-finish without interruptions. Sometimes we need a new license file; or we need to open a ticket with the vendor; or we need access to a protected site; or information from the customer. Due to these interactions with other vendors and customers, I find many technicians need to have 3-5 projects in order to stay busy.

Senior Engineers should have routine conversations with junior engineers to discuss the projects, and how they are going. The Project Plans will never be perfect, so discussing the project as it proceeds is a healthy part of mentoring.

Work Flows Where You Pump It

With the proper distribution of tasks, even a team of two engineers or technicians can be more effective. Junior staff have responsibilities to grow technically and professionally, and Senior staff have an opportunity to increase their team's effective throughput.

Photo Credit: Ewan Cross