• Organise
• People
• iOS
• Android

The Challenge - Is it useful for a small agency to have a career framework?

An excellent question to ask before you embark on creating any kind of framework for career development or progression is 'do we actually need this?'

As Brightec's Head of Engineering I certainly asked myself that question (often!) and frequently revisited my answer. I'd worked within such career frameworks at previous larger companies, but in a smaller agency setting I wanted to feel fully confident it was the right direction for our context.

Ultimately, a combination of observations and desires were what cemented that conviction, alongside some of the principles that underpinned it.

Observations about our existing career framework

Observation 1: Staff feedback

A single post-it tucked away under the 'People Development' heading of one of our staff retrospectives, in the most sparsely populated section of the feedback:

"More structured path to junior/middle/senior?"

I immediately resonated with the sentiment because it matched what I'd already been thinking about. 'How well were we helping our engineers grow and develop?' was a thought I rarely went long without revisiting.

But this was an important data point - an opportunity, maybe. I was not the only one thinking about it. There was an appetite, perhaps, for change. Read more about Brightec’s drive to continuously deepen our understanding of our art.

I think it's really important to gauge where your team is at, and to be ready to encourage and enable them without 'outpacing' their own desire for growth. The fact that at least some individuals had started to ask this question was a great signal we might be ready to evolve beyond our current setup for engineers at Brightec.

Observation 2: Outgrowing the status quo

I already had some of my own observations about the existing setup. Historically, Brightec had only ever defined three different software development roles - junior developer, mid/intermediate developer, and senior developer.

Over time, we had already expanded as a team. We'd grown numerically in terms of sheer numbers, and even aside from the new additions to the team we'd also grown older and wiser in our experience and skills.

As far as the team makeup was concerned, this manifested as a sort of 'bunching' around the senior developer role.

We are known for great staff retention. This meant our junior developer role was feeling somewhat underused as various individuals progressed. What's more, our senior role was feeling increasingly 'muddy', describing an ever wider range of expertise.

Observation 3: There wasn't a big problem

That said, we really weren't facing any large or imminent crisis in this area. 'People Development' and 'Staff Buyin' were the business areas receiving the least feedback from our team, and individuals were generally feeling satisfied and supported. Find out more about how we look after the wellbeing of our team.

I was looking ahead though - a year, maybe two - and wondering whether that would remain the case if we didn't act. Our core desires for the team and its future seemed ready to take us beyond what we currently saw.

Desires for our ideal career framework

Brightec believes passionately in and thinks deeply about holding authentic, meaningful and useful values. It's one of the things that drew me to the company in the first place. Read how we created useful and meaningful Company Values.

I just couldn't ignore the difference in the level of detail and care with which we'd articulated those cultural principles and that which had been applied to our day-to-day responsibilities as software engineers.

As I thought about what it meant to be confidently humble, I reflected that I was confident in our team and processes now, but I didn't want to assume the existing set-up would continue to support us effectively without evolving alongside the growing team.

As I considered the continuous improvement we were all practising, constantly making things better, I wanted to apply that to our career development as well.

So I gave myself some space to think, purely and without constraint, 'what do I want for our team?'

Three key themes emerged:

Desire 1: Room to grow for all software engineers

I wanted Brightec to remain a great place to work for every individual, and that meant no one becoming limited by a lack of 'headroom'. I looked at what we'd so far expressed, and wanted to be able to say to every software engineer: 'Your career doesn't finish at "senior"'.

I'd also noticed that it tended to be easiest to focus on serving the team members in the middle of our experience range, and risk inadvertently under-serving both our most junior and most senior individuals. I wanted to help every engineer learn and grow, and understand their role and the expectations of them.

Desire 2: Articulate our engineering roles meticulously

We've spent a lot of time over the years honing and refining the way we articulate the things we believe in and the team we strive to be. As a matter of principle, I wanted to be similarly dedicated to articulating what 'engineering' meant to us, so we could all align around this and keep growing together.

Desire 3: Keep 'valuing people' at the centre

From the weekly kudos board right through to our job titles, we want every part of Brightec's organisation and culture to support us in helping to recognise and thank people for their contributions.

I felt instinctively that sufficiently expressive job roles could help us to do this even better, enabling us to more specifically call out and praise the many ways in which our team was pushing boundaries and going above and beyond 'baseline expectations'.

Principles for defining a new career framework

In reflecting on the above, five key principles were apparent to me that I felt should underpin any change we made. Before setting out to explore what approach we might adopt, I wanted to establish these as guiding lights to keep us on track.

Principle 1: Naming matters

Key question #1: What do we call it?

Like it or not, words matter. And so job titles matter, both to us and our clients. I wanted to apply extensive care and consideration to the language we settled on.

Principle 2: Meaning matters

Key question #2: What does it mean?

Beyond what you call it, there have to be meaningful and codified distinctions in what we expect across our job roles. We've all probably had some experience of a title or accolade that seems to be 'just for show' without any real depth of meaning. I wanted to pursue real semantic depth in what we were expressing.

Principle 3: Make it yours

I firmly believe (and will reiterate at every opportunity) that a career framework has to be bespoke to your company - a cookie-cutter copy from a different organisation is doomed to fail.

That doesn't mean you shouldn't take inspiration from all the brilliant resources and examples that are out there (more on that in the next post). But I was determined to define something just right for our team and company, and I wasn't just going to find that lying around 'pre-baked'.

Principle 4: One size definitely does not fit all

Brightec was still at a relatively small scale to introduce a more structured career framework, and this was a crucial factor in identifying the right way to express our engineering roles and responsibilities. I wanted us to think deeply about what the right size was to introduce such a framework, and whether we actually had that critical mass. A precondition of the exploration for me was that we were willing to abandon the effort and retain the existing system if, after further research, we felt that's what was most appropriate and beneficial.

Principle 5: Make it consumable

Finally, whatever we ended up with (even if it was significantly more extensive than what we had at the time) I felt it was imperative that it was consumable for the team. If you can't easily understand and engage with something, it probably isn't that useful to you. I had a difficult tradeoff in my sights - something both concise and powerfully expressive.

Lots to think about...

As you can imagine, this left me with lots to think about! Achieving this endeavour in a way that satisfied my very personal sense of responsibility for it was going to be no mean feat. But we'd framed the problem, which was a great starting point.

In the next post you can read about how we further reflected on, analysed and reacted to these observations, desires and principles.