Progression frameworks for smaller companies


Most of the organisations that have their engineering progression frameworks listed on progression.fyi are at least medium-sized. Many are very big indeed. It’s very easy to fall into the trap of assuming that a similar approach would work for a smaller organisation.

As a company grows, it’s not always clear at what point a progression framework is needed. Introduce one too early and it feels like unnecessary bureaucracy that can’t be handled by that size of organisation. Too late and a lot of the problems of not having a framework have started to become entrenched and difficult to deal with. This latter problem is the one I’ve had first-hand experience of.

One of my coaching students, a Head of Engineering at a growing startup, recently asked me how he should go about creating an engineering ladder. He had already sketched out possible levels like Software Engineer I, Software Engineer II, etc.

This is jumping the gun. It’s like starting a design system by diving straight into building all the components you think you might need, free of context or exploration. Titles and levels are not the first thing you should be exploring.

Remember, the aim of progression frameworks is to provide some explicit clarity to staff about what is expected of them, and to give them a clear path of progression within the company.

In larger organisations, it’s necessary to formalise explicit levels to communicate this in order to reduce the differences between managers and teams in how progression would otherwise be handled.

But in a smaller organisation, it’s more important to link expectations and progression clearly to the company’s mission, vision and values. For very small startups, this can be done at an individual level.

In other words: a role description, person specifications and personal development planning. For some reason, these are rather out of fashion in early startups, possibly because the assumption is that the role will change so quickly that it’s not worth writing down what it is or what you think it might be next.

I disagree. I think creating role descriptions for everyone is helpful immediately in setting expectations and providing constraints. It’s just that a startup will likely need to change them more frequently as the goalposts move. Being comfortable with that is part of working at an early-stage startup.

Once the company is bigger it becomes a lot easier to consolidate existing roles into a more formalised progression framework if there are already good role descriptions, and hands-on experience of helping staff to progress at the company. In other words, the company has already learned a great deal from a series of deliberate attempts at progression.

Do you have a job or role description? Does it accurately reflect what the expectations are around your role and what you need to do to progress?

All the best,

– Jim

Receive emails like this in your inbox

I write about front-end engineering leadership every weekday.

Sign up now and get my Front-End Engineering Responsibilities Laundry List PDF for free.

You'll get regular emails about front-end development. Unsubscribe at any time.