As designers our aim is to make sure we meet user needs by utilising strong user-centred design.

As multidisciplinary product teams we all have a responsibility in making sure we deliver consistent user-centred design by ensuring we iterate, question our hypotheses and have these made a priority in backlogs.

It’s important to understand the life cycle. An idea becomes released into a service or product at some stage. These ideas grow into patterns. Like any other aspect of design they are subject to change and improvement.

It is important to iterate. We should look at maintenance and improvement through design research.

What is Design Debt?

Forward thinking organisations will encourage their teams to identify and reuse standard components and patterns. This is a no-brainer for organisations who understand the need to save resources and avoid reinventing the wheel. By doing so we can focus our effort on the trickier aspects of a service or product that make it unique.

“Design Debt” are the deprecated design components, styles and patterns in the services, journeys and experiences of our users.

It’s what happens when we fail to iterate our designs based on new data, feedback or research or when we don’t keep design patterns up to date with parts of a design system which we may be using. It also happens when organisations become purely focused on feature releases without prioritising design maintenance as part of their backlog.

We often know that design debt will happen, we’re aware of it but dealing with it is different entirely.

In a large organisation that follows a design system, design debt can still accrue. In fact, design debt can rapidly increase when there are multiple teams working to different demands and it takes a level of resilience and self-motivation to keep on top of it. Teams may work faster than the design system can bring in new patterns or components. These patterns may not make their way up the design system.

For instance, multiple teams in a given area may be working at a different pace and inevitably may have breakdowns in communication.

The realisation of design debt

When the realisation hits that you’ve accrued design debt it can be quite daunting to deal with, not unlike dealing with financial debt. Let’s take a look at the compounding effects of design debt to you, your team and your organisation.

Is the design really consistent?

Stakeholders start to notice small inconsistencies with design across the organisation. Maybe different teams have presented to the same stakeholder within days of each other and the stakeholder notices differences in the design.

Design system alignment

Cracks start to show between approved patterns and components in the design system and design which has been approved for release to users. A single source of truth is no more.

Design governance

You may have some level of design governance in your organisation, but when design debt increases how do the governance models work? How is it known which design pattern or component is the correct one. Which one is assured? Has a governance team approved the wrong one for use without realising?

Design debt in to tech debt

As design debt mounts, there will be a point when it’s surfaced and taken into a backlog for a development team to update. Design Debt transfers at that point into technical debt which increases the overall debt amount quite considerably. In some cases updating something which is in a design system may need to be corrected in five different places in a live build.

These are just a few compounding problems which can occur from a design debt build up. There will be more and you’ve probably felt them at some point through your career.

Surfacing debt

Accepting design debt is the right thing to do.

Most importantly, surfacing the design debt is where you’ll find incredible value. It gives you a place to start. This is where you will be able to understand and quantify what you’re working with and begin a plan to work through and reduce it.

Below we’ll give a few examples of how to start as a design team and bring along our product and delivery colleagues to support us on the journey.

Acceptance

As we said above, start by accepting it’s there. Design debt will not go away by itself. If anything, once it starts it will only increase and cause more compounding effects like we’ve described above.

Inventory

By creating an inventory of design in your given area, you’ll be able to visualise the design components and patterns as well as being able to quantify what you’re working with. Surfacing these details puts you in a much better position going forwards to start working through your design debt. Below is a list of things to include in your inventory. As a starter you should surface;

• Service / Product / Tool
• Name of element
• Name of screen using component / pattern
• Component / pattern location on screen
• Component / pattern location in other service / product / tool — this is important to find the design consistency across different services / products or tools

Once you’ve surfaced the data you can then begin to add extra detail to enable you to measure your inventory;

• Confidence level rating (should be vs needs to be done)
• Risk of doing / not doing
• Opportunity of doing / not doing
• Proposed fix, fixes or iteration
• Time to design / research fix or iteration
• Team availability and activity required
• Any alternate hypotheses

Measuring the inventory will help to communicate with product and delivery managers in your organisation.

Documentation

There are various ways you can document the above information;

• Spreadsheet
• Trello board
• Miro board
• Github repo
• Print it out on a wall (not so easy during lockdown)

All of these will help visualise and describe the level of detail you need to extrapolate in order for it to be valuable.

Working big scale

As we’ve mentioned, working towards building an inventory in a large organisation is a challenge.

If you think of an example like having six or more large areas of an organisation, each with their own design team, their own priorities and motivations working with a design system which may not have everything they need you can begin to understand the scale of what you might come across.

Here’s a simple plan to get going;

• Treat the inventories like a broad project covering your organisation
• Identify your stakeholders
• Communicate the plan and the problem you’re trying to solve across your organisation
• Begin your inventories in your own area of your organisation
• Document the inventories as described above
• Bring these inventories together into a central working group
• Identify those patterns or components which should be used against those which shouldn’t
• In your area work with a product manager to prioritise the work required in a backlog
• Have your design system team take the ‘true’ pattern or component into the design system backlog
• Work with as much validated research and data as you can

Without a doubt you’ll find both consistency and inconsistency.

The scale of the work required might be large and it may take time to complete.

The important thing is to start.

Communicating with your product management colleagues

It often feels difficult to get project leads and stakeholders to understand the importance of dealing with design debt.

Their jobs are full of conflicting priorities and motivations and they are usually under pressure to deliver new features.

Think about it from their point of view. If it isn’t broken why fix it?

Delivery managers and product managers don’t often see design debt. In the same way they don’t see technical debt. This is not a fault. These concepts are highly specialised and require a trained eye to spot them.

If they cannot recognise design debt in their own service or product, how can they be expected to understand the impact it may have on other services or products without our help?

As experts in design we need to reinforce a constant message throughout a product’s lifecycle. That any design, including standard components, is our best understanding at any given time. Design should evolve as we learn more, either from our own team, the wider community or ultimately from our users.

It is our responsibility to highlight design debt as it’s spotted. For example, when adding tickets to your backlog include the reasons why it’s an issue. Why it’s going to cause problems in the future and the benefits of putting in the effort to deal with it now.

Will it save wasted effort in the future? Will it benefit other services? Most importantly, how will it impact users? What improvements will it bring them? Use this language when discussing design debt. Frame it as an opportunity, not a complaint. You may find your team start to use the same terminology.

Senior product leaders should create a culture where our delivery colleagues are encouraged to think about the impact their service has on the wider digital community. A culture that aims to deliver something great today, but also helps to deliver many great things tomorrow.

Product owners and managers should be recognised for releasing something back to the community that has an impact on their organisation beyond their own service.

It’s about open communication with our colleagues. Helping them to recognise that this is never just change for changes sake. Consistency is only part of it. More importantly, we all want the products and services we design to be the best they can be for our users. Each team must do its part by dedicating some resource to reducing its design debt over time.

How to stay on top

Once you have the process above ironed out, you will hopefully have the majority of the design debt cleared and you’ll have inconsistencies made consistent and documented in your design system. It’s good to iterate and revisit the process we’ve described over time, the scale will be smaller and you’ll be much more able to build design debt into your backlogs.

This article was co-authored with Jon Greer.

Thanks to Richard Young for his words which were included in the article.

The post Design Debt first appeared on Gavin Elliott.

Over the years, I’ve focused on building teams, setting standards, and increasing maturity. After many years of leadership, my eyes have scanned all the ways of working at an organisational level.

The industry accelerated its maturity 10x over the last five years; however, there are still two things I see pretty often. 

1. Some companies and organisations still need to catch up in maturity at a higher level, which can hinder the learning and growth of those working within them.
2. Those who matured the fastest have become disconnected from their best years and become stuck in their ways, limited by broken ways of working, processes, and bureaucracy. They need to remember what they can do to be great. 

I want to discuss two things organisations did well yet have either stopped or been forgotten over time.

Technical insight/feasibility and prototyping at speed as early as possible in your project’s ‘understand’ or ‘discovery’ phase. 

User Research and understanding the problem you’re trying to solve are essential and should be part of this phase. However, looking under the rug to see what’s there from a technical point of view and prototyping as soon as possible are equally important, primarily as teams have touched more surface areas.

When we only focus on the user needs at this stage, we often miss the possibility of a trapdoor the size of the Atlantic beneath our feet. All user needs might be null and void if the technical feasibility isn’t there. If we understand both, we’re in a much better position to avoid getting caught out later. 

In addition to this, I’ve seen prototyping happen later and later in the discovery or understanding phases. 

Prototyping enables us to learn something, anything, even if it’s terrible news. You can not understand that from ‘shiny’ UI or being devoid of putting anything in front of users to see if it will meet their needs. A prototype doesn’t have to be all singing and all dancing. It needs to be ‘just enough’, and ‘just enough’ can be done quickly and earlier than you’d think. The excellent time for this was 6-8 years ago, and since then, I’ve seen ways of working conform to something else: a non-agile, non-nimble, non-quick-learning process. 

It takes maturity as a team and organisation to balance understanding, innovation, and technical feasibility. We used to do this. We used to treat it as fun, learning quickly and failing fast if need be. It takes a high degree of communication between a team and the ability to leave ego and bias elsewhere. 

By understanding technical feasibility and prototyping earlier, it’s far easier to communicate with stakeholders and make them aware of what the playing field looks like. It mitigates the question of “Can we even do this?” and “It’s going to take six months of work and £XXX, XXX”. Whether there’s trouble ahead that you need their help to unblock or whether not to invest time, money and effort. It makes setting expectations easier as things progress. 

Something I’ve talked about a lot over the last few months is ‘impact’, ‘impact towards outcomes’, and ‘speed of impact towards outcomes’ by people, teams, and organisations. Positive impact happens in many ways. Focus on positive outcomes; when your organisation does that quickly, it’s a win-win situation for everyone. 

The two things I’ve described will get you there. 

Remember, any process is a floor and not a ceiling. Any process can be challenged and changed. 

Focus your process on the speed of impact on outcomes.

The post Tech Insight and Rapid Prototyping: The Neglected Game Changers first appeared on Gavin Elliott.

Good leadership would state that you should share that information so that you get collective buy-in.

The where enables your team or teams to know what the ultimate goal is and what achievement they’re aiming for.

The why, if done right, gives them something to hold on to. The belief, the reasoning, the thoughtfulness. It’s the thing that brings people together. It’s the emotional connection. It’s the thing that makes them get out of bed in the morning.

If you put all of your own internal language to one-side and any bias that may carry, let me use a military analogy to share my view on where I think folks can do a better job to cover off a few pieces like empowerment, leader-leader, story-telling and goals and why some** structure mixed with independence and autonomy – can have massive positive effects on teams.

Imagine if “Insert company slogan here” is your ultimate goal as a company. It never shifts. It’s the mountain you’re told to take, and if you do, your company and your customers will see success, but success takes time. It’s a journey.

In order to take the mountain, you have to take the villages, towns, cities and hills around it. These are your objectives towards your ultimate goal.

The bad way

Tell folks to “take that village” and they look at each other like you’ve gone mad, however, because they’ve been told, they run off towards it whilst with no plan, no reasoning and no resources. They hit blocker after blocker and failure after failure but continue on to impending doom because they’re solely fixed on the order they’ve been given.

The good way

The commanders from air, land and sea have stood around a map; they’ve identified that in order to “take that village”, there needs to be a coordinated set of actions:

• Recce to know what they’re up against
• Identify routes in
• Identify potential points of contact – enemy
• Identify how many enemies
• Create a fallback plan should shit hit the fan

The commanders can communicate the reason ‘why‘ the village is important so the fighting force knows what and why they’re fighting for. This involves a level of story-telling which is clear, consistent with fine-tuned clarity. Done well; the folks on the ground understand it the first time, every time.

This information then gets passed down to lesser-ranked commanders until it’s gone all the way to the fighting force on the ground so they can act upon their orders.

Each member of the force is empowered to speak up, share opinions and give guidance on their own skill set/position in the team in order to maximise the safety of those around them and get to their goal. Because they’re empowered they take ownership of their responsibilities – this is the leader-leader model.

Folks follow great leaders because they can do all of the above.

If you’re a leader, you need to do the same.

You need to let them know what the ‘hill’ is and why they need to fight for it.

You need to prioritise the roads, villages, towns, and cities that need to be taken in order to get to the hill.

You need to frame why those need to be taken (aka, What’s the problem we’re trying to solve? And who’s going to do the taking?

If we have Commanders, then with enough information they can work together with others from each of the ‘arms’, aka Product Management, Design and Engineering to get the job done in the right way. We should know who is capable of what and where gaps need to be filled.

Great leaders are enablers in every sense of the word.

Leaders need to nail all of this to get everyone aligned and have them know where we’re headed and why.

It’s your time to story-tell the above in a non-military sense.

What are the hills we need to take, why do we need to take them, in what order does it need to be achieved and which parts of your teams are going to do each bit?

One step further, how are you going to support them to accomplish their mission?

** There is often an opinion that structure can cause a reduction in speed or momentum. However, it’s a balance. You need just enough structure for something to work better and faster.

The post Leadership and Strategy first appeared on Gavin Elliott.

At the very heart of our work in UX Design, we want to enable users, meet their needs and make experiences better for everyone.

When we meet their needs they should feel invincible.

Here are a few words that describe a similar thing:

• Experiences
• Journeys
• Workflows

These can be singular or plural.

They can be great or they can be small.

Either way, they must never be broken, never frayed and always seamless.

The nature reserve

Let’s talk about the nature reserve analogy I mentioned earlier.

Below you’ll see a large nature reserve. It opened in 2021, was well designed and functioned well.

It met all of the recognised needs of its visitors:

• It was accessible
• It was safe
• It was beautiful
• It was the right length
• It had amenities
• It was clean

The first extension

In the summer of 2022 the nature reserve was extended. The design and build was done by a different provider to the original reserve.

Over time visitors had asked for ‘more’ out of the reserve. They wanted extra parts for activities like a climbing wall, a few more routes and some land for camping overnight but all with the same needs as the original part of the reserve. A small yet functional addition was made.

A short while after it was opened feedback started to come in.

Overall visitors loved that they had the additional space and climbing wall.

However, they displayed confusion as to why certain connections between the pieces of land hadn’t been provided. The camping ground was north of the new piece of land, close to the bend in the river but there was no way to get to the main amenities other than going the “long way round” walking south and west. No bridge was provided.

The climbing wall was a big pull for visitors, however, when they got there you weren’t allowed to climb unless you’d signed a waiver at the main visitor center in the west part of the reserve but there was no notice of this as you walk into the reserve from the car park to the far west so you had to double back on yourself before even getting to climb.

There were also a couple of near misses with visitors wandering in the wrong direction and meeting other inhabitants of the reserve.

The second extension

After a consultation in the early part of 2023 another application was made to extend the reserve farther north to add in more activities like white water rafting, paddle boarding and fishing areas and add in some new routes to the reserve.

Again, feedback came in once it opened up and people loved the activities. Whilst new bridges had been erected to connect the reserve, visitors complained about the lack of a direct connection between the newest section and the oldest. Some feedback was provided from a safety perspective that if there was an emergency there was no quick way to get to the medical center at the heart of the reserve and yet again routes which had been created were slightly unsafe and were the “long way round”.

Frayed edges

As much as the reserve had grown into a beautiful piece of land that visitors would enjoy, it also had its faults.
In our world we can interpret the nature reserve as a large product. When creating and building happens at speed, quite often the seams between one place and another can start to fray. This hampers the overall experience that someone may have when you take a look at their experience as a whole.

It can happen when creating and building happens in isolation of themselves without running through the whole experience of the things around it.

As an example, if someone had added visitor needs to a journey or experience map when extending the reserve the first time, they’d likely have noticed the gaps in meeting those visitor needs prior to building it. The experience could have been tweaked in order to meet them better.

The more edges that fray, the worse the experience gets, essentially turning into ‘debt’. It’s not great for users or ourselves.

Retrospectively dealing with frayed edges

Our users don’t slow down so neither should we. So how do we retrospectively deal with frayed edges?

It’s actually easier than you’d think.

We do what we’d have done at the start. We document the whole journey, in its entirety. We identify those pain points, toil, challenge areas, lack of guidance, support or sign-posting and broken connections. All the bits which are just “gah!“.

We then run the whole team through this journey and the identified issues and help them see what we’re seeing. From there we can prioritize the most toil and start to fix those frayed edges, often grabbing the quickest wins and shipping them.

Living journey maps = max value

The most important thing out of all of this is the realization that journey maps should never become artifacts that are used once and then put in a drawer somewhere.

That does not unlock the maximum amount of value.

If they’re kept as liveable documents, kept up to date and used as part of your product process then you’re nailing it.

You can gamify it to an extent whereby you want no amber or red cards on the map and you’re in constant improvement mode whether you’re picking up a piece of toil to fix or you’re adding in a new feature to your area of the product.

Take-aways and tips

• Er on the side of caution when designing and building in isolation
• Use living maps
• Use the maps as part of your product process and roadmapping
• Have all disciplines go through your product regularly
• Align feedback to your map

The post Experiences and Journeys first appeared on Gavin Elliott.

There are a few companies now who have duel track frameworks, one track for management and another track for individual contributors.

The duel track framework can be a learning curve for managers as they begin managing ICs were are at an equal level to themselves. Over the last couple of years, this has become an often asked question:

Do you have any advice for managing an individual contributor who is at the same level as myself?

An assumption could be that you just manage in the same way as you do with your other team members.

However, it’s more nuanced than that – in my mind every level requires something different, and every person in your team will be unique anyway.

As a starter for anyone who is beginning to manage an IC at a similar role to themselves, I’d recommend agreeing on ways of working at the earliest opportunity, basing it on the following points which cover of what you will do as their manager and what they will do as an individual contributor in the team…

You will provide

This list isn’t everything, but it’s a good place to start.

Psychological safety

At a more senior level, our individual contributors have opinions and they should be provided with the psycholigical safety to have them. They should be nurtured and protected just as any other member of your team. Ensure that you provide with the pychological safety they deserve.

Protection of time

Whilst our senior and more experience individual contributors have been around for a minute, it doesn’t mean that they should be spread thinly covering off too many things at once. Their time should be protected as any other persons on the team. They’ll then be able to support you in skills growth of other ICs and ensuring work is done to the highest quality. Protect their time at all costs.

Ensure briefs or kick-offs are organised

Don’t force your senior individual contributors to do the leg-work up front. You should be ensuring they’re set up for success with every piece of work. A brief should be available in a sufficient quality and depth for the work to be started with their peers. Do right by them, always.

Prioritise the work

It’s your job to make sure the team works like a well-oiled machine. Having your senior individual contributors running here, there and everywhere on unprioritised work is not a sign of success. You’re an enabler, so enable them to do their best work.

Make sure you have the right people working on the right thing at the right time.

Support with professional development

This is something that I often see forgotten about when folks move into more senior roles. Their managers take less of an interest in their professional development leaving it up to them to pursue. Regardless of how senior they are as an individual contributor, we as their manager, are supposed to know them intimately enough to guide them on their professional development journey.

Utilise them for the development of others

Senior individual contributors are at the top of their game in terms of skill and experience, as a manager, if you observe development needs of others in your team then you can and should utilise them for that.

That should build up the relationship between you both, building trust and working as a partnership for the greater good of the team.

Keep them unblocked

Regardless of whether they’re a senior individual contributor or not, these folks deserve to be unblocked in the same way as other members of your team.

What they will do

The easy direction on this is ‘Everything that is expected of them in their job description’. However, job descriptions aren’t clear and usually don’t run to the depth of clarity that someone should base their expectations on.

So, a little guidance.

Write some very thorough yet clear expectations for your teams. Every level for every role. Your people will thank you for it. It will go towards reducing impostor syndrome over time, too. Win-win.

Don’t forget…

As a manager of anyone, your aim is to:

• Be motivational
• Be supportive
• Be confident in your approach
• Be a problem solver for literally anything
• Be responsible
• Have empathy
• Be comitted to the team
• Delegate – have the right people working on the right thing at the right time
• Keep trust levels high

To close

Manage your senior individual contributors even if you’re the same ‘level’ as them. Trust me, they want and need to be managed.

The post Managing IC’s at a similar level to yourself first appeared on Gavin Elliott.

I’ve watched teams work together for the last 5-6 years to do this well. Peers from design, product, engineering and data bring their wealth of experience to start work in the best possible way. Knowing this:

• reduces the potential for communication breakdowns
• provides clarity on ‘why are we doing this?’
• ensures the team focuses on user needs
• supports the understanding of what good may look like
• reduces the amount of ‘surprises’ which may crop up

Whilst also knowing that “everyone has a plan until they get punched in the face” – Mike Tyson.

Success Metrics vs Success Measures

One of the most notable things from the past 5-6 years is the imbalance between success metrics, success measures and, more importantly, user-centred success measures.

More often than not, success metrics are in a quantitative format:

• 46% increase in downloads
• 30% decrease in lost applications
• NPS increased by 30 points

Whilst success metrics can give you concrete aims; they’re not user centred.

• a 46% increase in downloads doesn’t mean a user has completed their objective.
• a 30% decrease in lost applications doesn’t mean users have a better experience.
• NPS increasing by 30 points may have to do with something external.

It is my duty and the duty of any design leader to make sure that products and features are user centred. We ensure:

• user needs are at the heart of the work
• there is a balance between business needs and user needs to get a successful outcome for both
• teams do user research to validate/invalidate/learn
• user-centred success measures are defined upfront

I will say that I don’t believe it’s a ‘versus’ situation. We should know that qual and quant can give us great insight when used together. So it’s very much a conversation of bringing user-centred success measures into the mix as a power-up.

What are user-centred success measures?

To frame being user-centred in your mind, you can ask yourselves a series of questions:

• Does X thing work for users?
• Can a user get what they need from it?
• How well does it produce the intended outcome?

The latter point is most notable, does the action/feature/product produce the intended outcome for a user?

Track the ability of users to get to their intended outcome and other metrics to measure how well you’re meeting their needs.

Using both user-centred success measures and success metrics, you will understand whether the growth or decrease in metrics is causing a positive outcome to the experience for your users.

How to write user-centred success measures

Much like the way we write user needs:

• As a user, I need X so that XYZ…

You can write user-centred success measures like:

• As a user, I can X therefore XYZ…

You can use these at both a high-level or intricate level of product design and development.

The post User Centred Success Measures first appeared on Gavin Elliott.

Backstory:

It was December 2015, and I was on a flight to Montreal. A few weeks earlier, I’d begun chatting to the folks at Shopify, and they wanted to interview me. A day-long experience which didn’t feel like an interview at all. Much more chatting with people I liked.

A few days later, I was back in the UK. Oddly for that time of year, it was colder than in Montreal.

I began to reflect on why I was interested in Shopify in the first place. I’d been aware of the company from early on. I was using the product and loved it, and I knew a few people who worked there I respected.

Beyond the company as a name, the product and the people, there was something else. That thing you generally feel rather than see. I felt a level of care in the aura that surrounded the people they were there to serve.

I waited over Christmas with bated breath for the outcome of my time in Montreal and discussed the reality of moving to Canada if an offer came through.

A few days into January and I found out I’d been successful. I received an offer.

And then it happened.

January 8th, 2016.

My Dad died.

A day later, I wrote an email to Shopify to inform them I couldn’t take the role as there was more to sort out than I could have ever imagined. Their reply, which I still have, was filled with care.

I spent much of 2016 sorting and re-sorting my Dad’s and my own life.

As much as I went on to enjoy my time at DWP Digital building the team, professionalising design, public speaking, and genuinely working with some fantastic people, there was always that niggle that Shopify had gotten away from me.

Present Day:

Late last year, whilst at UK Health Security Agency, I thought about what I wanted to do next.

Earlier that year, I’d had many conversations with private companies and decided that private rather than public service was where I was headed.

As much as it pained me, Shopify was out of the question. Most if not all of their design roles were in Canada.

Or were they?

I was scrolling through LinkedIn and saw a role at Shopify and thought to myself, “I’ll make myself smile and cry at the same time to read this…”

And then I saw it.

In bold lettering across the top of the job post…

Shopify is now a completely remote company.

!!!!

After a reasonably direct conversation with Rich* about it, I contacted Shopify.

I was in no rush. I’d just begun my role at UK Health Security Agency as Head of UX and wanted to fulfil my time with the teams to focus on the Covid19 App, Contact Testing and International Travel.

I was ‘all in’ on Shopify**.

I went through a complete process again. I’m a very different person now from who I was back in 2015, with more experience.

Today I join my first call as part of the team at Shopify.

Shopify is the one that didn’t get away.

I can’t wait to get started.

Thanks:

Cynthia, Kevin, Matt, Matt, Mona, Lynsey, Mel and many more folks for your support.

Notes

*Rich has been there for me as a supporter and calming influence throughout the process. He’s a legend. Thanks, Rich.

**There is much more to tell, explain and detail as to why. That will come soon.

The post The one that didn’t get away first appeared on Gavin Elliott.

I want to share my thoughts on managers and leaders who can’t or won’t manage and or lead. I’ll explain the effect this can have on people, teams and organisations.

TLDR; Managers and leaders who are unable to manage or lead (for lots of reasons) can break delivery, momentum and morale and therefore render people, teams and entire organisations ineffective.

I recently shared my thoughts on measuring effectiveness and how to measure whether you are or aren’t.

Management and leadership

Many years ago, I said management was good leadership.

Whilst I still believe some of it, my experience has grown over the years to understand the differences between both fundamentally.

I now appreciate what makes good managers and leaders. I know what happens when a manager or leader isn’t effective, myself included.

I now have a deeper thread to my thinking.

They’re different.

Let’s break them down into some specifics, so they’re identifiable.

Management

There are critical aspects for management, too. Some look like those of leadership but are very different. They can focus on people, understand them, support them, develop them and get the most out of them.

To do that, you’re looking to use a set of skills like;

• motivational
• effective communication
• confident
• problem-solver (in anything that crosses your path)
• responsible
• empathy
• commitment
• delegation
• build mutual trust

Leadership

There are vital aspects like creating an inspiring vision of the future, motivating and inspiring people to engage with it, managing its delivery, coaching, and building a team to be more effective in achieving the vision.

To achieve that, you’re looking to use a set of skills like;

• compassion
• empathy
• confidence (you and your team)
• off the charts communication skills
• ability to make tough decisions
• lead by example
• clarity
• ability to foster a diverse and creative culture
• serve a purpose greater than themselves
• strategic thinking and decision making

Managers manage, and leaders lead, right?

Managers and leaders sit at various levels within an organisation, from entry-level to CEO and Chairmanship, and titles and positions predicate the expectation that managers manage and leaders lead.

The predication is there, but the reality of life on the ground is very different. There are far fewer managers that manage and leaders that lead.

In my mind, there are a few causes to that happening;

• an incorrect expectation that ‘everyone’ is a manager/leader based on a rank system
• moving into a position folks aren’t ready for
• training, or lack thereof
• modelled behaviours

You can see how they can intertwine into chaos. It certainly doesn’t set up an individual or an organisation for success.

Accountability

The person ultimately accountable for the health of their organisation is the person at the very top, the leader of leaders.

They’re accountable for providing a functioning environment to have delivery, momentum and morale.

They decide on the mission and vision, communicate it and delegate accountability to other leaders and managers to move towards it.

They hire the leadership team (sometimes called C-Suite). They set the standards and expectations and ensure they are empowered to do their role.

The functioning environment will happen or not because of them.

They are the example of managers and leaders to the rest of the organisation.

They are accountable.

When the thread breaks

My working assumption is that 80% of people reading this have never had any form of management or leadership training.

Another assumption is that if you’re one of the 80%, it’s likely you’ve not been in a position to either understand the skills needed or been able to put them into practice.

I believe this is where the problem lies, especially in large organisations.

If managers and leaders are ineffective because they either can’t or won’t do management or leadership, it hinders the whole organisation.

In large organisations, this can go unnoticed and can often lead to those with higher expectations leaving to find better managers, leaders and culture elsewhere.

Where do you fit?

It will take some reflection.

You may be an established leader of leaders or a new manager who hasn’t done management before.

You may be in a position where you’re trying to build a functioning environment or effective team, and you can’t seem to make it happen and need support guidance or support, or you’re stuck, you’ve gotten so far, you won’t do anything else, you’re frozen.

As I’ve said, it doesn’t matter what level you are at or where you sit within your organisation. The effectiveness of your management or leadership impacts people and the organisation itself.

But it’s not my fault…

This isn’t about blame. If anything, this article will help you reflect on where you and your organisation are in its journey and hopefully provide a few points and nudges to become better.

Note: blame should not be appointed towards anyone who has not been provided training.

Generally, “I can’t” is more prevalent than “I won’t“, but sometimes “I won’t” is because “I can’t” unless the person has been wholly mismatched with a role and the experience/skills required. Ultimately, their leader or manager’s responsibility is to ensure they’re in the correct position to be effective.

What can you do?

Depending on where you’re at, whether you’re the most accountable person, a leader or a manager, different approaches are taken.

The leader of leaders

You’re held to account by everyone inside and outside of your organisation. That’s what it means to be the leader of leaders.

You must ensure your organisation functions to a high level of effectiveness in the most efficient way possible. Starting with your people, product, processes and everything in-between.

You’re there to make sure those around you are empowered and held accountable for their role. Put everything in place to bring their whole selves to work and be as effective as possible.

For the health of your organisation, ensure the expectations are set for your managers and leaders. Lead by example, show them the way and support the way to get there. Support their development. Some may need experience. Some may require training – make sure this is ingrained in your organisation.

Those that can’t

The biggest “I can’t” is generally down to confidence which usually stems from a lack of experience.

I’ll let you into a secret. Hundreds of thousands of people said “I can’t” as well.

Let me tell you that you can.

You can.

You can.

You can.

Just start.

Here’s a group of management and leadership books that I’ve read, which I know will help you out.

You can get extra support and help by getting a mentor or coach, too. I highly recommend this route.

Ask for some training, either externally or internally.

Now, if “I can’t” stems from your manager/leader stopping you or acting in a way that doesn’t empower you, then you have a big decision to make.

People don’t leave bad jobs; they leave bad managers/leaders.

I can’t remember where the saying comes from, and it’s likely just a meme as there are many reasons you should leave a bad job but usually, having a good manager/leader can do wonders.

Depending on where you are in your organisation, there are a few choices;

• move away from your current manager/leader
• move into your managers/leaders job
• leave the organisation

I believe you need to reflect and assess where you are regularly and understand your next move.

Those that won’t

If you know that you won’t, for whatever reason, you need to understand that everything you’re not doing is affecting everyone and everything around you.

The knock-on effects are crippling;

• low staff retention
• high staff sickness levels
• increase in costs due to terrible efficiency
• low customer feedback scores
• decrease in sales figures
• reduced product output

The list could go on and on.

If you don’t realise you’re not managing or leading, then you’ll have to identify other factors which tell the story for you.

Ask people for feedback in a radical candour type of way. Ask if they feel empowered, find out if you’re doing a good job, and they’re effective because of it.

If you know, then you have a baseline. If the picture you’re presented with doesn’t look great, put a plan in to fix it. If it does look good, find a way to keep improving for those in your stead.

It doesn’t matter which level you’re at in your organisation. Every echelon of management and leadership should have reviews and 121s.

Closing comment

In some large organisations, everyone who attains a certain rank or grade is expected to be a manager or leader regardless of their experience.

The organisation’s grade structure says so.

The grade doesn’t make the person a manager or leader.

Training, experience and skills do.

The post Managers and leaders first appeared on Gavin Elliott.

I’ve been thinking about being effective a lot lately.

Just so we’re clear, the definition of effective is;

successful in producing a desired or intended result

Regardless of where you are in your professional journey or what role you have, it’s absolutely normal and right to want to feel like you’re achieving something.

Being effective gives you purpose, motivation and keeps your morale high.

As organisations grow in size, the ability to be effective can start to diminish.

More work, more people, more silos, more personalities, more politics and more governance… you can see where I’m going with this.

I’ve watched morale be broken, impostor syndrome go into overdrive and fatigue kick in faster than ever before.

It led me to think about how we can measure effectiveness, ground ourselves with a level of evidence and then execute on it.

A set of questions

Are you empowered?
or Do you feel like you need/have permission to do the things that need to be done?

Are you working well?
or Do you feel like things are working in the right way?

Do you feel the work you’re doing is important?
or Is it validated as important to you or the organisation?

Do you feel like you’ve achieved something in the last 30 days?
or Can you recognise the last time you felt you achieved something?

Do you feel like that thing is having a positive effect somewhere?
or Can you recognise the value it has had on others?

Do you feel like it has had a positive effect on the overall goal of your team?
or Can you identify that your team is feeling positive and moving towards their goal?

Is your team effective and having a positive effect on the overall goal of your organisation?
or Can you recognise that your team effectiveness is meeting the goal/strategy of your organisation?

Depending on how you’re getting on answering those questions and assessing your answer to each, the next question is the one which could hit a lot home.

Am I / are we really that effective at accomplishing things? What impact has my/our effectiveness had?
or Am I / are we set up to be empowered and/or effective?

Conditions for effectiveness

There are key conditions required to create effectiveness for an individual, team or organisation.

• Hire people better than you, always
• Be honest and have integrity
• Make people feel safe and provide them the space to do their best work
• Meet a problem with the right skills and experience – NOT job titles
• Create empowerment everywhere
• Make sure your strategy and mission is publicised
• Make sure your strategy and mission is clearly defined, concise and understand by all
• Ways of working need to be defined, processes need to be simple and smooth
• Operationalise as much as possible

As much as the above list will help create the conditions required, there’s one larger and more nuanced piece which needs to be navigated…

Human behaviour

Humans are the only ones who can make any of this happen.

They’re also fully capable of derailing it.

The person with the most accountability is ultimately responsible for making sure the conditions are available to all.

There’s a strong leadership play to make, to lead by example and emanate all of the good behaviours required.

If you’re individual or a team and you’ve recognised you’re not being effective and can identify why, then I implore you to use the evidence and show how things can be better and tell it like it is.

The post Measuring effectiveness first appeared on Gavin Elliott.

The change in my role within the Department for Work and Pensions (DWP) over the last few weeks was one I needed. As I’ve mentioned, the role I started wasn’t the role that it ended up being. There is more to write about that in future.

The benefit I had in my first days is that I knew a lot of the people I’d be working with. Importantly I knew who my new manager would be and my ‘C-level’.

Fay Cooper, my new manager, I had worked with before. I’d acted in a consultancy type role for the area Fay was working in. Fay has all the qualities we should expect of Product Managers in digital, in Government.

We have a great working relationship and matching enthusiasm to do the right thing.

My first days in government

In 2015 when I joined the DWP and Government, I kept a little note of my first 10 days. I listed my thoughts, musings and observations.

My first days in a new role

As with any big change I thought it would be good to do the same thing again. A lot has changed not only within my own Department, but also Digital UK Government across the board.

Day One

My new role is a new directorate of the Department. I asked myself a series of questions;

• Who are we?
• What do we do?
• Who are the stakeholders in our directorate and others?
• What is our vision and ultimate goal?

Coming from outside of the directorate I’d observed others not knowing who we were.

Big thought;

• There’s a lot going on, I need to map the things and the people to understand it better

Day Two

We need our closest allies aligned on strategy.

Big questions;

• Are we talking about the same thing?
• Are we using different words/language to describe the same thing? (Fairly dangerous)
• Are we using different words/language to describe different things which we’re assuming are the same? (Really dangerous)
• What guidance or documentation do we have for people to use now?

Big thoughts;

• Not having a shared understand early is detrimental to long-term progress
• Communication is key, use the right language at the right time
• Ask questions to get clarity
• I need to rally the community – let’s do this

Day Three

Our architectural community are great. Their appetite for doing the right thing is high as is their ability to see a future state. They may well be ahead of others in their thinking, we may need to catch up.

In any thing you do whether it’s internally or externally there is an element of selling ‘it’ to people. We need to find a way to promote and sell, effectively.

Big thoughts;

• What’s the biggest priority out of all the priorities?
• Show the thing
• Work in the open

Day Four

Lots of listening and talking today.

Are we reactively pro-active or pro-actively reactive?

We provide things to teams to enable them to create a better user experience. The teams utilise these across their service offering.

Big thought;

• There are some meaty things which are enablers X-as-a-service type things. These need promoting so that the teams understand what they are and how they use them. Both of which need explaining in a simple and effective way

Day Five

I can’t help but think we’re in the right time to do the right thing boldly. Being bold always holds an element of risk. We can de-risk this through research and data, yet, ultimately a decision on being bold has to be made.

There are folks around us who appreciate this.

Big thought;

• I wonder how people in other organisations measure their boldness?

Day 6

There are a lot of things being worked on. Do we have enough people from user-centred design working on them? We need to make sure content, research and design is represented.

If you want to understand someone, have a 1-2-1 with them and ask as many questions as possible. But, also make sure you both walk away with the same understand of what you discussed.

Working groups… working groups need more musing on.

Big thought;

• Make decisions based on evidence not personal crusades

Day 7

Sometimes showing the thing (work) without asking for permission is better. They can create value and enable design to show its worth with very little effort. One of the reason why prototyping will always be my go to method.

Interviewing today, I still enjoy it!

Day 8

The language and words we use are important.

Calling something 8 different names causes confusion and breaks alignment and understanding.

It’s time to ‘go loud’ with the work we’re doing, working in the open.

I want us to communicate always about our work and make sure it’s effective.

Day 9

“The Custodians of Common Components” – It could work but will need managing carefully.

Had various conversations with different areas today. I’m loving this new role.

Done my two mentoring sessions and really enjoy doing them. I do wonder if I provide value in these sessions, I guess that’s a little bit of impostor syndrome creeping in.

Big thoughts;

• The consistency of what you’re saying, how you’re saying it and why is key.
• Ben told me to say the same thing repeatedly everywhere and you’ll notice it catch on. I’ve done it since he left and it’s time to keep doing it.

Day 10

I finished off the ten days in a full day of interviews. After all this time I still get excited by the work we are doing when talking to interviewees. It’s one of the reasons why I’ve never left the Department.

Thoughts

Safe to say that I feel that I’ve made the right decision in changing roles. Whilst there is so much to do, I don’t feel daunted by the task at hand. If anything the task excites me even more.

The biggest accomplishment in the first ten days was aligning a large group of people on one thing. This came about by simply changing the language and explaining in a way people could understand.

I can’t wait to get going and write more about our work.

The post The first days first appeared on Gavin Elliott.