• People
• Organise
• Android
• iOS

The Thinking - How we as a small agency redefined our career framework

With our motivations and guiding principles in place, I started to research and to define. I began gathering my thoughts in a private Miro board. If you're setting out to define a career framework for your organisation, you may find some of my observations from along the way useful.

The article reading list

I read. Lots. And lots and lots.

Every new article I read generated 3 more that I wanted to read!

Before very long I realised I would need to effectively catalogue my research, and I'd highly recommend you do the same, as this can really help battle the 'overwhelm' factor.

I started a 3-column reading list table, with a score-out-of-10 and a space for excerpts:

Link to the article

Usefulness score / re-read value

Insightful excerpts

This helped me organise my thinking and make subsequent references back to the things I'd read much more efficiently.

There's value in most of what I read, but the excerpts column also helped me to avoid marking everything for re-reading later, since there were often just 1 or 2 key excerpts which I wanted to retain. Some articles were just good for building up my 'feel' of the topic and didn't need revisiting.

Avoiding paralysis of analysis

If your experience is anything like mine, the research phase could be never-ending. At some point you have to stop reading and start applying what you’ve learned.

Cataloguing what I read helped to show when I was hitting the threshold of fewer new and unique insights – when most articles only contained what I had already read elsewhere.

I don't want to contribute to any potential information overload, and the most helpful articles change over time, so I haven't tried to reproduce a reading list here. Be sure to do some reasonably broad general searching at the outset though using your search engine of choice, to seed your reading list with a variety of starting points.

Evaluating public reference career frameworks

Beyond just reading 'around' the topic, there are many companies that have generously shared their own job ladders and career frameworks publicly.

Career frameworks come in many different shapes and sizes, catering to the many different types of companies that use them.

You'll likely have some reasonably quick intuitions around which of these are likely to be a cultural fit for your own organisation, without getting into the content and specifics of each one.

For instance, it was clear to me that a huge matrix presentation just 'wasn't Brightec'. However good the content might be, it would just give the wrong impression to our specific team.

Our 'Make it yours' guiding principle was to generate something bespoke to our company, and avoid any cookie-cutter copies. Other public reference examples were perhaps more useful in helping to decide on the format we should drive towards than for their more specific content.

Dialling in a 'target format' for your career framework

The factors may stack up differently in your context, but for Brightec, these were my reflections on various different presentations to help us steer towards an appropriate career framework:

• Matrices (e.g. CircleCI or Rent the Runway)– These felt too dry for us. The rigorous structure felt a bit too restrictive. They also perhaps lend themselves towards being 'gameable' with people slipping into seeing them as a 'checklist'.

• Mini-sites (e.g. Inviqa) – Some of the mini-sites out there are awe-inspiring in their richness and depth. But they just felt too big for us (and indeed they can cater for many hundreds of staff). They didn't feel consumable enough.

• Bullet points (e.g. Basecamp) – Some companies keep things very brief indeed, constraining themselves to just a few brief statements. This felt too vague/loose for us, when we were reaching for more definition than we've previously had.

Putting all of this together, I decided to target a Slides/Cards format – one collection of paragraphs per role, constrained to fit onto a printable page.

Pay attention to visual and linguistic metaphors

One other observation I made while looking through reference examples of career frameworks was how easy it is to inadvertently employ both visual and linguistic metaphors that imply some unintended semantic meaning.

The most common one to remain conscious of is implied 'above/below' positioning. Be watchful for vertically stacked visual presentations, and language like "ladder" and "level", that can end up implying hierarchy or status.

Very early on, I determined that if we used a vertical presentation, our most senior staff would appear at the bottom of the stack. They are the foundation that we build on and who support and lift up their peers – not an elite group elevated above their colleagues. I was eager to avoid such language and arrangements altogether though, and pursue a less linear representation.

Observations on level definition and naming

There are several places where you can explore how other companies differentiate and order their job definitions (you could use a resource like levels.fyi for instance). You'll soon find there's a broad variation in approach.

I chose to review in detail 13 job level arrangements that I felt were most comparable and informative for Brightec, and catalogued what I did and didn't like about them according to what felt 'far from' and 'near to' what we wanted.

Taking the best of these, here's what felt closest to what Brightec was looking for:

• Prefer "Engineer" or "Software engineer" rather than "Developer"

• Prefer "Software engineer" at lower levels, and "Engineer" at higher levels

• Avoid acronyms (SWE, SDE, etc)

• Avoid numeric / rank level naming (2, 3, II, III) – our role set is too short to require it

• Customise role set and length to suit your organisation (3 levels is too few. 4 / 5 / 6 are options. 7+ is excessive)

• Pursue thoughtful internal naming for the lowest level (junior, associate, entry level)

• Use externally identical naming of the lowest two levels, with an internal band/title distinction

• In general, use non-prefixed external naming for the lowest two levels ("software engineer")

• It's reasonable to have "Principal" follow "Senior" if desirable

• Avoid "Distinguished" and "Fellow" which are simply too grand for an organisation of this size

• If an additional fifth level is needed, prefer "Senior Staff" over simply "Staff" for a UK context

A fair amount of thinking went into each point, but in summary, these felt like the right trade-offs for our context.

The decisions we arrived at

By this point, I had a lot of good constraints and decisions in place to shape the specific content of our new role definitions around.

• It felt like the right moment to change some of our long-standing historical language, by moving away from the term "developer" towards "engineer".

• We decided that the right number of role differentiations for our engineering team both now and for the near- and mid-term future, was six.

• We thought very carefully around other terminology we used such as "Tech Lead", "Project Lead", "Team Lead" and "Engineering Lead", and decided these were better represented as responsibilities within a role, not roles in their own right.

• We thought carefully around the naming and language for our most junior and senior roles:

  • For team members at the outset of their software engineering careers, we decided to continue using the term "junior" but distinguish it from "trainee".

  • For our more senior staff, we settled on industry-recognised language that was not confusing to a UK audience, and that felt distinctive without sounding grandiose.

  • We thought carefully about internal and external presentations of this language.

Taking all this together we had a starting point for our career framework:

Click here to find out more about how we defined the roles of the engineering team at Brightec.