Meaningful Roles Can Be Consciously Designed

I don't know about you, but doing meaningful work has always been the most important part of my career. More important than salary, even. I'm not saying every job we have needs to change the world (although that would be nice). What I mean is that we need to know why we're doing what we're doing, and why it’s important to us and to the people around us.

And it turns out meaningful work isn't just some nice-to-have for the philosophical few. A 2019 meta-analysis of 44 studies, covering more than 23,000 people, found that meaningful work strongly correlates with engagement, commitment and job satisfaction, and is also linked to life satisfaction, general health and lower intentions to leave. (It's correlational, so it doesn't prove that meaning causes all of this. But the pattern is hard to ignore.) So the value here is not just personal. It lands directly on the organisations people work for.

Of course, not every job can be equally meaningful. But the way I see it, the content and structure of the work do most of the heavy lifting, for better or worse. Which means it shouldn’t be up to the person to find meaning in their work (some roles give them very little to work with!). We can design roles that offer as much meaning as realistically possible, so people don’t have to find it. They just feel it.

Here's how I'd go about it, in five steps.

First, a quick distinction: jobs vs roles

"Job" and "role" are frequently used interchangeably, but they aren't quite the same. We can view a job as a formal set of tasks assigned to a particular position, while a role is what emerges and gets negotiated with the people around it over time.

People's real experience of work is shaped by more than the tasks on paper. It's also shaped by the tasks they lean towards, the relationships they build, and even how they think about what they do. So when we design roles, we're designing them in two layers:

• The formal edges. Things like outcomes, decisions and responsibilities.

• Room for growth. A space where the person can shape the role in a healthy direction.

Step 1: Understand the system first

There are two common things I've noticed organisations do when they think they're ready to hire:

1. They create a new role from a to-do list that never gets ticked off, made by people who are drowning in work. They stick a credible-sounding job title on it and use that list to create a job advert.

2. They reuse last year's job advert that worked, update a couple of things that noticeably changed, and use that to find a new person to fill it.

I'd argue that neither is the best approach, because:

• A long to-do list is not necessarily a role. Take a load of tasks that no one properly owns, put them together, and you can easily end up with a strange bundle of unrelated activities. Something without a coherent purpose, that probably isn't a role anyone can do particularly well.

• An old job description tells you what the organisation needed before. If an organisation is growing and learning, it has probably changed: its strategy, technology, team, problems and, most importantly, the work itself. So why assume the same role is what you need now?

• Hiring is actually an organisational design intervention. Bringing someone new in changes decision-making, communication flows, where expertise sits and what the organisation is capable of doing. If you don't look at the overall system, you can end up hiring someone to absorb the mess created by a lack of clarity, which can just make everything even messier.

(If you're not sure whether you need to hire yet, but feel overwhelmed and think you probably should, this might help: How to Know if You're Actually Ready to Hire (Not Just Overwhelmed).

So when it comes to hiring, I think we need to start with purpose, not tasks. Why does this role need to exist, and what organisational need is it responsible for? Then ask what outcomes the new person should create, and only after that, which tasks the role might involve.

One of the core ideas in systems thinking is that the way a system is structured is a big part of why it behaves the way it does. So if the same problem keeps coming back, that says more about the structure creating it than about the people involved. Which means a new role might not even be the answer. The answer might be fixing a process, an ownership gap or a decision bottleneck instead.

It also helps to remember that a role isn’t a document. It’s the set of expectations other people have about what whoever sits in that seat should do. Everyone around the role (managers, peers, customers, anyone whose work depends on it) has expectations of the person in it. They communicate them, clearly or not, and then react to how the person responds. Over time, that back-and-forth becomes the role. That’s why two people with an identical job description can end up in completely different roles.

And because those expectations sit with the people around the role, it makes sense to design it with them, not for them. They know the handoffs, and the problems that keep coming back, far better than whoever writes the job description. While you’re talking to them, check three things that are easy to forget:

• What happens to the roles around it. A new role takes work away from someone, and sometimes it can be the part of their job that they were proudest of. Ask each affected person what they’ll gain and what they’ll lose. Don’t let them find out after the new person starts.

• Whether the manager actually has time. A well-designed role can still fail if the person managing it has no time to manage it. This is really common in founder-led companies. Work out how many hours a week managing the role well will take, especially in the first 90 days, and where exactly those hours will come from. If they don’t come from anywhere specific, they won’t happen. So decide what the manager will stop doing to make room. If there’s no formal manager, this applies to whoever the new person will go to day to day (in small companies, that’s often the founder).

• How the handover will work. Until the new hire is up to speed, the work still has to happen. Without clear handover dates, the people currently doing it tend to keep doing it because it’s quicker, and the new person never fully owns the role.

Step 2: Define the role from outcomes

Write one sentence on why the role exists, then three to five outcomes it's accountable for. If you're stuck, ask: "If this person had a great first year here, what would be different?"

Then decide how you'll know each outcome is being delivered, and here's another step I think is really worth including: check what each measure could accidentally reward. When a measure becomes a target, people start chasing the number instead of the outcome (that's Goodhart's law). Measure only response times and you might get fast but unhelpful replies. Measure only renewal rate and you might get discounts handed out to keep customers at any price. So pair every measure with a counterbalance: response time sits alongside repeat contacts, renewal rate alongside discounts given.

Then check the load. You can’t put hours on an outcome, but you can on the tasks that deliver it. List the tasks, estimate the monthly hours for each, add meetings, admin and learning, and compare the total with the contracted hours. As a rule of thumb, if it comes to more than about 80%, the role is overloaded before anyone has even started! The remaining 20% is your buffer for everything you can’t plan, such as interruptions, urgent requests, or covering for someone off sick. So cut the scope, or decide now what gets dropped when it’s busy. And view any task that doesn’t serve one of your outcomes as a clue: either an outcome is missing, or that task belongs to someone else.

Now you’re ready to draw the formal edges. The ones that I think matter most:

• Decision rights: what they decide alone, what needs consultation, and what needs approval (and from whom).

• What they own, and what they don’t: without the second list, every new request will land on them by default, so don’t skip it.

• One priority owner: who has the final say when the role holder’s priorities clash? If you’re a founder and still the person deciding what gets done first on Monday morning, that’s your design problem.

• Success measures: what good looks like at 90 days, 6 months, and a year.

• Cover: who does the work when they’re on holiday or off sick. In a small company, it’s usually whoever did it before, or nobody, which brings back the exact problem the role was created to solve. So decide which parts need cover, who covers them, and which parts can safely pause (and for how long). And if the same person ends up covering everything, check that they actually have the capacity.

• Room to stretch: in my experience, people take more initiative when they have real autonomy and see their role as broader than a narrow job description. So in addition to a clear core, decide where they could stretch beyond it, should they wish to.

And the rest are still worth deciding BEFORE you hire, too:

• Dependencies: what the role needs from others, and what others can reasonably expect from it.

• Key relationships: who they’ll work with regularly, and how.

• Capabilities: what’s a must-have on day one, and what can be learnt on the job. These feed straight into your hiring process and your 30/60/90 plan.

• Essential requirements: anything they must have to do the role (it’s fine to leave this empty; more on this in Step 4).

• Resources and constraints: the budget, people, information, tools and systems they’ll have access to.

• Work design: which ways of working they can design themselves, and which they’ll inherit.

• Feedback: how often they’ll get it, and from whom (this one matters more than it looks; I will explain why later).

• Priorities: which tasks come first, and which can be dropped in the weeks when everything can’t get done.

• Who benefits: the people and communities who gain when this role is done well.

• Flexibility: which parts are tied to a time or place, and which can flex.

Why bother? Because unclear edges create role ambiguity (not knowing what’s expected or how you’ll be judged), role conflict (expectations that can’t all be met at once) and role overload (more than anyone can reasonably do). A large review of 96 studies (Jackson & Schuler, 1985) found that both role ambiguity and role conflict go hand in hand with lower job satisfaction and commitment, more tension and anxiety, and a stronger wish to leave. The way we can think about it: ambiguity tends to cost you output; conflict tends to cost you people. And neither is automatically a problem with the person. Both usually come from how the role was designed, which makes them fixable.

What I find interesting is that people in unclear roles often feel something's off without knowing what's causing it. A few patterns to look out for:

• Unclear ownership. “I thought you were doing that.” “It fell through the cracks.” If you keep hearing it about the same kinds of work, that’s your sign.

• The role built from a person. It was written around what the last person happened to do, or from the list of things a founder was tired of doing. The new hire inherits leftovers, not outcomes.

• Too many bosses. A new ops hire takes requests from whoever’s been there longest, nobody owns their priorities, and they’re left choosing whom to disappoint.

• Accountable without authority. They’re responsible for an outcome but can’t make the decisions that drive it, so they escalate everything and end up looking indecisive.

• Unowned coordination work. The chasing, follow-ups and handoff fixing that everyone needs and nobody owns. It tends to land on the most conscientious people, who end up overloaded and under-credited.

Then there is the generalist problem

In small companies, it’s normal for one person to wear several hats: ops, finance and HR in one person; marketing, community and partnerships in another. That’s often sensible, and plenty of people love owning several areas instead of being boxed into one. But a few things can go wrong:

• The hats start fighting each other. Each one comes with its own expectations, and they don’t coordinate. Your finance deadline doesn’t care that your people role has a difficult conversation booked for the same afternoon.

• Switching has a cost. When we switch between tasks, part of our attention stays stuck on the last one (researcher Sophie Leroy calls it “attention residue”), and our performance on the next task can suffer.

• Variety stops helping. Variety can be great for learning, but in my experience, as commitments pile up, the switching and coordination start to cost more than the variety gives back.

So here’s how we can make multi-hat roles easier to sustain (practical principles, not research findings):

1. Bundle around a shared purpose, not leftovers. “Everything that helps our people do their best work” beats “everything the founder doesn’t want to do”.

2. Watch the type of work. Deep focused work mixed with a constant reactive queue is one of the hardest combinations. Structure the week so both get room.

3. Keep the skills close together. Unrelated skills can leave someone feeling permanently junior at everything.

4. Don’t bundle roles meant to check each other. Whoever approves payments shouldn’t be the only one reconciling the accounts.

5. Watch for emotional tug-of-war. Being someone’s go-to for support and the enforcer of their performance is hard on everyone.

If you’re designing a “generalist role”, define each hat separately, with its own outcomes, decision rights and boundaries, and agree a rough time split so everyone knows what “enough” looks like for each one.

Step 3: Design the experience

Now, just because we define a role well, it doesn’t automatically mean that it will motivate anyone, or that it will feel meaningful. There are a few bodies of research I want to use to address this.

Hackman and Oldham's Job Characteristics Model says meaning comes from skill variety, seeing a piece of work through from start to finish, and knowing that it matters. Add autonomy and feedback and you get real internal motivation. In their formula for a job’s motivating potential, they also gave autonomy and feedback extra weight, by the way, so a very low score on either one drags the whole score down.

Then Deci and Ryan's Self-Determination Theory adds the person's side. People move from doing work for rewards (e.g., money) towards doing it because it matters to them when three needs are met: autonomy, competence, and relatedness. And they can't be traded off against each other. Loads of autonomy with no connection to anyone still ends in disengagement.

The spectrum runs roughly like this:

• External: "I'll do it if I'm paid." Disappears when the reward does.

• Introjected: "I should do this, I'll feel bad if I don't." Gets things done, with anxiety and resentment attached.

• Identified: "This matters to me, even when it's hard." Much more stable.

• Integrated: "This is part of who I am."

• Intrinsic: "I'd do this anyway." The most self-driven kind, and the hardest to create on purpose.

The goal isn't to make everyone love every task. It's to help people move up the spectrum, towards work that feels chosen and connected to something they value.

Then, to check a role before anyone's hired into it, I like Parker and Knight's SMART model of work design (2024). Ask whether the role is:

• Stimulating: enough variety, complexity, and challenge to stay engaged. Note that more isn't always better, because adding random, unrelated tasks just fragments the work. Aim to enrich it, not just enlarge it.

• Mastery-building: give room to grow, with support and feedback. Work far below someone's ability bores them; work far above it with no help makes them freeze. And feedback should come from the work itself. A salesperson with live pipeline data automatically gets feedback that they can act on, whereas an analyst whose reports vanish into a system never hears a thing. For roles like that, it helps if feedback is designed in some other way.

• Autonomous: freedom over when the work happens, how it's done, and what gets decided. Some roles might have one of these without the others. Aim to give them all three, where possible.

• Relational: seeing how your work affects real people. Back-office roles especially need this designed in, even if it's just a customer story at a team meeting or a thank-you passed on directly.

• Tolerable: demands should be balanced by resources. Tolerable basically means that for every big demand you design in (workload, time pressure, hard conversations), there's support, autonomy or development to balance it. Check the workload realistically, not optimistically.

BTW, here’s something to watch out for: you can design autonomy into a role and then accidentally take it away through how you manage the person! One of SDT’s most practical points is that autonomy-supportive management tends to bring better motivation, satisfaction and wellbeing than controlling management.

Here’s how they differ:

Autonomy-supportive management

• Sets the outcome, leaves the method to the person

• Checks in to offer support

• Explains the why behind decisions

• Treats questions as engagement

Controlling management

• Sets the method as well as the outcome

• Checks in to make sure people comply

• Gives directions without reasons

• Treats questions as pushback

Aaaand, if people have already been asking you for permission for every tiny decision for a while now, then autonomy is likely missing somewhere. And talented, driven people either leave for places where they'll own more, or stay but are disengaged.

Step 4: Check it's fair

Before finalising the role design, look at the role through Scotland's Fair Work Framework and the B Corp standards on fair work and inclusion. At a minimum, ask yourself whether the role you just designed is fair, sustainable, accessible and inclusive. And whether the person will have opportunities, a voice, respect and safety.

My favourite practical move here is separating the essential from the habitual. Things like specific degrees, a set number of years’ experience, or being full-time in the office are often habits that I think should go now (and, to be fair, I’m seeing them in job ads less and less). If something isn’t essential to achieving the outcomes you’ve set, don’t ask for it. I also feel very strongly about designing specifically around outcomes rather than hours, so that far more people can do the role.

A few more ways to design a role more people can do:

• Decide the flexibility up front. Say which parts are tied to a time or place (customer hours, a weekly meeting) and which can happen whenever. Note this in the job ad so people know beforehand.

• Treat job shares as a real option. If two people could deliver the outcomes, don't limit it to one full-time post.

• Make adjustments normal. Once you’ve hired someone, ask them what helps them work well, both during onboarding and in regular check-ins. Do it with everyone, so it’s a standard part of how you work, not something that only comes up when a person asks for something in particular.

Finally, be honest about what the role really offers. Before you write the job advert, list what you can really promise a candidate, and which part of the design delivers it ("you'll own renewals end to end", because that's in the outcomes and decision rights). Then list what you should not promise yet, like a team to manage when there's no budget for one. Share this honestly with candidates upfront, because a new hire will hold you to everything you say. The gap between what’s promised and what’s actually delivered is exactly where trust (and, alas, engagement) starts to go. :)

Step 5: Test it, then keep it evolving

No design is ever finished. The easiest place to start testing is the first 90 days. Add a few questions to your check-ins:

• Around day 30: Is it clear what the role owns and doesn’t own? Who’s asking them for things we didn’t expect?

• Around day 60: Is the workload what we planned? Which parts of the work give them energy, and which drain it? Can they see the impact of what they do?

• Around day 90: Are the outcomes still the right ones? What would they change about the role if they could?

Treat the answers as direct feedback that you can use to evolve the role into something that works better. Then revisit the role every six to twelve months. Roles drift as companies grow and priorities change, and a role that fitted perfectly at the time of hiring might no longer work once the company has doubled in size.

Want the full version?

I did actually write 5K+ words about this topic, but shortened the whole piece for the essay, as I figured no one would read it at that length. But if you want to learn more, you can grab the extended version alongside the Role Design*, Role Definition and Role Brief templates, a Fairness and Inclusion Checklist, and ready-made AI prompts here.

*The Role Design Template includes all 5 steps in 10 stages, from confirming your starting point to sign-off, including the complete list of formal edges, the workload and counterbalance tables, cover and transition planning, the team and manager stress-test, capabilities and essential requirements, and the full fairness and inclusion review. The Role Definition and Role Brief templates come with AI prompts that transfer your answers across for you.

(A quick note: this is about role design, not legal or HR compliance advice. Check anything you build against employment law and your own policies, with qualified HR or legal professionals where needed.)

Thanks for reading!

Lina