As the kind of person who sticks around at jobs for a long time (I’ve had precisely two of them in the last 15 years), It’s a daunting experience to be staring at an empty calendar and not knowing yet what the near future holds, and whilst in my case it is with at least something lined up, I know that for lots of people the experience of waking up jobless on a Monday morning is a more traumatic one, and I know that amongst the subscribers here there will be many of you who are in this exact predicament. And so today I wanted to just give my sense of where our industry is at, what the hiring market looks like and to perhaps give some consolation to folks who find themselves back in the job market, and the job market being nothing like it was the last time they were in it.

The Polarisation of everything

The first thing that became clear to me as I started to look around at the market for design and design leadership roles is that we have entered into a period whereby lots of companies seem to have raced to the extremes across all sorts of things for which the right answer is almost always going to be somewhere closer to the middle. The whiplash of post-pandemic RTO policies has created companies which are now incredibly dogmatic about the specific desk from which web-based work gets done, and whilst in some cases that has created new opportunities, it has undoubtedly robbed lots of people of them too. For every company with a sensible location policy there seems to be a dozen for whom 3 days of commuting is now seen only as a marketable perk of the job and not also as an often inefficient use of time and energy.

Similarly there are companies for whom large language models are now not merely an ecologically disastrous technological curiosity with some limited utility, but are instead the critical and unquestionable fulcrum of the entire software manufacturing process which is not to be audibly doubted or - god-forbid - circumvented, even if it means doing worse work, slower, at higher costs.

Perhaps related to that, there is also a hollowing out of mid-career positions, with instead a focus on junior hires complemented by a small number of super-senior ICs and the mythical “player-coach-design-leader-magician”. Most people in our industry are - and still need to be - in mid-career IC level roles which for reasons not entirely clear to me are now unfashionable.

I know that for my personal tastes, the kind of organisation I like working in is one which is not dogmatic or extremist about anything, and is instead willing to flex, bend and adjust based on reality, and the changing dynamics of the world in which we operate. And because I’m a contrarian, I might even prefer to work somewhere that zigs when everywhere else is being convinced to zag by a chatbot, or by whatever it is that Amazon are doing. The companies that win rarely seem to be the ones that do things exactly like everyone else does.

Basic decency is in short supply

Perhaps it has always been this way and I have been blissfully unaware of it, but I am hearing horror stories from lots of people who are being treated with what feels like utter contempt from hiring companies.

A complete lack of feedback on case studies or spec work, job descriptions being changed part way through hiring processes, salary bands being reduced at late stages, and all sorts of really shoddy candidate experiences which seem ignorant of just how small a world tech still is, despite how it always behaves.

There is no world in which it is acceptable to ghost a candidate, even if there is a sense that the power balance in the hiring market has shifted back towards employers after a long-period in which they needed to fawn over candidates just to get them through the door. No doubt the high turnover of people in recruitment teams which are always amongst the first impacted in mass-layoffs is part of what is creating these broken processes, but it feels like it is more than just that.

“Leadership” as a nice to have

The final thing I have spotted on my travels around the hiring market is that for lots of organisations, technical leadership roles are being seen as a luxury and not a necessity, with design teams being moved to report into Product, or Engineering organisations. You see this most acutely with the rise in multi-portfolio C-Suite titles, whereby a Chief Product & Technology Officer, or a Chief Product & Marketing Officer is overseeing a portfolio which includes design, but which rarely treats it as an equal partner with the bits between the ‘C’ and the ‘O’ in their job titles. This obviously creates organisations which are sliding backwards on the design maturity index, and whilst it will create short-term cost advantages, it will also create brittle design teams who will themselves be more tempted to jump into the job market, even one as hostile as that of 2025.

It’s not you, it’s them

If you’ve been interviewing, I’m sure none of this will be a surprise to you, but perhaps there is some consolation in the knowledge that it’s not you, it is definitely them, and that this period will end and hopefully it ends with companies being less dogmatic about the way they operate, less shoddy in the way they treat candidates, and less blasé about how they structure their teams in order to help them build great stuff.

The first thing to say is that promotions are not logical. They are not the result of consistent, well described, rigorous processes. They come about in all sorts of ways, are blocked for all sorts of reasons, and sometimes after all the effort to get one, end up being a poisoned chalice.

Some things to keep in mind:

1. Performance & Promotion processes are always mid-refresh - Promotions tend to happen in an annual or bi-annual cadence in most large organisations, and at any given time the processes and parameters which define promotion eligibilities are either being rewritten, being implemented afresh, or are stagnant to the point of being ignored by at least part of the business.

2. Promotions are first-and-foremost a budgetary decision - Performance processes are primarily constrained by the amount of money available to uplift salaries and bonuses in line with the pay scales. You might’ve had the most phenomenal year of consistent over-performance, but if the company can’t afford (or won’t prioritise spending) the extra money required to promote you, you aren’t getting promoted. Obviously no one is ever going to give you this as the reason for not being promoted, you’ll be given development points and they may well reflect real areas of potential improvement, but it doesn’t always mean these are the reasons you didn’t get a bump in level.

3. Different disciplines value different things, and these differences become points of competition - As we’ve covered several times here previously, once promotions and performance reviews go into cross-disciplinary and cross-departmental calibration, designers are weighed against other disciplines who are likely better understood, better represented and more easily measured from a bottom-line perspective. This will often mean designers missing out because the finite pool of promotion cash will go towards these simpler cases.

4. Sometimes, it is personal - As much as organisations work hard to remove biases from these processes, it is impossible to remove the human - and therefore inherently biased - perspectives from these processes. It’s probably healthier to reconcile this than to try and overcome it, a manager who likes you is always going to be a better sponsor than one who doesn’t, and an exec who values design is always going to be better going in to bat for you than one who has only a cursory understanding of what it is you do all day.

5. Be careful what you wish for - Even if you are fortunate enough to be promoted in the current chaos of our industry, it isn’t always sunlit uplands on the other side of the title change. With that promotion will come greater scrutiny, heightened and more vague expectations, more meaningful bonus and salary adjustments, and more pressure. Some people thrive on that kind of situation, others most certainly do not. You do not need to continue climbing the ladder to the point where you promote yourself into failure, burnout, or just being miserable every morning at the prospect of opening your laptop.

So I just wanted to start the week with a little rallying call, for those of us who do design work because we want to make things better in some small way. The job is not the software. The job, for designers in particular, is to make things which are good, or make better things which aren’t. And whilst these tools toys are good at making things quickly and (artificially) cheaply, they are not good at making things well.

Whilst many of us right now find ourselves in organisations which are breathlessly mandating the use of these things, there will be a course correction - a time when people will again come to appreciate the value of things being made, not just regurgitated, and when people will seek out those products and services which care enough about their users to actually make things for them, instead of outsourcing that work to unsustainably funded, ecologically disastrous, lying autocomplete machines.

Have a great week.

At the core of my complaint with this type of performance management processes is that it relies on observations typically drawn from people who have too few of them and who are under-qualified to make them because they often aren’t designers and therefore lack the depth and breadth of understanding with which to contextualise their already thin perspective. This is not a criticism of those people, but of the process which asks cross-disciplinary and often non-technical peers to weigh in on a role which is still poorly understood in almost all businesses. We would be - and I’m sure are - equally lacking when giving input on the performance of sales managers, operations teams, marketeers and data scientists.

In a LinkedIn post pointing to my previous article, my friend Andy Budd summed this up nicely:

One of the biggest frustrations I hear from designers I coach is being held accountable for the business success of a feature they had little say in shaping. Maybe they flagged issues early, pushed for improvements that never landed, or had to quietly execute a flawed idea. But come review time, they're still measured by the outcome.

The result? Performance evaluations often feel like a lottery — heavily influenced by the project you were assigned, the strength of your peers, and whether your PM liked working with you.

Andy goes on to suggest designers keep a Brag Document, and this is pretty much where I have ended up in my thinking on this topic, albeit with a more functional and hopefully easier to sell name - the Logbook.

Logbook Template

The logbook format is a simple way for designers and their managers to keep a running record of everything a designer has worked on, such that come the end of the performance period there is a readymade document to use to guide, inform and steer the debate on performance which comes from performance calibration sessions. The logbook does a couple of things which I think are valuable:

1. It provides the context for the work - the business problem being solved, and crucially the articulation of that problem from a Product Manager in the form of a hypothesis or a PRFAQ.

2. It ask for specific feedback from peers in real-time on the aspects of the work which they are qualified to weigh in on. An engineers will be asked about the implementability of the design work, a data scientist will weigh in on the measurability of the design work and the business outcomes attached to it. Product managers will talk about that business impact and the role design played in achieving it.

This targeted form of feedback avoids the tendency I have seen in these processes for people to make broad generalisations based on narrow datasets, and instead embraces the narrowness of the collaboration by going deeper on the impact of the work.

The logbook also includes a list of deliverables which the designer created, not just the end-state of the work which may or may not have gone live, but the thinking, the synthesis, the exploration, the version the designer considered the MVP, the version which was subsequently shipped as the MVP, the fast-follow, the long-term vision, etc, etc. This shows the work, not just the tip of the iceberg which we are typically showing peers through other processes.

Come the end of performance period, the manager has a list of logbook entries which:

• Cumulatively represent the total impact of the designer

• Describes feedback from a broad range of informed stakeholders

• Includes work which goes beyond the superficial

This document is - in the aggregate - therefore a much more robust reference to take into a performance management process which is likely under pressure to conform to population bell curves, stack ranks, and budgetary constraints, all of which apply downwards pressure which is disproportionately felt by our discipline and others like it.

In that process a manager then has the opportunity to share the logbook, and ask for input on it, not on performance in the abstract based solely on broad and shallow 360 feedback. Reassured by the thoroughness, specificity and representativeness of the feedback, I think it’ll be easier for design managers to prove performance this way than it is with anecdotal, opinion-driven, low-quality observations drawn from a distance. This process also allows designers to feel some greater sense of control over their own destiny. They should have a pretty solid grasp of where they stand by themselves looking at the logbook and the feedback therein, and the most proactive amongst them may even look for in-period opportunities to course correct and show a willingness to improve upon emerging areas of development.

If there is one single sentence summary of this newsletter so far it is that design and designers are not like product managers and engineers, and the sooner we stop treating them as such, the better it will be all round. This is one of the processes where I sense we are most lacking in bespoke tools, and most in need of them.

What do you think? Would a logbook-driven performance management process work in your organisation? Does it solve the pitfalls I outlined above or perhaps introduce new ones? I’d love to get your thought on this and to develop my thinking on it with your input.

Just a quick note here to say hello and thank you to all of the folks who have recently subscribed to this newsletter. It’s both super energising and mildly panic inducing to see the calibre of people who are entrusting me with a slice of their inbox. If there are particular topics you’re interested in hearing about, or areas you think would be fun for us to explore together, do let me know.

Thanks,

Stuart.

Good luck out there 😬

I’ve long held a belief that observation-driven performance reviews do a disproportionate dis-service to designers. The model of managerial assessment, multi-disciplinary calibration and stack ranking performed at departmental levels lead invariably to worse outcomes for designers than they do for other disciplines because we are outnumbered by people who work in ways which are fundamentally different, and fundamentally incomparable. In this post we’ll discuss why that is, and outline some starting points for an alternative approach.

Iceberging

We’ve spent years working to demystify design, to open up the work beyond the artefacts to try and bring stakeholders along with the discovery process, the real heart of what design is. That hasn’t happened with performance evaluation. My sense is that there is still that same myopic focus on artefacts and outputs, and as a single part of a larger machine designers are therefore being judged on the superficial part of their work, and their minimal control over the life that work leads once it is in the hands of engineering, product or data science disciplines.

Sharpshooting

In lieu of significant exposure to designers and their day-to-day work, it’s often the case that peers from outside of design will be asked to draw conclusions on performance levels on top an absurdly thin set of data points. They may have worked with a design for a few hours across a quarter, or more likely members of their own team will have done so and so all insight is at-best second-hand. It’s unfair for organisations to put people in this position, but so long as they are expected to hold a view, or to dissent from one, they are always going to have to do so using the limited information at their disposal. We should stop asking this of them.

All opinions are equal, some are even worse than that

When design managers take performance reviews into cross-disciplinary calibration and review sessions they are always outnumbered and often trying to explain both of a designer and their performance at the same time. Whilst for other, larger disciplines in those rooms there is typically strength in number consensus and context sufficient for lots of well qualified input, there is rarely that same thing for design, and so in lieu of well informed opinions specific to design, participants will often fallback on the way they think about performance in their own disciplines - engineering managers will default back to thinking about outputs, product managers will default to thinking about stakeholders management and business performance. Non-technical peers will want to look at measurable outputs linked to high-level business objectives as they might for a sales organisation or an operational unit. None of these things are bad perse, but become so when used in isolation of the broad impact of design across these and many other areas.

We as design managers and leaders typically play into these knowledge gaps by trying to conform to those expectations in the way we describe performance. We will link design work to business results, highlight good examples of stakeholder management, talk about output of design work. This might help get us through a single performance period, and might yield what feel like good results for our teams, but all it does in the longer-term is to cement the idea that design is best measured in output, and is interchangeable with all other disciplines in terms of expectations. This is clearly a bad idea for the long-term health of a design organisation.

Logbook-based performance reviews

A thought percolating in my mind as I last went through a performance cycle was that designers would be better served by a much less amorphous process whereby work and the assessment of the work happen not in isolation of each other, but as part of the same integrated process.

That might look like a logbook of projects, each one with a success criteria agreed upon and defined upfront, a set of key stakeholders and their in-time feedback, and the artefacts of the work. It sounds like a clumsy and unsophisticated way of assessing performance, but it has some key advantages - the expectations are set in stone on a per-project basis, the feedback is logged when it is fresh and is limited to the specific expertise of the people giving feedback, and the work itself is included as delivered, not as it exists whittled down by a subsequent lack of capacity, ambition, etc.

Design is a field role, we are out in the real world speaking to people and figuring out how to make a mark - we are not meant to be heads down writing code, nor in meeting rooms debating with stakeholders - and yet these are the kinds of expectations designers are often being measured against.

Logbook-based performance assessment acknowledges this and allows us to design a performance review process which feel less arbitrary, less prone to the kinds of fallacies outlined above, and perhaps less anxiety inducing for all involved.

In an upcoming post I will share a template for this type of performance artefact, and I’ll welcome your feedback on it.

1. Infrastructure to create scalable high-quality user experiences, and 

2. The recasting of the role of design and designers in the organisation.

Today, I want to talk a little about that second part, because I think it is under-appreciated both by design practitioners, and by leaders who are commissioning this work and asking organisations to attribute value to it almost always on the basis of the first part.

I would posit that the large majority of the overall impact of Design Systems work is actually not about consistency, speed of delivery, quality of experience, or ease of “handover”, but it is in fact about unleashing the potential of design to operate across businesses as thought partners, as proposition designers, as facilitators of user-centric thinking and of technical partners with peer technical disciplines. That is what Design Systems done well do in design mature organisations, and we need to be more bullish in that assertion, and less unambitiously myopic in how we measure the success of these investments.

Stop measuring output, start measuring impact

A typical early-stage approach to measuring the return on design systems investments is to take superficial measurements of outputs and to use those to show that building infrastructure for design scales better than designing stuff over and over again. Teams will often build dashboards which look at the raw count of components live in a product, they might even go as far as to calculate the percentage of a product surface area which is built using componentry rather than adhoc code. This is useful as a measure of progress, but in reducing the value of these investments to such narrow aspects obscures the wider impact we are making in freeing up time for more generative design and research work. Whilst many organisations are always going to require some sort of output measure, we should also be bold enough to talk about impact of our work in the whole. 

So instead of saying “45% of the product page is now made up of design systems components”, we should say “45% of the product page is now built with design systems components, this has reduced our time-to-market by 20% and with the capacity we have gained in leveraging these components we have begun to tackle some of the work for next quarter to the point where we are now ready to start building new features 2 months earlier than would have been the case previously. This in turn has allowed us to conduct pre-launch research which has significantly reduced the risk of these features failing to meet both user and internal needs”. 

This speaks to what the business cares about, and not to the fears of the design organisation in keeping hold of the progress we have made to work in ways which scale and are sensible. 

Celebrate design work that happens without design

Design systems done (and crucially, documented) well create the possibility for good design work to happen without a designer ever having seen it. That is an uncomfortable position to put ourselves in, but we also have to acknowledge that there are almost no businesses where every feature and every product gets the attention it needs from a design perspective. HR tooling, finance tooling and partner tooling are all regular examples of where software is being built without dedicated design investment. If - in building high quality reusable architecture for design - we allow these teams to deliver better stuff, we should celebrate that and not shy away from it for fear that we have designed ourselves out of a job we were never going to do in the first place. This decentralised leveraging of design builds advocacy in places which may previously have felt resentful that they were not deemed important enough to deserve well made software.

Design Systems need not be simply a set of reusable parts

When we talk about Design Systems, we are generally talking about technical infrastructure, but our definition should be wider than this. If design systems are about the systemification of design, then we should avoid making design simply about the interface in the way we as an industry like to complain is done to us by every one else. What is the design system for workshop facilitation?  What is the design system for technical documentation? What is the design system for proposition design work? What is the design system for multi-disciplinary collaboration? This stuff is what we all know design to be - and so we should be thinking of how we formalise, scale and operationalise all of these things, not just the rounded rectangles which come out of the end of that lengthy process. 

The last decade has seen design become a much more mature and integrated part of how software gets made in evolved organisations. We should recognise that progress, stop being bashful about it and ask for it to be measured in ways which recognises that scale of change, and scale of ambition. 

Stuart.

Stuart.

For many people in design leadership positions, the idea of a concrete job description which accurately describes what they spend their days doing is novel enough to be laughable. Design leaders often come to this work through internal promotions which anoint leaders into hitherto only imagined roles whilst other times the role described when they were hired was written by someone who had never done the job themselves and had an at-best vague sense of what they needed someone “running design” to do.

So, we need a new job description. Let’s look at what it should cover. And perhaps there is an interesting exercise for us all to do off the back of this in writing down an accurate description of our actual jobs for probably the first time.

So… what is it you do exactly?

Every company is different, and so we’re not going to write the perfect job description here, but what we can do is consider both the job as it exists today, and the job you’d like your job to be if only you could stop doing all of the other stuff that keeps getting in the way.

Harking back to my “working in tech is an act of optimism” gambit, an optimistic summary of the role of a design leader might be something like this:

”The role of design leader is chiefly in creating and sustaining the conditions under which great design work happens. It is in developing and attracting world class talent which accelerates the progress we make versus that of our competitors. It is in partnering with colleagues from across the organisation to support and supplement their capabilities with strategic design partnerships. It is in developing and disseminating an understanding of user needs which is woven into the fabric of corporate decision-making and providing user-centric balance to business-centric metrics. The result of this work is brilliantly designed products which serve their users and their organisations equitably.”

That is a reasonable start. We’ve talked about the role as one which spans culture, strategy, organisational design, talent management and collaboration. That’s probably a pretty good encapsulation of what we’d describe this work as given ten seconds to do so. Moving beyond the summary, let’s talk a bit about the *how* of each of those categories, because it’s one thing to do that stuff, but quite another to do it well.

Culture

What does “good culture” look like for a design organisation? In some places, it is probably entirely about the efficient handover of artefacts, in others it might be about just not being an impediment to progress. In a design mature organisation, it is more than that, and you should take this opportunity to make explicit your aspirations for design to be more than that for your organisation, even if it feels a long way off.

A culture which creates great design work is one in which practitioners feel psychologically safe and in turn empowered to do ambitious work, it is one where they have the support of an emotionally literate manager and leadership staff. It is one where there is a consistent focus on the quality of the collective output, paired with a generosity of spirit which guides how feedback, critique and professional development are managed.

To be a designer is to care about the human experience, and so we should expect that design teams are made up of passionate, empathetic people who thrive in a culture which values - and is designed for - that kind of intense caring.

Strategy

Strategy is a view of the world we seek to create over the long-term, and whilst there are entire functions dedicated to doing just this, design leaders are critical cogs in the strategic machinery of a business. Your job description should include explicit mention of the role design plays in both informing and conceptualising what the strategic direction of the business needs to be.

Whilst other functions can talk about this in long strategy documents, we are uniquely positioned to be able to show what that direction looks like in a way which can engage everyone. Developing a long-term vision in partnership with the rest of the business is a fundamental part of the role of a design leader, and one which demonstrates the value of this role beyond the day-to-day operation; making design an asset the company leverages in both the short and long term.

Org. Design

Designing a design organisation is not like designing an engineering, product or data science organisation. The specific requirements placed on design, it’s relative scale and the nuances of the work itself create a need for ongoing work to design and iterate on a model for how design functions. You may have an established view of the specific flavour of org. design which works best for your business but the important part is that this is recognised as a part of the role which doesn’t go away.

Design teams scaling beyond 1, 10, 50 and 250 people require completely different architectures and infrastructures, and it behoves you to be thinking about this as an iterative, evolutive process as opposed to one which requires massive organisation change on a semi-regular basis. Org. change done well happens slowly enough that no one notices and quickly enough that no one felt the pain of delay.

Talent Management

If you’ve built an org. that functions well with a culture that creates the conditions for great design work and have been able to create room for design to inform strategy, the individuals in your team will have the breadth and depth of opportunity required to make meaningful professional progress.

However, it is a rare designer who doesn’t also need support in acquiring and honing new skills, or who doesn’t come up against blockers to progress at some point in their career. Managing talent well requires explicit goals at the individual level, and systems through which those goals can be achieved - be those on-the-job opportunities, or formal learning programmes.

It is not enough to adopt a sink or swim attitude to talent, and whilst hiring can augment even the shoddiest of internal talent development programmes, it too is not trivial when done well and is only ever a short-term fix because the people you hire will have their own knowledge gaps and stretch goals to achieve too.

Collaboration

The image of design as a solitary act done behind closed doors by precocious geniuses is alluring for a certain type of designer, and we’d all quite like a bit of peace and quiet on occasion to do some real work, but great design almost always happens in the open as a collaborative process across disciplines and departments. As a leader, you set the tone for this as the representative for design at the highest level, and the behaviours you model in your collaboration with fellow leaders will cascade down and be mirrored through the organisation. You must therefore find ways to work across silos and departments for the greater good of the business, create ways for your team to do likewise, and for the fruit of the joint labour to be recognised as a direct result of designs ability to unite people behind a shared vision.

If you can figure out how to write a job description which succinctly and simply expresses those things, you will be well on the way to describing what good design leadership looks like, and creating a document which you can point to when you are next asked “what it is you do, exactly”, it may also help your manager to understand your role better, and to be more useful in supporting you to do it.

It might even accelerate the process of finding your replacement when you decide you’ve finally had enough and are moving to Peru.

Stuart.

There comes an inevitable moment in the growth of an organisation where someone sensibly suggests formalising titles, levels and criteria for progression. Once that cat is out of the bag, there is no putting it back in until you have written a raft of documentation, rocked several apple carts, and eventually deployed a set of organisational changes and a new way for everyone to think about their job, development areas, and place within the wider business.

The good news is that design teams rarely reach this moment of need first. In large tech orgs. engineering is typically first to scale to the point where this need becomes acute.

This is good news and bad.

The Bad News

Engineering are going to be off writing their L&E framework, likely lifted from whichever FAANG company the CTO worked at previously. In doing so, they will be creating a format and a structure which you are going to be locked into. HR teams and leadership do not relish having to learn and switch between different versions of these same artefacts in cross-disciplinary forums, even if they are serving wildly different populations within the company. So, hope your pals in engineering accidentally make decisions that serve the wider organisation, or better still, work with them on their L&E framework knowing that you will be inheriting a bunch of their work in writing your own.

Because Engineering is a completely different role which draws in completely different kinds of people and is asked to do completely different things to designers, there will limited utility in the actual content of the engineering framework, but there will be some…

The Good News

Whilst design and engineering are rarely on a level playing field, this is one opportunity to narrow that gap. If you can cast aside your understandable concerns about the framework you are inheriting, you will be able to:

1. Create parity across the career ladder - If there is a Vice President role in the engineering framework, there is now one in the design framework too, and whilst it may sit vacant for some time as the organisation matures, its very presence is a helpful nod to that ambition. Throughout the ladder you can create comparable roles across disciplines, and create shared expectations beyond the production aspects of the work.

2. Just replace the verbs - It may be that you can almost completely replicate the engineering rubric, replacing only those aspects of it which refer to specifics of the role. This will help to elevate the role of design as the “soft skills” which form the other half of the framework are very often areas in which designers excel beyond the typical performance levels of their peers in Engineering.

3. Codifying expectations reduces bias - Organisations which use observation-driven performance management processes are prone to being tainted by a bunch of biases which a well written set of expectations can help to reduce. A framework which can describe both output and behavioural expectations makes it more difficult for outlying feedback to overwhelm that at the centre, and can mean that groups who are less representative of the overall company - and wider industry - benefit disproportionately from a framework, even if it was derived from that written for the dominant group.

Done well, a career development framework becomes a useful tool for individuals, managers and the organisation at large. Whilst it can be a significant effort to create, the earlier in your companies scaling you do so, the easier it will be to maintain, evolve and adapt as time goes by. Some things to try and avoid as you put pen to paper:

1. Create as few levels as possible - (notwithstanding the point above on duplicating the engineering levels) It is nigh on impossible to remove levels later, so resist the temptation to create a 9 level ladder from day one. Instead, look at the team you have, and consider where it is headed over the next 18-24 months in terms of career development and likely hiring. If you’re not going to be hiring at or promoting to Senior Staff levels in that window, don’t create that level.

2. Make sure you aren’t myopically focussed on outputs - This is an opportunity to enshrine elements of *how* people should work into the fabric of their role. If it’s important to you that people aren’t arseholes, then make sure you codify what good communication and collaboration skills look like, and how those expectations rise through the levels, not decline.

3. Don’t make changes mid-cycle - Once you’ve rolled this document out, you need to let it go largely unchanged during performance cycles. It is manifestly unfair to change expectations in the middle of a period where performance is being measured. Non-trivial changes should be bundled, and enacted with prior warning at the end of an annual cycle. This is the minimum timeframe over which an organisation can digest these types of changes.

Stuart.

Subscribe now

Levels & Expectations frameworks resources:

• Progression.fyi - Software to define and measure career growth for your team

  • Quick Start: Product Design Team

  • Example Framework: Small Product Design Team

  • Example Framework: Large Product Design Team

• Figma - How our design team level set on career leveling

• Buzzfeed - Product Design Roles

Share Design Leadership Memos

Working in technology is an act of optimism, we sit at the forefront of progress in all sorts of areas of human advancement. Our job is to take the raw ingredients of new and unrefined technical capabilities and turn them into things which improve the lot of our fellow man, and yep, generate shareholder value along the way. At it’s best, this industry gives us a front row seat to the rapid advancement of society, and at worst it throws you and everyone else into a tumble-dryer which you can only hope finishes it’s cycle with your innards still in the right places.

Design Leadership is an essential ingredient in creating from this exciting maelstrom a place in which designers can do their best design work - where lucrative careers can be created for all sorts of people, and where in offices and slack channels largely made up of business types, teams of people who get excited about great design work get to get excited about getting to do great design work which enriches their professional lives whilst making the world a marginally better place.

I hope that this newsletter will provide the raw ingredients for you to create your own framework for design leadership, that it will be a comfort to those us you who are deep into your leadership journeys and for aspiring design leaders who are looking around and finding scant information on how to do this work, and to do it well. Whilst it is largely my own personal experience and a career positively littered with mistakes which have inspired the writing of this newsletter, it’s contents will also drawn from the experiences of my peers and colleagues, from brilliant conference talks, from prior art in this same category, and from rants over drinks in generally dingy bars spread across several countries and multiple decades.

Stuart.