Little Tasks, Little Trust


All software project management today seems to focus on dividing your work into the smallest tasks possible and then assigning them to programmers. This is in contrast with the approach of delegating responsibilities to programmers. The “little tasks” approach treats programmers like assembly line workers and the “delegate responsibility” approach treats programmers like professionals.

Little tasks put product vision in the hands of management. While working on a little task, programmers do not contribute to the product vision

Little tasks give management more opportunity to produce and optimize metrics.

Little tasks take away design/architecture decisions from programmers, so they only do grunt work and don’t get valuable experience designing systems.

Little tasks estimation falls apart when the underlying hypothetical design assumptions don’t work out.

The extreme case is that all interesting responsibilities (product design, system design, etc.) get taken by roles above the front-line programmers, and the programmers are left with only dumbed-down code monkey jobs The solution is to delegate responsibilities to programmers, responsibilities like entire products or libraries.


This is all true and I’ve lived thorugh it.

I’ve been in work situations where I am given responsibility, trusted, autonomous and creatively engaged. I’m producing high-quality work using my talent and emotional investment.

And I’ve experienced work situations change into a “little tasks” model, and watched myself become disengaged. Suddenly, I’m contributing about as much as the the weakest member on the team.

The problem with taking responsibility is when the organization doesn’t like what I’m doing. Not because I’m doing a bad job, but because there are flaws in the company. After dealing with situations like that, where my emotional investment gets wasted, I welcome the disengagement of little tasks, which is not a great thing for me or management. I then welcome Goodhart’s Law and just worry about getting my assigned tasks done, instead of worrying about the overall vision.

Little tasks are neutering. Instead of being the 10x programmer on my team, I get chopped down to the same level as everyone else. It’s a real Ellsworth Toohey kind of move. But that doesn’t mean it’s wrong for every company, in some companies, little tasks just be the way things have to be.

  1. Being given little tasks sucks if you want to be treated like a professional and allowed to care about your job, it’s good if you don’t care about your job and you just want a paycheck.

  2. Little tasks are a crutch for management that lacks a solid vision. They’re a good way to get programmers to work on bullshit tasks that arise from a lack of integrity in the design.

  3. Little tasks cover up the fact that management needs to get better at hiring good programmers.

  4. Little tasks make everyone a 1x programmer.

I’ve also experienced this as an employer. I figured out right away that the best and easiest way to get good work done is to give programmers something interesting and challenging, and let them own it.

It is good to work on the design and write a specification, it’s definitely good to have general guidelines about my expectations and how I want things to work, but at some point I hand over responsibility for the design and for the spec, and I just trust the programmer to do a good job. This has worked out great for me. Of course, the issue is that you need to find a good person to do the work. A real professional. And you have to build a relationship of mutual respect. It helps to higher someone intelligent.

I have confidence in my engineering abilities, so I’m actually able to delegate to others and have confidence in their abilities, and know that I’ve communicated enough of the right things so that we start the projects with a common understanding, and I know that I can evaluate their code and effectively communicate what I like or don’t like.

I have a clear, vision for what I want, my vision has integrity, I’m not being pulled in multiple directions because I don’t actually stand for something. This means the programmer can do their job feeling aligned and productive, instead of feeling impeded by a lack of conceptual integrity.