Career Growth Framework

Career Growth in a software consultancy – Our journey so far…

Originally posted one Medium.com.

I’d like to share the challenges and goals for maintaining a skilled software development consultancy through the lens of career development.

Now I know what you’re thinking, what could be sexier than a deep dive into individual career progression and the tribulations of one software engineering consultancy in their relentless pursuit of fairness and transparency? But I am afraid you will be disappointed by the outcome, as it is both unsatisfying and deeply frustrating.

This post is the first in a two-part series. This part sets the stage, frames the challenge and gives some background into the obstacles. In the second part, I’ll go into some practical, specific details of how we are attempting to solve this challenge in our business Haefele Software.

The journey that brought us here as individuals will not carry us forward

My path to my current position started much like many at the time, I graduated from university, joined a company as a junior developer/support engineer and began earning my stripes. I started making slightly more than minimum wage doing software support for the first year of my career. I made a move to improve my prospects hopefully, get out of software support and start writing code and joined a more exciting tech consultancy which had a reputation of “knowing their shit”.

During the years I was with this company, I was gradually promoted every couple of years and was thankful for the increases and titles that came along with them. But I was never sure what the measurement criteria were and how I was doing at any given time concerning these measurements, other than the occasional informal meeting with a manager.

Eventually, I was promoted to a technical lead position in the company, but by that time, I had grown quite disappointed in the organisation. I joined at a time when the business was relatively small, and a few years later, it was acquired and absorbed by a larger company — gradually eroding the original culture of the business.

What I later realised is that the time spent with excellent teachers, hard challenges, and plenty of deep ends to climb out of is what formed my skillset and experience in my career.

I joined Haefele Software after that. The business was new, vibrant, with massive potential. The team was young, talented, and hungry (still is). We needed to do better than what we were all used to, and I knew it was possible, but we just didn’t know how to start. But knew two things for sure:

1) Great talent comes from excellent teachers and mentors.

2) Talented individuals need to be nurtured deliberately and often.

Practising what we preach, we took an agile approach at what we thought could work and right now as of this writing we are in the 5th iteration of our way of managing progression and career growth in our organisation. This is by no means the last iteration.

We began with the first version of our growth framework, based on the philosophy of our MD, Alan Haefele. His view is that the talent should jointly lead this business from all our disciplines, a core principle we share today, evident in how we define and refine our strategy, execution and approach with clients. As such set out the foundational 1st version of our career progression strategy which is fully specified, refined and reviewed by anyone at any time.

Progression forms the core of a pillar of our business which we call “Haefele RISE”, which focuses on growth, learning, knowledge sharing and collaboration, not just internally within the company but outward to anyone interested to experience us and can gain value from our experiences. If you are interested in reading more on the origins of “RISE”, you can find more here in one of our earlier blog entries.

I will go into detail about our specific framework in a subsequent post, but for now, we need to understand what we are trying to solve.

The goal of this post

I have poured over the challenge of equitably measuring the performance of individuals in a software engineering context for the better part of 4 years now. Our company’s approach to people development is one we are particularly passionate about.

We feel that each individual and their contribution to the growth and sustainability of the company deserves specific, detailed, and robust attention as often as possible when it comes to their career growth and earning potential.

I want to share our approach and explore whether our current model and process adequately allows those that are pursuing further career growth the clear path to achieve their goals?

I want to answer whether this approach is right for the business and can we learn from others that have blazed this trail before us?

Simon Gerber wrote an article that I am referencing quite a bit in this post which I encourage you to read.

The process of career growth and your organisational structure is your company culture.

In Simon’s post, he alludes to a story of a business that hired a consultant to help them improve their culture. In this story, the consultant asks employees a straightforward question: “What do you have to do to get promoted?”. He delivered the answers to this question back to the business and stated that the definition of their culture lies in the answers provided to that specific question.

What this story illustrates to me is that company culture and your career growth framework are inextricably linked. At first reading, I felt the way you probably do after reading this, and I can hear your eyeballs rolling toward the back of your head while thinking “Sounds like bullshit”. But after a couple of days reflection on this idea, I probably agree with this sentiment, mostly because I am not qualified to disagree and because common sense prevailed.

Eli Goldratt wrote in his book “The Haystack Syndrome: Sifting Information Out of the Data Ocean.”:

“Tell me how you measure me, and I will tell you how I will behave. If you measure me in an illogical way, don’t complain about illogical behavior.”.

I like this quote because it succinctly demonstrates our human nature. We will follow the path in the maze that will lead us to the cheese the quickest and with the least amount of effort. To change the perspective to that of your business, you will receive the behaviour that you measure or reward.

How the organisation is structured has a part to play in the culture of your organisation.

Nebojša Janićijević concluded in his paper titled: “THE MUTUAL IMPACT OF ORGANISATIONAL CULTURE AND STRUCTURE” published in the journal “Economic Animals” in 2013:

“If organisational culture and structure are not in accord, there will be serious tensions and problems which will affect the organisation’s functioning and its results.

Organisational culture affects the design and implementation of organisational structure. With its assumptions, values, norms, and attitudes, the culture creates the context and the frame of reference used by those who design the organisational structure…”

He goes on to state:

“…organizational structure institutionalises the culture, i.e., reflects its values, norms, and attitudes. However, the organisational structure can strengthen or even change the existing organisational culture.”

What do culture and structure have to do with a career growth framework?

In my opinion, your organisational structure defines the career ladder that makes up progression and growth in your organisation, and I assume this is not too contentious. The logical extrapolation then is that you choose your structure based on the culture you want, and that defines your career ladder. Once you have an established career ladder, you can start to set a growth framework.

A bit of history

Before we can responsibly look at any practical approach to career growth in a software consultancy, it is crucial to have a view of what a career ladder is and why it exists.

Simon Gerber shares this in a bit more detail. In summary, he writes that before the industrial revolution, only the owner of a business had anything to do with running it. After this, the concepts of division of labour were implemented as ways to optimise. Workers were controlled by management structures which took direction from the owner. Two prominent models existed at the time: Taylorism and Fordism.

Taylorism aka “scientific management”, sought to break down work into repeatable, well-understood, measurable, and optimisable chunks. They were focused on the separation of planning and execution. Engineers planned the work; workers executed the work in the hope that this would smooth relations between workers and management. The effect of this was workers where wholly replaceable.

Fordism looked to optimise further by famously introducing the assembly line. From these models, corporate structures emerged from their success. Engineers planning the work became management which provided employment to a mostly unskilled workforce. In these organisations, career growth meant climbing the career ladder from unskilled worker to skilled manager.

Peter, Dilbert, and dual-track career ladders

Simon explains the Peter Principle as follows:

“If an employee does well they are promoted. Promotions cease when they are promoted to a level at which they do not do well. As a result, over time, every position tends to be occupied by an employee who is incompetent to carry it out.”

There is a lot more detail here if you are looking for more information. He also linked to a cartoon that defined the “Dilbert Principle” :

“Leadership is nature’s way of removing morons from the productive flow”.

Probably most relevant to us as software development professionals.

I am sure you can relate. Anyway, one solution is dual-track ladders in industries like software development. A technical track for individuals that have no desire to be promoted out of the work they are very good at into a management role and another for those that have that desire or are especially skilled in a management track and are not necessarily technical. The idea is to have two equally rewarding hierarchies that are exclusive of one another. An example could be:

Technical track: Developer > Technical Lead Developer > Architect > Development Fellow.

Management track: Developer > Team Lead > Business Unit Lead > VP > CTO

The problem, as Simon found, is that often the dual-track approach is implemented within a Taylor-ist hierarchical structure and doesn’t solve anything as the technical track is still viewed by workers as bureaucratically inferior. This led to technically focussed individuals feeling undervalued.

As workers, our careers are there to support us, our families, and our chosen lifestyle. As a business, our challenge is to make sure the opportunities we provide enables their chosen lifestyle.

The question then becomes; “How can we motivate for optimal performance in exchange for the opportunities we offer?”.

According to Simon, the extent to the effectiveness of extrinsic motivators begin to wane after basic lifestyle requirements are met.

In Daniel Pink’s book “Drive” he talks about the more powerful intrinsic stuff. The act of doing as its reward. The skill and craftsmanship, the art of the craft itself. I find my motivation to be in line with Pink’s idea of intrinsic factors.

What should be noted in this is that extrinsic motivations are essential and cannot be ignored. Still, acknowledgement and encouragement of intrinsic factors are crucial. They must be nurtured within the organisational culture to find a balance, particularly for skilled knowledge workers. They hone and sculpt their skills throughout their career, well beyond the effective reach of extrinsic motivators.

Why have a ladder at all?

The big debate, as Simon points out, is whether a ladder is useful at all in the context of knowledge worker industries like software development.

Some argue that the concept of a career ladder in these industries goes against the ideals of Kaizen, which is the basis of many methodologies embracing the Agile Manifesto, something many modern software development companies embrace. I won’t do it justice in this article, but in short, Kaizen holds, collaboration, organisational agility, autonomy and continuous improvement as pillars of its definition.

Graham Lea argues in his post that the mental model of hierarchical roles in a software development organisational structure is an inaccurate representation of the real world, stating:

“Having a variety of roles conveys an inaccurate mental model of people’s capabilities, places boundaries on people’s responsibilities, and can be divisive if used as a motivational tool”.

He describes these roles as gradients of responsibility and skills as opposed to clearly defined skill boundaries.

For instance, an individual doesn’t end his day as a junior developer and start his next morning equipped to take on a senior role, but rather is gradually and naturally progressing to the level of skill required to be considered in that more senior role. Describing the mental visualisation as a slider between junior and higher-level positions as opposed to a switch:

Image credit: Graham Lea – “Why Smart Software Teams Don’t Need Senior Developers, Tech Leads or Architects”.

Others, like Chuck Groom in his article — “The Software Engineering Job Ladder”, argue for a career ladder by stating in his final thoughts:

“Employees want to know where they stand in an organisation. Having well-defined career milestones with expectations and objectives makes everyone’s jobs easier…

You can fine-tune your roles and values over time; but never violate the principle of fairness. Everyone must be held to consistent standards or else your morale and productivity will crumble. A good jobs ladder levels the playing field and lays out the rules to the game.”

This is the part that gets frustrating. So far as I can tell there is no clear “best way” to structure your business or tailor your culture to satisfy all the people and their perspectives on what the “best way” should be. It mostly boils down to a series of trade-offs.

Flat vs Hierarchical structure

There have been several articles written and studies done analysing this subject, some of them can be found here and here. Something to keep in mind is that while a flat structure sounds excellent in concept, and to be fair, it has a religious following in some circles, it is not a panacea.

There is always a power hierarchy, no matter what they choose to call it internally. There are analogies in nature for this behaviour that we cannot ignore. Some argue we are hardwired to form power hierarchies on a biological level and that they are unavoidable, not in business nor any aspect of our complicated social existence.

I am sure there are exceptions to this like anything else. Still, in my opinion, it is better to embrace reality and human nature than romanticise about a truly flat hierarchy.

Are you frustrated yet? I can’t make any practical suggestion as to which is right for you, of course, but I can share what our current approach is and what has worked for us so far.

Hierarchy within Haefele Software

We have a set of core disciplines some of which are development, business analysis and quality assurance; each has its hierarchy structure, they are all similar but using our development discipline as an example it looks as follows:

Individual team members are encouraged to hold all other members equally responsible for getting the job done, regardless of title and hierarchy in the broader business. Each member of the team is encouraged and empowered to challenge up and down within their teams. They are also encouraged to challenge other teams across the business for that matter.

There are no business-imposed communication boundaries between individuals on a team, no limitation on who they can challenge within their team. They are encouraged to mentor others, communicate with clients, argue architectural decisions and technical implementations. They are expected to question authority, drive and take responsibility for internal team processes and hopefully share learnings with other teams to make the business better regardless of job title.

Effectively giving us the best of both ideals, in my opinion. A natural, well understood corporate hierarchy as well as all the best bits of Kaizen and others offered by a flat structure.

We think we are getting better at this and getting closer to an answer to the problem of culture and structure for us as a business. But we review this often, inviting and welcoming criticism of this model from everyone in the company.

Our career growth framework

In the follow-up article to this one, I’ll detail our specific implementation of this framework. Sharing a few prior versions of it, what we learned along the way, and hopefully, it is useful to you in your career growth framework.