malvasia bianca

I planned to say more about First, Break All the Rules, but I seeem to have gotten excessively sidetracked on computer and programming geekery, and worse yet geekery of relatively limited interest. For which I apologize: I’ll try not to let it happen again to quite that extent. Anyways, one last thing that I liked about the book: it has a very refreshing approach to how career paths should ideally work.

Recall that the book’s focus is on having employees spend as much time as possible doing what they’re most talented at. Unfortunately, many traditional career paths involve changes requiring quite different skill sets: a programmer might traditionally be promoted to a manager role, for example, or if a programmer resists that but still wants to move up, then he or she might turn into a software architect.

I happen to like managing and I happen to like designing software, and I wouldn’t claim that my programming skills are irrelevant to those ends, but ultimately the skills required for the jobs are different ones. And I’m not sure that I enjoy either managing or software architecture more than simply programming. So it’s refreshing to see somebody say “we shouldn’t present those job transitions as the only goal for our best programmers”. And the authors back up those words with, for example, recommendations that employees and their managers should have overlapping salary ranges, with the employee potentially earning more than the manager.

But, now that I write that, I realize that my take on the matter is rather different from the authors’. I don’t want to give up programming; but that doesn’t mean that I don’t want to, for example, have a say on the architecture of the software that I’m working on. The truth of the matter is that I want to exercise a range of my own skills, so I’d rather not have the pigeonholing that is present either in a traditional programmer-to-software architect career path or in this book’s presentation of those as distinct roles with less of a hierarchy between them. And it’s not just my skills: I’d be happiest if everybody around me was doing a mix of getting their hands dirty while improving the software architecture. (Part of the reason why I’m attracted to XP, doubtless.) Of course, this might change if I’d seen a situation where having separate software architects worked really well; in my brief programming career, I haven’t had that experience.

Some more random comments that I don’t have time to string into a coherent essay:

• I’m probably excessively biased against the notion that programmers’ managers should be ex-strong programmers. The reasons why I don’t like it are that the justifications that I’ve seen for that claim strike me as after-the-fact, and that I learn more every day (or at least every month) about the different skills managers need. But those aren’t the most solid of reasons, and I do accept the fact that, for example, managing a programmer is different from managing an accountant, and that some domain knowledge is probably useful to that end.
• A counterpoint to the notion that managers and employees should have overlapping pay ranges: one very good point that Andy Grove makes is that an effective manager’s actions will have much higher leverage than a regular employee’s actions, so have more value to the company. Then again, equating value with appropriate salary is pretty naive economics: there is this notion of supply and demand, for example.
• The book that I’m currently trying to integrate into my thought talks about how job transitions are increasingly horizontal. Which fits in well with the notion of focusing on what you do best.