Tuesday, March 10, 2009

Professional Development Ladder

Steve McConnell's company, Construx, uses a very smart approach to professional development within its engineering practice. Here's the whitepaper.

I've been discussing the issue of professional development with friends lately. I was introduced to the idea of parallel career ladders when reading about 3M in Built to Last. Apparently engineers at 3M are not limited in their ability to rise within the company if they choose not to become managers (in many companies, an engineer's only path up the corporate ladder is to become a manager). This gives skilled engineers a path that allows them to further hone their skills without fear of hitting a salary or promotion ceiling.

Construx' approach creates a framework for the engineering ladder. It places high value (and salary) on engineers who become leaders not just within their company, but within their field. The value this sort of engineer can provide to a company is huge, and having a structure in place to acknowledge this value is important. It helps engineers set and achieve goals, and it gives prospective and new employees a clear view into the future their career can lead to.

Here's a question: How high does the ladder really go? Benson suggested that the top engineer in the company is known as "CTO." That works for me. It would be a strong company indeed who had an engineer with a PDL rating of 15 acting as Chief Technology Officer.

Ss.

Thinking About Architecture

I'm finding lots and lots of reasons to think more and more about architecture these days:
  • Architectural reviews coming up at work
  • A new guide to architecture published by the Patterns & Practices folks at Microsoft
  • New projects coming up that are going to require some significant planning
So I'm collecting resources. Here's where I'm looking for guidance, new thinking, and inspiration:
Notice these are all .NET-related. My work is all in .NET these days, so good .NET architectural guidance is important. For those who think there's no difference between strong architectural practices in different technologies, I will just sigh and shake my head, rather than argue the point (at least for now). You're right enough, but I'm looking for the details and subtleties, where specific implementation details diverge in technology-specific ways.

So: If you're reading this and you have more resources you can point me at, please comment. Or email me. Or text or call or tweet or something. I need all the input I can get.

Ss.