Eliminating Front-Line Technical Managers

Cory Foy posted a thought provoking comment to my post on Grooming Technical Managers:

One of the interesting discussions I had when I came on board at my current job was with the XP Coach. Part of bringing on XP at the company was that he convinced them to do away with the front-line technical managers. Everyone became a developer.

It’s an interesting study because there are two primary teams (of about 30 devs each). One of the teams embraced this (or embraces it now) while the other seems to fight it. And in that, it seems like the ones who embraced it – who traded management for self-managing teams, who traded assigned leaders for those who showed their strength for it in the group – are doing much better. In fact, they are coming off a 600 unit story that they completed the week they said at the onset being only 4% over budget. Not bad. 😉

I find the idea of doing away with my job fairly appealing. I love the idea and practice of self organizing teams. My personal goal both in consulting and as a development manager has been to bring the team up to a level where I was no longer needed.

I do have fears however that some stuff gets left behind by making everyone a developer. Most organizations just have a lot of administrative stuff that someone has to take care of to keep everything rolling along. And someone has to focus on things beyond the project at hand. In a team of developers who does one-on-ones, fills out the purchase orders for a new build box, or makes sure time sheets get signed off and approved.

The admin duties of a line manager can get absorbed in part by the team. Someone can take the task to run the purchase order through the procurement division and make sure it arrives. Tracking down time sheets can fall to the ScrumMaster. Reviews and feedback can come from other team members and mentoring relationships can be established while pairing.

And Cory’s point here is that your trading your assigned leaders “for those who showed their strength for it in the group.” Thus leaders are elected by the group and not chosen. I have a healthy ego, but if the group wanted to elect someone more qualified, I’d be pretty happy to have someone to use as a mentor.

At one startup in the past I experienced something like this process. The startup was opening a new office in Las Vegas of all places and I was brought in as the first web developer along with a senior Java programmer and one Microsoft programmer. I was never officially granted any management title, but I simply stepped up and took the reins. As I performed on projects and helped stabilize the web developers we were hiring, they just started referring to me as the lead/manager. As a nice bonus they started raising my salary without even telling me. I remember looking at my paycheck and noticing it had jumped three separate times in a single year. This was of course when you could barely type out some HTML and recruiters would throw crazy salaries at you.

Eliminating front-line technical managers can probably work, but within a corporate environment it’s going to be a tough sell. I know at my present company it would raise more than a few eyebrows if we attempted it, but given enough time and organizational change we can get there. But, darn as James Shore asks:

Is burnout inevitable for anyone attempting organizational change?

5 responses to “Eliminating Front-Line Technical Managers”

  1. keith ray says:

    can you tell us what purpose time-sheets serve in your organization?

  2. Cory Foy says:

    “Is burnout inevitable for anyone attempting organizational change?”

    It’s certainly tough. Which also makes me wonder how long a change agent can remain effective within an organization.

    As for administrative tasks – we have teams that handle procuring servers, setting up workstations, etc. Developers only focus on developing – not patches or building boxes or ordering supplies.

    It works because we have great support teams. When we ask for a box, it’s usually there. We have some meetings, and they do what it takes to get it set up for us.

    But I really am amazed to watch how well the teams function without individual managers. I think that there are things they could definately use improvement on (no automated build servers yet) but they seem to sense problems in those areas and work to learn what they can do about it (several developers are working on learning CruiseControl to see how it can help).

    It also helps that people aren’t afraid to let others lead – and I think this is a marked change from other organizations I’ve been at. We have people who we’d consider experts in areas, but not many of the people feel challenged or threatened by others leading – even the experts. So they all function as a team in the truest sense – doing what’s best for the whole knowing that the individuals benefit most from that.

  3. Ed Gibbs says:

    Hmm, good question on the timesheets. Basically the timesheets are administrative trivia and probably required out of habit. My guess is fighting a battle to change that would be monumental.

    And the one thing we could get out of the timesheets, some general sense of how much were using resources for each project is pretty much ignored as far as I can tell.

  4. Ed Gibbs says:


    Your current organization sounds pretty unusual and a lot of fun. I think we may get there some day at my current organization, but it will take a lot of change and it won’t be overnight.

    And Cruisecontrol really isn’t too bad to setup and we’ve seen good results from having it running. The developer who originally brought it in before I arrived was explaining to me today that he’s ready to setup a dedicated build for all projects.

  5. Vasco Duarte says:

    I read your comment on Cory’s post. I would say that some of the fears that you mention are real but only when you take self-managing partially and don’t embrace it’s real meaning.

    I’ve posted an entry on this very subject inspired by your post. Check it here:

    Let me know what you think about it.