Pages

Wednesday, 23 October 2013

Career Ladders: Avoiding chaos and anarchy in Software / Systems Projects


This post is part rant & part structured discussion around the topic of career development in the domain of Software & Systems Engineering. I have been in the business of core software engineering for fifteen years (15), and was fortunate to experience working with highly rated professional companies (from Silicon Valley, internationally renowned) whose sole purpose was producing software systems from scratch, including as providing software design services to other software companies - these companies maintained true to engineering as a discipline.

A graduate engineer would enter the company with a fairly good idea of the where he/she is starting, and the various options & opportunities that lay ahead in terms of career growth, and, depending on the company - this graduate could spend

the next 10-15 years with just one company alone and never get bored, traversing many job disciplines as he/she so desired. 

This is the baggage (rightly or wrongly) that I come with, and hence my surprise to learn that some companies in South Africa are still making a serious mistake of not having a simple template that maps roughly the career ladders for the team, covering Development/Test/Integration Engineers, Architects and Managers. I firmly believe this is a recipe for chaos & anarchy that must be avoided as far as possible, and the solution to this problem is to map out a simple Career Jobs Ladder for your technical department.

Don't get me wrong: I am all for meritocracy, flexibility and not bureaucracy - but it really irks me to see things happen in the workplace that just don't make sense, especially when promotions happen when there is no real truth, track record or backed-up peer recognition that warrants a role / title change. 

I have seen the following happen as an example of chaos:
  • An integration engineer with no prior design or architecture experience is promoted to Architect
  • An software engineer with no prior architecture accolades is promoted to Architect
  • A software engineer with no prior team leading, people management or facilitation experience is promoted to Scrum Master
  • A team lead with no prior project management or scrum mastering track record becomes an Agile Manager
  • An integration engineer with no product management experience becomes a Product Manager
  • A new recruit with no prior experience in the technology domain joins as a Senior Solutions Specialist
  • A new architect who has never architected any product before enters as a Solutions Architect
  • An enterprise architect who has never delivered to market any real enterprise-class systems product that has a user base of more than fifty is made Enterprise Delivery Architect
  • A component architect who's only worked on a single software module / component becomes Enterprise-wide Solutions Architect
  • An integration engineer who's only experience in embedded devices joins an enterprise systems integration team as a Senior Integration Specialist
  • An automation specialist or tech lead who is misunderstood as the Head of Automation
To an observer, the above scenarios are candidates for chaos (What do all these roles mean? What's the job spec? Is there a clear map that shows the progression of one role to another?, etc. etc.), although these cited migrations would not be that far fetched if there was a career ladder to hand, that facilitates the growth path - that can be used to take the individual on the journey to reaching his/her desired goal....

And this is where anarchy comes in (again, a little rant on my part):

Thursday, 10 October 2013

Agile Africa Conference - Content made available


Earlier this year I wrote about my experiences from the first Agile Conference hosted in Africa:
The kind folks at JCSE have now shared the documents from the conference here, and allowed me to link independently to my own copies, should their site ever disappear. But for now, you can find the slides for each here: