I’ll be the first to admit that some progression frameworks are lacking in substance, often speaking in banal generics and lacking tangible examples. I know this because I’ve written plenty of regrettable howlers.

Without a progression framework, or at the very least a list of expectations for a given role, you’re hanging people out to dry. You’re opening up performance reviews to all those wretched cognitive biases, which is why something is better than nothing but a coherent progression framework is the current gold standard you should be aiming for.

Virtually all tech companies will have have a career ladder that goes something like junior → mid-level → senior → very senior → super-senior. A progression framework describes what is expected on each of these rungs, across multiple dimensions such as skill, communication, engagement, leadership, and so on. It’s called a progression framework because it will make clear how each expectation progresses from one level to the next, as this seminal ‘rope analogy’ example from Radford demonstrates:

When people are hired they’ll be taken through interviews and technical challenges and an assessment will be made on where they sit on this ladder. On this, where things are not clear it’s better to match people against the lower level. This sounds tight-fisted, but acknowledging a mistake and promoting a mid-level hire to senior after a couple of months in the role is easy. You’re doing nobody any favours by hiring them into an overly senior role just because it’s the role which matches the salary they want. This won’t end well, believe. But I digress…

The same assessment is made for each person during their (annual, bi-annual, whatever) performance review, which will be far more accurate than the initial hiring assessment because you’ll have a wealth of direct on-the-job evidence to draw from by then. Making a fair assessment is where a progression framework comes in. A progression framework allows you to articulate, in depth, what it means to be a mid, senior or principal engineer at your company. It’s crucial to developing someone in their career, which keeps people more engaged and less likely to go looking elsewhere for a new challenge. People need to know where they’re at, and what they need to do in order to get to the next level. How can you do this without some sort of benchmark? Spoiler: you can’t.

Introducing a progression framework will be a challenge. You’ll hear cries of pigeon-holing and box-ticking, which isn’t actually unreasonable – it's usually just a misunderstanding. There’s an inherent fear of receiving critical feedback if you’re not used to it, but feedback is essential to improving performance. Just ask anyone with a personal trainer. At some micro level, you are putting someone in a box called senior, or staff, or whatever. You’re making an assessment and you’re calibrating people against others. This sounds rather awful, mainly because of the unpleasant and dehumanised HR language ("assessment", "calibration", "review"). I’ve been guilty of this, of course, but with a bit of imagination you can avoid the jargon.

At smaller companies, especially ones like 37signals, creatives (by which I mean programmers and designers) are working so closely that someone’s skill level and overall contributions will be obvious. You can see what they’re producing and the impact they’re having day after day, so why do you need a new and irritating "box-ticking exercise"? It’s a good question, but manager-lite arrangements with highly technical supervision are just as open to bias as more "professional manager" setups. Recency bias after shipping that popular feature. Primacy bias because you still remember their first ever project which they absolutely nailed. Halo effect bias because that person’s performance peaks are so fucking high despite the fact their day-to-day performance is a flat calm, even atrophied, most of the time.

To earn trust in the framework, you have to be able to demonstrate its value to everyone it affects. In time, it’s likely you’ll get buy in from most, if not all, because people will see it working for them and for their peers. If the worst happens and the whole thing is an abject failure, don’t hesitate to admit it. Throw it away and reset. Lean on your teams to find a better path forward.

If you’re not using a progression framework right now, you should create one. If you are using a framework, be sure to reassess it every couple of years. Always get input from those at the front-line. There are plenty of examples out there to gain inspiration from (or outright steal), but remember it’s always a time-consuming exercise, but one with a high return on effort. Don't scrimp, just take your time.

People often moan about meetings, often for good reason. Here's how I deal with them.

I read an article recently about how GitLab automates engineering management. My interest was piqued by the title but watching the accompanying video left me wide-eyed. Using Google Docs, the script editor and copy/pasting long alphanumeric IDs doesn't strike me as particularly fun or efficient. It seems like a very high barrier to entry, but I guess it works for them 🤷.

I'm not getting involved in the meetings versus no meetings culture war (you're both right), but on the back of the GitLab article I thought I would write about a way to keep track of the meetings you run.

Unless you work at Gumroad, I'm assuming that you participate in some sort of meeting at some point each week. At the very least I would recommend having 1-1s with your manager/reports weekly (or thereabouts... but I do recommend weekly). Meetings work best when there's an agenda prepared in advance (at least one working day or more) so that attendees can prepare themselves, and also so any reference materials that might be relevant can be shared with time for people to read it. Depending on the type of meeting (e.g. incident review), you might also want to take minutes, list attendees and note down action points.

Using a good tool like Notion (which is my current preference) for these agendas can make your life a lot easier. Here's one way to do it.

A home page for your meetings

Notion is a wiki so works hierarchically. Create a new page to act as the root for all your meeting notes (in reality you'll likely have multiple roots) then embed a database into this page. Here's a contrived example:

Having all these pages/notes in a database is brilliant because as the number of pages grows, you can add filters and sorts and different views. It's really powerful, but the UX is kept reasonably simple.

Create templates for different meeting types

The power of using Notion for this is that you can pre-define templates, which are essentially different page layouts. Once you've defined a template, you can create a new meeting agenda from it in a single click, and all the annoying boilerplate is pre-populated for you. No copy/pasting required.

Here's what a 1-1 template might look like:

Templates can be used for weekly leadership meetings, team retrospectives, and they are extremely useful for incident response – both living incident docs as well as post-incident review meetings. When things are on fire, you want to create an incident doc without thinking about it at all – you certainly don't want to resort to copy and pasting Google Docs.

(Note: I've included some example templates at the bottom of this article.)

A meeting manifesto

In many ways this is less about the tool and more about the process. A good tool (like Notion, but there are plenty of others!) can/should be intuitive and reduce cognitive load from repetitive tasks.

Regarding the process of meetings, what I've learned over the years is that meetings (when you absolutely must have them) should:

• Be concise (always bear in mind Parkinson's Law).
• Have a very clear purpose and need. First ask yourself if you could just send email or another form of async discussion thread instead.
• Have an agenda. For all the reasons described above (justification, consideration time, reference material etc).
• Start and end on time. Ideally it will end before time!
• Have an agreed, documented outcome. This might be a firm decision (e.g. "hire / no hire") or some clear actions, each of which are owned by one person and clearly documented.
• Have a chairperson. The chair owns the meeting and must make sure it runs like clockwork, ensure everyone who needs to be present is, and will follow up on any actions until they're all complete.

I've found these to be really helpful guidelines over the years, but I've also found it very difficult to enact culturally however much 'leading by example' you try to do. Old habits die hard, and you have to over-communicate this stuff tirelessly. Thankfully, if you spend time reducing your meeting overhead as much as possible this won't be a massive problem.

Links to my Notion templates:

• 1-1
• Incident

Photo by Sigmund

Your first 90 days in a new leadership role (in particular, a VP Engineering or CTO role) will be largely spent in orientation. You'll be getting to know the ways and hows of the business in detail: its culture, its values, its structure, its current priorities, the things that work well and, of course, the things that don't. You need to see warts and all, leaving no stone unturned.

A big investment of time will be getting to know your peers on the exec team (your first team): what makes them tick, what are their strengths, what skills are they working on ("weaknesses"), what are their frustrations, what are their interests. Similarly, you'll be getting to know the people you're managing as direct reports. First impression count. On both sides.

Approaches to tackling the first 90 days in a leadership role have been well documented already, so in this article I want to focus on using a SWOT analysis-based framework for helping to identify the priorities of a department or organisation, in order to shape team strategy. This isn't a technique intended to replace the job of getting out there and meeting with as many people as you can – that's still crucial for building relationships and trust. It's a structure to use for an information gathering exercise that has proved really useful to me.

While it's especially useful for people coming into a new leadership role, I've found it really valuable as a recurring annual exercise to run in your engineering organisation. Change is the only constant in life and you need to keep up.

SWOT analysis

As defined by Wikipedia, a SWOT is:

a strategic planning technique used to help a person or organization identify strengths, weaknesses, opportunities, and threats related to business competition or project planning

Put simply, this means gathering views from across your organisation about what's good and what's not so good, both internally and externally. This diagram explains:

How to run the process

Survey the team

In order to gather the feedback, publish a Google Form (or similar) to allow participants to easily provide answers to the four basic SWOT questions, anonymously. The form goes to everyone, across the board – individual contributors (ICs), testers, engineering managers, IT and security staff as well as the leadership team. My form looks like this:

Allow people a couple of weeks to complete the form, you don’t want to rush it. Participation is optional but push for people to make every effort to complete it. You'll have to chase people (engineers typically have a lot on their plate), but aim for 70%+ engagement.

Wrangle data

Once submissions are closed, you need go through the data and collate the responses into themes. There are probably some clever technical approaches you could apply here, but is it worth the time? For better I worse I always use a manual, brute force method which, on balance, is good enough despite being more art than science. It will take a good couple of hours to do this but that's fine because you probably want to read all the responses anyway.

During this data-wrangling phase, clusters of 'hot topics' will start to appear alongside a long tail of more fragmented ideas and feedback. The long tail ideas are interesting but it's the hot topics that will become your key areas for further discussion and prioritisation. You'll take these to relevant teams, start discussions, run workshops and eventually factor work into your roadmap.

The good thing about SWOT is that it focuses as much on the good stuff as the not-so-good. Don't just pay lip service to strengths and opportunities – these are the things that are working really well, and things to get excited about for the future. Analyse strengths and opportunities and see how you can capitalise on them elsewhere.

Communicate

You don't want all the effort people have put into the survey to be left unrewarded, so it's important to communicate your results. Create a slide deck and present the results in your weekly engineering all-hands meeting (if you don't run one of these, this is your excuse to start!).

When taking the team through the results, I'll first present the previous year results (obviously only if we've run a SWOT before!) and reflect on whether we managed to take action successfully. It's important to look back and celebrate wins, however big or small – it's so easy to overlook this because it's natural to be looking forward to the next thing, and the next thing.

Finally, after presenting, I'll run a Q&A to allow everyone time to ask questions and give feedback.

Take action

The main point of running the survey is to identify actions to prioritise. I'll work with my leadership team on how we can work the most pressing actions into our strategy for the upcoming year and get them factored into team roadmaps. Some of the actions might be big-ticket projects which will require a lot of further analysis and discussion, but there will be plenty of low-hanging fruit as well.

Outcomes

Over the years I've been doing this we’ve had some really big wins. The first time we did it, the most problematic area by far was deployment pain. There were too many steps, not everyone had the ability to deploy, it was increasingly time consuming to get changes out of the door and we had no clear plan towards continuous delivery. As a result we prioritised the building of an entirely new CI/CD platform which had a dramatic effect on number of deploys per day and led to a happier and more productive team! It wasn't like we didn't know this was a problem before, but surveying the entire team and getting unambigious raw data from dozens of engineers gave us a much-needed reality check.

Of course the big wins are not a result of this particular framework. It's just one of many techniques you could use. The underlying message here is to give everyone on your team a voice and demonstrate that you are listening.

Photo by @jamietempleton

Sometimes you come across a fantastic article that is totally relevant but seems positively jurassic in internet years. Maybe you actually read it at the time, years ago (especially if you're a quadragenarian like myself). If you did, maybe you even briefly experimented with the approach, but most likely you forgot all about it and moved on to reading the latest articles because surely they're more relevant and contain better advice?

This gem from Werner Vogels is twelve years old. It describes how Amazon approached software service development to ensure they remain "customer obsessed" (noting that the customer could be internal or external). It's as relevant now as it was in 2006 and it's a worthy reminder about why software development needs to focus on the customer, why it should always start with simplicity, and why software teams need to be brought together with a shared vision.