A few weeks ago, our CTO James Eddison shared a great “careers path” form with everyone that worked in our tech team. The aim was to ask us questions we maybe hadn’t asked ourselves about which areas we wanted to progress in and, at the same time, highlight all the areas we could progress in at Octopus. Even after 6+ years here, it was still a fascinating exercise.

One thing struck me though, and it’s a similar issue I’ve experienced in all of my past jobs: what does progression look like if you don’t want to be a manager? The form of course asked if you were interested in that, and it is the most traditional route. For me, there’s always been this natural crossroads at the places I’ve worked where, however long it takes, you eventually reach that same decision of whether you’re going to manage projects and/or people.

What are we offering?

For what it’s worth, there were a lot of different avenues in the careers form - everything from client support to helping with sales. They all take you out of your core job though. Variety is a lovely thing, but these still represent to many a journey away from the thing they love in order to move forward.

The other natural alternative is “domain expert” work - becoming the code owner of a feature or part of the codebase. This feels more dev-centred, but it’s quite specific and not to everyone’s taste, as there’s often a fear of being stuck in one area for a while and, ironically, not really progressing.

All of this got me wondering about whether this could be better solved in most cases from within the teams and disciplines we have:

If we were failing people not taking the traditional route, what could I offer my team to encourage progression absent management?

At the same time, I’ve written before about the struggle of going from being the one person who did everything in front-end to the person in control of even more but without the time to do so. Lots of responsibilities I have naturally accumulated over time don’t fall neatly into a role. It’s because of this that they’ve sat with me for so long - they were things I wouldn’t want to heap onto managers as they already had a lot to contend with.

Within these things is certainly variety though - we have writing and speaking, presenting, training, recruiting, mentoring, and that’s just naming a few. They’re things that help the company and the team, but importantly aren’t line management.

They’re also things that often suffer when left unattended, or without someone’s full attention to keep them at the level they had been previously. For example, we have a weekly team catch-up called “State of Front-end”. As a team (and company) that likes to keep meetings to an absolute minimum, this one has taken on importance over the years as:

  • 👋 A check-in with everyone to see how they’re doing
  • 💬 A forum for discussion and debate
  • 👩‍💻 A show-and-tell area for new approaches and technologies that could benefit us
  • 📰 A newsroom for me to share anything and everything I can about the company’s direction with the team
  • ❤️ A safe space to question practices and processes

…and I’ve probably failed to mention a few other things. We’ve regularly questioned its existence to be sure that it’s not a waste of time and, time and time again, it’s proven immensely popular. However it requires planning. Guest speakers and team speakers need organising. Regular topics like retrospectives need respecting and owning. There’s also dozens of other ways it could be improved, and directions it could be taken, that haven’t been considered as I’m frequently organising it on short notice after the week has gotten away from me.

This is just one example - it’s valuable to a person and the company, takes something off of my hefty plate, and provides an opportunity to own an important aspect of the team without needing to be a manager (or even a senior or lead developer).

Forfeiting responsibility

Now, this is typically a scary thing, as forfeiting responsibility will naturally make you feel less useful or needed. However, I’ll never not be busy as the team grows in size and across the world. The last thing I want is to be gatekeeping someone’s progression, whilst also doing a bad job of the thing I’m owning.

So to focus on what I should (which is chiefly helping the team grow and progress), give others the chance to advance absent management, and raise the quality of the things we do in the front-end team, I made a bounty board.

A what?

A bounty board! (I may have been playing Red Dead Redemption at the time). In our internal Notion, I now post things that could do with more attention in front-end. If someone in the team is interested in anything on the board, they just get in touch with me. These things are open to developers in every country, can easily be done remotely, and most of them can be done by a developer of any level of experience.

The biggest thing here is that these “bolt-ons” to someone’s role need to come with tangible rewards. That’s why completing things from the board will have a noticeable impact on reviews and progression (they’re taking on responsibility after all!). So if someone is making their way up the progression bands at Octopus and aren’t ready for management yet (or don’t want to manage), then this will significantly help their cause.

If someone likes the look of a few and can’t decide, we have a chat and I suggest what I think they’d be great at.

Finally, it’s important to mention that it’s perfectly fine to not want to do any of these things. If someone wants to solely focus on improving their skills as a developer, they’re free to do so without pressure to do otherwise. What I’m most concerned about is asking the right questions so that, much like the careers form I mentioned above, people can ask themselves things they may not have done before. This board is something someone can ignore for six months and then suddenly pick something from. It’s something that may not have anything of interest for a developer until I post something months from now that ends up being exactly what they were looking for. I may even have managers who’d prefer to do three things from the board as opposed to line managing developers. People change their minds, and now it feels like we have a place where they can consider pivoting from.

A work in progress

I haven’t been running this for long, but the response has been amazing. Developers all over the world have reached out about things on the board, and we now have people taking on new responsibilities that had been left to go a bit stale previously - doing so with enormous enthusiasm. It’s also created a new conversation for team leads and mentors to have with their devs.

Importantly, progression is no longer a friendly nudge down one inevitable path, but more of a friendly nudge to a crossroads with many possible paths. It’s a chance to ask your employees if they’re ready to wander down any of those paths, or if they’d prefer to just relax there for a while.