What future, a technical career path?

The link between professional practice and career path progression represents one of the seemingly intractable problems faced by firms in computing but also science industry, high-tech, design, and engineering is the issue of practitioner career paths in contrast to management career paths. How far can a gifted architect, designer, engineer progress before the organisation fails to offer further challenges, opportunities, responsibilities etc. How far can an engineer be promoted before reaching the 'glass ceiling' beyond which it seems that only those with marketing, accounting or finance backgrounds progress to the executive, the 'c-suite', or the board room?

Certainly there are exemplars of programmers, engineers, technicians, architects, designers achieving great corporate and personal success.
But for each of these there are many who love doing what they're good at but felt they had to move into management in order to progress their careers.
And there are many more who stay in product development, design and engineering and languish to an extent because the pay is not kept in line with the equivalent on a management track.

Is there a technical career plateau? If so then why and what can we do to address it?

What about approaching this from the perspective of 'the profession' and link excellence in work practices (i.e. those practices articulated in XP in all its gritty glory) with career path, progression and professionalism.
A professional practice-oriented perspective should be devoid of proprietarianism (via the trademarked & proprietary methods business).
It would necessarily need our active involvement through our various professional societies, ACM, IEEE, IEE, IEI, IFIP, etc...

Further reading...A short piece by Alicia Clegg in the FT "Companies face up to the technical brain drain challenge"

Requirements are the devil.

Questions that keep coming up from business people managing development projects:

"shouldn't I build a blueprint a software company could use to directly build the plattform?""Isn't focusing solely on User Stories letting the software company a little bit too much freedom regarding design?"
"I think I need to describe the processes between differrent modules, how do I do this with just User cases?"
"Where can I define the database structure and security issues?"

In response, to be clear; of course you can design your interface, you can even design your database schema, both of those activities are useful and provide a basis for starting the project. BUT neither are sufficient to bring the project to market nor are they likely to be retained if you actually produce the project.

Why? Because you hire specialists to do design for you. The thing you bring is your judgement, appreciation for use and usability, the specialised domain knowledge you possess, your commitment to the project, your access to financial resources or gateway into a market etc.

In my opinion you shouldn't even be thinking in terms of modules, database structure or security solutions. Although you should be conscious of the need for all of them to be present or resolved.

Unless of course you are the developer.


As a product manager or project leader for development, at some stage you are going to have to capture basic requirements (look back to this post).

But be careful you don't stray into specifying the system design!
Relax, the people you hire to do the development should have the freedom to offer the best design they can. Note that User Experience design is a separate specialisation from application architecture design. You should actually bring in different specialist skills for these two very distinct disciplines.

The current practice for a system requirement is that it be:
* uniquely identifiable
* that it identifies the customer who requires it and why
* that it is expressed in goal driven terms rather than by specifying the implementation
* e.g. that you express it as a 'use case' using the storycard syntax "as a.. I want to.. so that.."

The same goes for functional and non-functional requirements. The main difference is in how testable they are.

Nearly everything else you produce for project planning and development is a design artifact not a requirement.

Reflect on this provocative opinion piece by Michael Schrage

"...have the wit and courage to ban requirements from every systems, process and innovation proposal made to top management. (Instead) Put use cases front and center in your value creation efforts."

blogs.hbr.org 12:31 PM Tuesday September 6, 2011

Also see this post on an underlying theory for requirements.