What happens when a developer becomes a manager?

Because I didn’t blog on Monday, December 12, 2011

A friend of mine has recently moved into a new position at work (insurance) where there is little day-to-day development, and more focus on communication with the business about strategy and e.g. PoC work for frameworks and vendor platforms.

He says that he can already feel an internal change happening. Things that he observed with horror in his immediate manager he now finds himself doing with increasing frequency.

So I asked him a bit more about his immediate manager

He said that his manager was recently made the director for all of IT for all of Europe in their section of the company. It’s not a huge company, but it’s still quite a big role, and this manager is moving directly out of a architect role (having shortly before moved out of a senior development role). He says that he used to see his manager analysing things with a “wrong-headed” approach. “He just doesn’t seem to engage with the idea of a technology on a level which makes sense. When he looks at an idea, he’s thinking about it in the most horribly over-simplistic terms. He’ll make judgments about things which are based on completely flawed understandings of the basic concept.”

To which I replied, “But, isn’t that just a difference in perspective?”

“Yes, that’s what I’m saying – I am starting to see that attitude in myself now and it's due to the perspective. I can tell that I’m thinking about components in larger blocks, and that things like efficiency and uniformity is becoming more important to me than the technical detail because those things seem like a waste of time if I can just buy off the shelf. But I remember that this was a big problem when I saw how my manager responded to ideas in the past.

If I remember correctly, I perceived my manager making decisions that would produce what I thought of as very sub-standard outcomes (in terms of client experience and technical soundness). I was being asked to be a developer when, in reality, there was no real inclination on the part of the manager to develop anything. For him, development was the most painful, risky option, and now that I am moving into that kind of role, I understand exactly how he felt. But it still bothers me that I am betraying the reaction I had.

Perhaps the problem is that we just don’t make a clear enough distinction between an off-the-shelf product and the decision to develop a custom solution (or the boundary between both). It makes me feel even more strongly about the dangers of the “middle road” which is to buy an off-the-shelf product and then customise it to the business’ needs.”

My next question: “So, can ever see yourself justifying the development of custom solutions again?”

“To be honest, even if an off-the-shelf component is less than perfect, that now seems preferable to me than custom development. I think that there’s a role for development in companies, but it should be considered very, very carefully. I think that there truly are gaps in the market, where you still have to build it yourself. The main problem is that I think we under estimate the cost of developing custom solutions to the level of maintainability and operationalization required for it to be the right choice. I believe that you should develop components which are less than perfect only when you can prove to yourself that there is time and capacity to do an really, really solid job of the development effort.”