Software Journal

Various management books (including some of the ones that I like – check out First, Break All the Rules: What the World’s Greatest Managers Do Differently) really go ga ga over broadbanding. The concept is very simple – that software developers (or generally speaking, people in any role) do not need to grow in the team hieararchy (to be leads, project managers, etc) to get higher salaries and add higher values to their companies. For a long time, I have believed in the concept too, though I never saw it happening anywhere I was. I kinda thought – hey, this makes sense at Google or at Microsoft (and perhaps it does). But it never made sense at more boutique software firms where I have been.

I must admit, it makes some very good theoretical sense too. Software developers should after all be allowed to become better and better developers, coding better and faster, and not be forced into leading teams, something they may not be inherently good at. Leadership (of which I am neither a patzer nor a prodigy) is not for everyone, and can be a distraction for a person focused on technical aspects.

Yet, a software developer’s career growth inevitable takes the developer into the path of a technical lead, and project manager. Why is that the case? Simple, really, for a person to grow, the person needs to be able to solve bigger (or more complicated) problems. Bigger problems are easier to find (and require leadership), while more complicated problems come by less frequently (but require a deeply technical person). So, one way in which a developer can grow her career is to lead a team in building an entire module (i.e., become a technical lead), or to lead an entire product or a project (that is, become product manager or a project manager).

From your management’s perspective, as a project manager, you are adding significantly more value as compared to a software developer, because you are the person in charge of the entire project, and the entire team underneath you is, in a way, your fiefdom. You are welcome to do anything within reason, as long as the project or product profitability goals are met.

You can add even more value (as compared to being a project manager), if you are the person handling an entire relationship with a client (perhaps spanning multiple projects). At that point, you are the client relationship manager, and you could have a few project managers working with you.

You can add even more value (as compared to being a client relationship manager), if you are the person who also talks to people, and help them solve their problems, and then provide your team to implement the proposed solution. At that point, you have your own account, that is, your own clients. You can choose to be the client relationship manager yourself, or after some time, transition that capability to someone else.

So, back to that inflection point, where a software developer becomes a technical lead. Compared to all other transitions that can follow from that point on, that is a transition unlike any else. It is that momentous occasion, where the developer has abruptly gone from just taking the tasks, to also giving tasks, and being responsible for other team members. Of course, that transition can be made smoother by adding one team member at a time, but still, that calls for a *huge* celebration when that happens. So, when you do arrive there, remember to paint the town red. You are in the big boys league now.