Taking the temperature

What do you do to keep an eye on how your team is doing – as individuals and a team?

A less-structured meeting (or part of a regular meeting) can really help: a chance for everyone to check in, say what’s going well and what they’re struggling with, to let off steam, to ask for and offer help, to say what’s on their mind, or kick around a new idea or two.

Super important. Super easy to push aside when things get busy – which is when you most need to know how everyone is doing, and to do all of the things above.

Raising the average (2)

The basic principle is that when you’re recruiting, you should be seeking to raise the average of your team, bringing in people who increase the level of energy, skill, and possibilities available – and who raise the bar in terms of commitment to your aims and values.

This is a helpful rule of thumb, but there are two problems with it:

  1. The more successful you are at raising your average, the harder it’s going to be to keep doing it.
  2. As you get better at what you do and grow as a team, it’s also going to get harder to find people who raise the average in what are presumably key areas.

So it’s inevitable that you’re going to lower some averages, some of the time, if you want your team to grow. It’s doubly inevitable if you’re seeking to build an organisation that increases the average, both internally (as individuals learn and grow and as the team works better together) and in the workforce (as people move on and take what they’ve learned to make a contribution elsewhere).

I think the answer is to make sure that you’re clear about which averages are non-negotiable, and which of the others are most important at a given time:

  • Values and integrity
  • Enthusiasm / energy
  • Commitment to your vision
  • Maturity – consideration and care for others
  • Skill in a key area. This could be something you deliver, like training or a technical service you provide for your clients – or a support function like accounting or managing infrastructure.
  • Readiness (and ability) to learn and grow

It’s worth being clear first about the non-negotiables of values and attitude (that is, character) – and the energy that you need a new team-member to bring to the team.

You also need to know which missing skills you’re seeking to add to your team from the outset, and whether you expect these to arrive fully formed (how will you tell?) or are going to help your new teammate acquire them (you need a training plan, and you need to make sure that you carry it out).

Beyond that, a lot depends on the stage of development of your team, and whether your priorities are growth into new areas (finding people to create possibilities and help you do things that you can’t already do), increasing capacity (adding people to help you do more of what you already do) or consolidation (adding people who will help you do what you already do better). It’s worth bearing in mind though, that the two types of growth create a need for consolidation, and consolidation creates the potential for growth.

The Onion (2): a model for solving interesting problems

My first post about The Onion looked at interesting problems as systems of networked sub-problems, and suggested that our solutions will mirror this structure.

The Onion is also a good metaphor for the process of finding practical solutions: we work from solving the smallest problems in theory, outwards to technical solutions, before we finally build a (networked system of) practical solution that works consistently and at the scale we need.

1) Theoretical problem – theoretical solution

First we work out how – in theory – the problem might be solved. This might be a simple case of gathering information, because the theoretical problem has already been solved – as in the case for all the three problems above.

If the problem doesn’t yet have a theoretical solution, we’ll need to break the problem into smaller pieces, work out what’s missing, and treat the smallest unsolved piece as a new interesting problem. (see the example above: family health)

2) Technical problem – technical solution

Once we have a theoretical solution, the problem becomes a technical one: how do we apply the theoretical solution in the world, in this context, to make the solution actually work? The old saying about the difference between theory and practice holds true here. When we attempt to put our theory to work in practice we uncover buried assumptions and dependencies that make our theory impractical without major revision or lots of additional work to create the conditions in which it will work. So we have a choice: modify the context enough to make the theory work, or modify the theory to better suit the context. Often we do both.

Example technical problems:
Yikes, how to do I reduce the number of horrifically-bad-for-you things that my family eats on a regular basis?
In our context, what does a healthy diet look like?
Given that I can’t source organic kale in my neighbourhood, what are the alternatives?
How do I make kale-alternatives delicious?
Which components of a healthy diet are easiest to add to what we already do?
What habits can I encourage that will make it easier for my family to eat healthily?

3) Practical or scaleable solution

This is often the most overlooked part in solving an interesting problem: what is the ‘wrapper‘ of infrastructure and activity necessary to make the technical solution workable on an ongoing basis.

This is usually about the collection and coordination of scarce resources (time, money, people, other inputs) that are needed to solve the problem reliably.

The Onion (1): understanding interesting problems

This post is a sketch of a way of thinking about how problems work, and what we need to do to make our solutions (“the change we seek to make”) effective. It’s bit abstract – I’ll share a more concrete illustration in a later post.

We often talk about interesting problems as if they’re discrete units:

  • How can I keep my family healthy?
  • How can we split the atom?
  • How can we help more children learn to read?

But all interesting problems really consist of little clusters or bundles (or networked systems) of problems – we just can’t always see what the problem-network looks like until we’ve spent some time working in it.

We can work our way down the problem hierarchy, reducing complexity as we ask smaller (and usually more easily solvable) problems.

Example theoretical problem:
How can I keep my family healthy?
Example sub-problems:
What is a healthy diet? How can I make sure my family has access to it? How can I make sure that they eat it? What foods do they need to avoid, and how can I make sure they do?
What’s a healthy level of exercise?
What about emotional health?

In lots of cases, the sub-problems have sub-problems… and so-on.

We can also work our way further out too, from micro-problems to macro – for example, “How can I help other families to live healthier lifestyles?”

The onion

So we end up with a multi-layered set of nested-problems – ‘the onion’. And effective solutions will mirror this structure of solutions-within-solutions, with each layer creating the necessary conditions for the layers within it – more on this in an upcoming post.

*see also: the wrapper

Seth Godin on transforming education

Seth Godin has written a lot about education – Stop Stealing Dreams (TED talk and longer e-book) is a good place to start.

Then it’s worth checking out what he’s actually doing:  the altMBA reverses the usual 90+ percent drop-out rates of most online courses, and the Akimbo workshops (including The Marketing Seminar, The Bootstrapper’s Workshop and The Freelancer’s Workshop) get rave reviews.

In this article on Medium Seth lays out some of the core principles of his approach.

Also check out the videos at the Akimbo Workshops link above – especially the one at the very bottom from Creative Mornings, where he sets out his thinking behind the model.

Interesting problems: a definition

A problem is interesting when…

1. It’s important to someone

Presumably because solving it will make things better.* The problem won’t be important to everyone, so by definition it won’t be interesting to everyone either.

The problem will be valuable in proportion to the number of people it is important to, and how intensely they feel its importance.

This means that problems exist in a network, and gain their importance and value from their position within the network – this is true of both their actual and perceived importance and value.

2. A solution isn’t immediately obvious or available

Sometimes (rarely) a problem is hard to solve because it’s actually new and unique – a world first. More often it’s because interesting problems are actually systems (or networks) of smaller problems, and are closely bound up with their local context, which means that there won’t be a simple, discrete solution: a ‘system’ of problems will require a ‘system’ of solutions.

It also means that what looks like an old problem in a new context (a new place, time, group of people, culture) is likely to respond differently to previously successful solutions. A new configuration of the problem ‘system’ will require a newly configured set of solutions – and the solutions that work best will change with time.

3. It doesn’t have a perfect solution

If you understand a problem as a system, you understand that predictability and perfection are impossible once you move beyond the most basic or theoretical level. Instead we need to understand the best solutions as those which most improve the disposition of the problem system, giving the best chance of a ‘good enough’ outcome.

4. We may not even be able to find a satisfactory solution

If you can’t fail, it’s not interesting.

5. The solutions to the problem are dynamic

If interesting problems are dynamic systems within changing contexts, ‘happily ever after’ isn’t possible from a single (fixed) solution: old solutions will become less effective (or less acceptable) as the context changes. Both the solution ‘system’ and the system that generates the solution need to be dynamic too.

What do you think? What problems does this perspective help with? Where does it fall down?

*Stopping things from getting worse is a way of making them better

Responsibility

Whether you’re improving your own work or helping others improve theirs,* it pays to spend time talking about who is responsible for what – and what you hope people will take responsibility for as they grow into their roles.

There are layers of responsibility.

1) Given all the necessary inputs…

Do you take responsibility for getting your job done?

2) If an input is missing…

  • Do you shrug your shoulders and put down your tools?
  • Or do you take responsibility for passing the problem to the relevant person – a colleague, supplier, manager?
  • Do you take responsibility for chasing up the solution?
  • If needed, will you work with the relevant person to make it easier for them to fix it?
  • Will you give thought to whether this problem is likely to happen again – and think about what you can do on your side to fix it (by, say, allowing more time in your process)?
  • Will you take responsibility for the breakdown in communication or process – by talking about it, asking for help, trying something new?

3) If the inputs are fine and the process is working…

  • Will you ask how it could be done better?
  • Will you think about whether you could entirely replace the process, or do away with it entirely?

4) Above and beyond the level of processes…

  • Will you take responsibility not just for the defined outcomes of the process, but for what those outcomes are actually supposed to achieve?
  • Will you set an example of excellence in the quality of your work…
  • Including how you treat people while you do it, both in and outside your organisation?
  • Will you take a degree of responsibility for other people do these things – that is, for setting and improving the culture?**

Basic competence in a defined task is just the start – taking that as given, members of your team become more valuable the further down this list they go.

There’s a world of difference between managing someone where you responsibility for their work, and working with someone who takes responsibility to make sure the right things get done in the right way – and helps you and others to do the same. Find more of those people.

*it’s usually best to think about both at once

**No-one likes a meddler, but most of the time most of us make the mistake of not taking enough responsibility for making things better.

Seth Godin on recruiting: raise the average

That next person you hire – are you lowering the average, or raising the average? ‘Cause if you’re lowering the average of your team because you’re in a hurry, when are you going to stop lowering the average of your team? How low does the average of your team go before it’s over?

On the other hand, anytime you can raise the average of your team, it’s probably a smart move.

Seth Godin – Entreleadership Podcast, Ep. 266

This applies to technical skills, but I think it’s even more relevant to team culture.

WhatsAppterview

I love WhatsApp voice messages. Through the wonder of the voice message (and especially after the introduction of the wonderful voice-record lock) I have better conversations with more of my friends – many of whom I only rarely catch face-to-face – than I have done for a while.

Asynchronous or semi-synchronous (those flurries of messages back and forth in almost-real-time) messages are far easier to fit into your day, especially across timezones.

So here’s the question: what about a semi-synchronous WhatsAppterview (you heard it hear first)?

In the spirit of do it now, I’m going to try. Watch this space.

Questions:

  • Will a normal phone mic straight into whatsapp produce ‘good enough’ quality?
  • Will the conversation flow?
  • Will I die stitching it together?

They’re (not quite) taking our jobs: Tim Harford on robots, spreadsheets and automation in the workplace

These are two great episodes from the BBC’s excellent 50 Things that Made the Modern Economy.

Episode: Robot

The robots are coming! Sort of. Featuring Baxter and the Jennifer headset.
More on Baxter here at WIRED.

Episode: Spreadsheet

Fantastic discussion of how the humble spreadsheet destroyed over 400,000 American jobs… and helped to create 600,000 more.