[jt2190]

  > Our group uses a JIRA[2] instance that I've customized 
  > the heck out of to make an effective "This is what needs 
  > done, grab this if you have any spare time" system. The 
  > motto is "No ticky, no worky" - anybody doing anything 
  > work related generates a ticket for it.

Understand that the system you've created implies that someone else has decided that the work is worth doing, someone else has broken the work down into manageable tasks, and someone else has prioritized it. This may work great for employees who need a lot of direction, but starts to break down as tasks become larger and more complex, and the goal is to leverage the knowledge and experience of the person doing the task.

Markovitz is really advocating an approach that works better for employees who are essentially given whole projects to manage, and are empowered to steer the direction of the project overall:

  > You might think, “There’s no way I could tell my boss
  > that I can’t do this by mid-February.” But I’d argue that 
  > you have to say no. The CFO says no when the president 
  > wants to move into a new building or hire new people, and 
  > the company can’t afford it — that’s part of her fiduciary 
  > responsibility. You have the same kind of responsibility — 
  > to set expectations about what can be accomplished with 
  > the amount of production time you have available.

(edit: Both approaches have their place, given the work and the team. It's important to understand both approaches, however. I see a lot of frustration from employees who want more say in the overall project direction when they're in a "just do what you're told" kind of job. Similarly, some employees really love the ability to focus on the tasks assigned, and not having to worry about whether they make sense from a business perspective.)

[Karunamon]

Ah, I should probably give more detail there. We operate on a kind of tiering system, technicians, sysadmins, and engineers. Sysadmins and engineers are generally the ones entering tickets, and the technicians the ones working them. Generally, but not always. It works as a good reminder system too for all kinds of assorted tasks that would be easily forgotten.

I think you've made a bad assumption in that only one or two people are breaking down projects into smaller tasks - that's not the way the software is set up, and it's not the way it works in practice for us. Anyone can assign subjobs to any main job, and this happens on a pretty regular basis.

The major bonus is that it allows management to see who has the least amount of stuff they're working on and allocate time effectively. When you've got north of 20 people being managed by 2, and you can tell at a glance who has more free time, I don't think the utility of this can be overstated. It definitely makes our lives easier, and I'd like to think it helps the company make money, but I don't have a good way to quantify that.

[jt2190]

  > We operate on a kind of tiering system, technicians, 
  > sysadmins, and engineers. Sysadmins and engineers are 
  > generally the ones entering tickets, and the 
  > technicians the ones working them. Generally, 
  > but not always.

Right. In general, a sysadmin or a engineer ("someone else") decides what should get worked on, and enters it into the issue tracker. The technician is not involved in this decision making process: They just pull tasks and work to complete them.

To pull Markovitz' article back into this, the sysadmins and engineers are (I assume) able to push back on the business, providing a reality-check when plans are unrealistic, and they are the ones he's suggesting should not work off of a simple to do list.