Skip to main content

The (Creative) Class Issues of "Career Evolution"

I've been thinking back to a job I used to have with a company that was very keen on "evolving" their employees to new and different positions over time. If you didn't move from position to position within the organization (taking on more responsibilities or adding to your skillset), you got yourself moved (through re-orgs or the addition of offshore staff who you trained to do your job). There was a huge HR initiative around helping people who'd been with the company longer than five years to find out what their career options were, in the face of increasing offshoring.

We were presented wtih a number of different paths:

1. Become a subject matter expert and serve as a mentor to others in the organization who could benefit from your experience.

2. Be more of a "team lead" and take on more project direction responsibilities.

3. Move into management and put your technical experience to good use.

4. Leave.

Now, while options 1-3 might seem like they're viable options for someone who's a technical producer and wants to move to the next level in their career, there's a certain conundrum with this. Namely, if you're an Author or Builder in the Cyclopraxis model and/or you're a bona fide member of the Creative Class, and you derive much of your sense of purpose, direction and self-respect out of making things and having something tangible to show for your effort, then the prospect of managing others or leading others or directing others to do things that you'd much rather be doing yourself, will not necessarily appeal to you.

Indeed, while becoming a team lead or taking on more managerial responsibilities might be the ticket for career advancement within the Movin' On Up paradigm, it's a recipe for disaster for those who thrive on the actual creation of things themselves. Those of us who really, really, really NEED to make things, and make them WELL, are just going to be thwarted and infuriated by people coming on-board who are dependent on us to give them guidance and leadership.

I'm not talking about ALL developer types. I'm talking about those Creative Classlings who are Authors and/or Builders by nature. We're probably a pretty small subset of the overall population, but remember, we're the ones who build what you need to sell. And if you can't keep your Authors and Builders happy, how will you manage to stay ahead of the pack in terms of innovation?

I really think a lot of careful consideration needs to be given to these concepts by HR. Not just because it's incredibly annoying to be a Creative Class Author/Builder (CCAB for short), and have HR constantly implying that the high quality work I've been cranking out for years, just isn't what they're looking for... but because that annoyance can translate to attrition. And it happens among the very people that the business Cannot Afford to Lose, if It's Going To Keep Its Edge.

Comments

Popular posts from this blog

An introduction to CycloPraxis

CycloPraxis identifies the natural working preferences of employees according to the lifecycle stage of a business. Much has been written about evolutionary stages of firms, disruptive technologies, new ventures, and high technology marketing, but it seems that large firms continue to experience difficulty in deploying the necessary new products and opening new markets necessary for tip line growth and employees continue to wind up with assignments for which they are poorly suited. CycloPraxis explains this behavior and prescribes novel approaches. The classic match between worker and job is function: operations, manufacturing, marketing, finance, sales, development, etc. Certainly it is important to match job function to an individual's preferences. There is another equally important dimension to the fit between workers and their jobs: cyclopraxis. And there's more to it, yet. The concepts of Praxis can be applied all across the board. I came across this idea

When working styles collide... and projects implode

We've all been there. You're on a web-based project, and things are going well. At least, you think they are. The right people are selected for the appropriate functions, and everybody's clear on their roles. You've got a designer, a developer, a project manager, and business stakeholders who are driving the requirements. You've got interlocked programs that tie in with your initiative, and you've got a fairly constrained budget to manage to. The timeline is tight, but if everybody just does their job, you should make your dates. The initial requirements are gathered, stakeholder expectations are set, and the first set of deliverables -- comps that define what the end product should (generally) look like -- is due. But it doesn't get delivered. The comps seem stuck in a perpetual working state with the designer, as repeat revisions are created behind the scenes in consultation with other designers... out of sight of the other stakeholders and app