Conceptual Work vs. Firefighting

For the purpose of this entry, allow me to recognize two general types of intellectual work:

  • conceptual work
  • support (aka “firefighting”)

Conceptual work is about creating content. This can be an offer, a piece of code, a presentation, a plan, editing, credit decisions… Actually, most of the activities you find in the office, perhaps excluding managing people and chatting around the cooler.
Support is responding to [more or less] urgent inquiries of all sorts, e.g. helpdesks, system administration. Representatives of the latter prepare FAQs, fallback scenarios and act when problems arise.

At times, it’s not easy to separate conceptual work from support. We do receive inquiries that require conceptual work after all, right? Right. The point is, that those two types of activities are sometimes combined in one position. Examples? A programmer who is part of the support crew. A project manager who supports the local knowledge management site. A business analyst, who acts as an application manager and picks up the phone when “something doesn’t work”. A communication consultant whose main responsibility is to edit texts, but is required to act when an author has technical problems.

My experience shows that this situation is quite common. Why? Cost cutting might be one reason. Employing a new person for the support part of the job isn’t the first choice. Another – ignorance? A manager thinks that the author or the main owner is best suited to support others. After all, he/she has the know-how.


The problem is that we lose money this way. In the long run. We might lose the employee in the long run too. Those two activities don’t work well together. Conceptual work requires longer attention spans, takes time to prepare before the actual execution. When the process is interrupted, we lose efficiency (the “saw effect”). A more appropriate pattern for conceptual work would be as follows:


For the employee the result in combining conceptual work and “firefighting” is usually… frustration. He or she finds it more and more difficult to provide quality work. Instead of “doing things” the employee is required to pick up the phone and respond to dozens of e-mails. For the knowledge worker, the value added seems vague here – all that can be quantified is a bunch of tickets in the support system. If anything.

Time for a coffee break 🙂