Kahneman talks about the brain’s two discrete systems:

• Automatic system – Fast, automatic, frequent, emotional, stereotypic, absolute, short term, subconscious
• Deliberate system – Slow, effortful, infrequent, logical, calculating, balanced, long term, conscious

One of the main points that I took away from the book is that using the deliberate system is hard work and depletes your cognitive energy, so our brains are always looking for ways to delegate to the automatic system. The psychologists call this a ‘heuristic’ or bias– a simple set of rules and shortcuts that people use to arrive at judgments and decisions.

I spend a lot of time thinking about productivity – how I can be more productive, how we can be more productive as teams, and organisations. The old adage is that ‘if it’s not measured, it’s not managed’, but how do we measure productivity?

In software development, it’s reasonably straightforward (at least in agile software development) – a developer’s ‘commits’ can be counted, the velocity of a development team can be measured against planned activity with burn-down analysis and bugs can be measured with daily automated testing, and projects can be measured by Earned Value, and other methods. But individual contribution in most white collar jobs cannot be so easily measured: how good are we at planning, negotiating, relationship management, administration, writing, presenting – how good are we in meetings?

Trying to measure this stuff is really hard, so we don’t. We use heuristics to help us.

We tend to think that people who talk a lot have a lot to contribute (when sometimes the opposite is true).

We think that people who express their opinions robustly should be listened to (‘they sound very sure, maybe they know something I don’t’).

Most damaging of all, we assume that because people are in the office for long hours they’re being productive (despite long hours and productivity being negatively correlated in a number of studies), because they’re available for work.

I sometimes find myself working long hours, on the train, in coffee shops, or after the kids have gone to bed, and occasionally in the office, because I choose to. However, the more senior you are the more your behaviour sets the tone for others, and if we want well-balanced, high performing teams, we need to think deliberately about the contributions that individuals are making in each area, not rely on a lazy ‘available=productive’ heuristic.

Some of the best members of teams I’ve worked on have been strictly 9-5, and sometimes less – it’s up to all of us to recognise real value if we’re to do better than just counting warm bodies around the office.

@anthony__lewis

When starting a new engagement, or a new role, the question that’s most often in my mind (apart from ‘where’s the nearest decent coffee shop?’) is ‘how can I add the most value here?’

Around a decade ago I worked at a client where project managers were a new thing – the management team had decided that the organisation’s delivery capability needed beefing up and several project managers had been brought in to ensure that key projects were delivered. In my first weeks I was regularly asked ‘what’s the point of a project manager?’ It was a genuine question as much as a challenge, and it led to some existential pondering – I’d taken it as self-evident that you needed a project manager to manage a project.

Looking around the organisation, there were hundreds of projects of varying sizes, most of them being loosely managed by people whose time and attention was consumed by their day job, and constrained from getting enough resource or attention from other parts of the organisation by silos and hierarchy. Everywhere projects were delayed, and no-one knew if they were achieving what they set out to do – project documentation and governance was sporadic at best.

After a couple of weeks in that role, the answer to the fundamental question had become clear in my mind, and these themes have crystallised in the intervening years.

A project manager is:

• The person on point for the delivery of the project – i.e. the person that can be fired if the project is failing, without seriously disrupting the core organisation
• The person who can tell you whether (and how) the project is meeting its objectives
• On top of the detail – can provide updates (usually from memory) on progress, risks, issues, and dependencies, knows what’s happening now, and what needs to happen next
• Able to unblock progress, whether by escalation, persuasion, or force of will
• Able to bring together teams from across an organisation, without being overly concerned by hierarchy

In the interests of balance, I did concede (as we still must) that a project manager can also be an expensive resource whose effort is put into management of logs and reports without putting their shoulder to the wheel and managing the actual things that will deliver a project.

A project manager who is in charge of their project becomes the go to person – the one who acquires a reputation for getting things done, but this reputation has a dark side. As a profession we’re focused on the scope of our projects in order to protect time, cost, and quality, but in an organisation where the process of commissioning projects and bringing their output into operation is unstructured and lacking ownership, we can find that our own personal scope enlarges to an alarming degree.

This can happen slowly: a meeting where no-one else picks up the actions, a plan that parts of the organisation don’t deliver and which has no consequences, issues that arise that don’t have an owner in practical terms (if someone’s name is against the action and they don’t do it, and nothing happens – there is no owner), and the service organisation you’re delivering into is unstructured. You have two choices:

1. Log the risks and issues, adjust the plan accordingly, escalate, and kick up a fuss, or;
2. Do the work yourself.

If you’re on the hook for the project’s success and failure would reflect badly on you, you’ll probably do both. This is workable if the project isn’t too big, or you haven’t got other projects, but where this isn’t true you won’t be able to fill all of the gaps. Or rather, you may be able to, but at significant cost to any pretense of work / life balance.

This is where we need to look to ourselves, and decide how much we want to give – to ask ‘which gaps am I prepared to fill’, and perhaps more importantly – which we’re not. We all hear stories (and sometimes witness or experience) the results of acute stress, and to avoid falling into the gaps ourselves, we can take some small but practical steps:

• Chair meetings yourself – it’s then easier to bring issues to a head, assign actions and follow up. i.e. it’s a challenge to steer the ship if your hand isn’t on the wheel;
• Keep notes (ideally in a shared action tracker) – being able to demonstrate commitments that people have made makes it much easier to ensure that they keep them;
• Escalate early, and constructively – if you become known as a project manager who only escalates when its really necessary and when something can still be done to fix things, and that you’re providing potential solutions as well as well-defined problems, senior members of the organisation will pay attention;
• Lean in – you can’t get around the fact that some projects will require a huge effort, and it’s infinitely better to embrace the work and deliver the project rather than moan about all the problems you have and fail.

Every organisation has its heroes, and its martyrs – it’s our choice how far we go along this continuum.

@anthony__lewis

General Melchett, Blackadder Goes Forth

Like Health & Safety, security is easy to blame for life’s inconveniences; from ‘security theatre’ at airports, to unnecessarily complex requirements for accessing everyday services online.

Security plays an ever more visible role in our lives because it is increasingly important when we leave a trail of personal data wherever we go online.

In my current engagement I’m managing a security project that underpins part of the UK’s critical national infrastructure, and so come into contact with information security PhDs, grey hat hackers, and people who spend a lot of time in Cheltenham. It’s genuinely frightening how easy it is for people with the right skills and some basic tools to breach the security that most of us put around our online identities, whether we’re using the same password (or variations of it) for everything or not, or whether we’re using ‘password1’ because it’s easy to remember.

When it comes to the systems that we build, a lot of organisations find it hard to find the balance between security and usability – erring on the side of ever-more security. This is probably because there are a standards for every aspect of IT security, from verification of identity to backups, and where there is an inevitable tension between hard (defined standards, audit, certification) and soft (user research, business need, ideas) – hard almost always wins.

The problem is that this often backfires. In trying to lock down what people can do to an ever-greater extent, organisations find that people work around the constraints to accomplish what they need to do.

The more complex we make password rules, the less easy they are to remember and the more likely it is that users write them down in a place that’s easily accessible.

The more we lock down access at work, the more we’ll use our own devices – where corporate IT security has no control at all.

The more rules there are, the less we’ll appreciate which are the important ones.

In almost every design workshop I repeat the mantra ‘users are like water – they will find the easiest path. If we don’t provide the easiest path for them to accomplish what they need, they will find another way.’

We can find this path, and a balance, by asking what we need to accomplish as users, and fitting this within a framework of security considerations. We need standards and rules, but we also need to be able to do our jobs. We don’t need isolated decisions (which are easy) that layer up into a hellish bureaucracy (making things hard).

Designing systems (in the organisation-as-a-system sense) is hard work but by mapping out the consequences of our decisions and asking ‘what will people do?’ when we’re making architectural decisions, and then watching what they actually do with the early versions of the systems they use, we’ll find a better balance between security and usability, and will have systems as secure as they need to be, and users who can do their jobs.

@anthony__lewis

A few weeks later we were both wondering what all the fuss had been about – the Three Letter Acronyms had meaning, we’d learned the names of a lot of the people in our organisations, and were getting to grips with our different roles and how to do them.

Since then, the feeling of mild panic and confusion when starting each new job. engagement has steadily diminished with experience. Projects (in particular) tend to have repeating patterns, and broadly-consistent terminology which enables us to identify problems you’ve already seen, and re-assure nervous new colleagues that you (vaguely) know what you’re talking about.

My friend and I have since agreed that if you don’t feel a little out of our depth in a new role, then we probably haven’t stretched ourselves enough – if we’re starting a new job and you already know the ropes, we’re probably re-tracing steps and the opportunity for learning is greatly diminished. Likewise, if we stay in a role too long, we experience diminishing returns the longer we stay, as our learning curve flattens over time. On old boss of mine was fond of asking whether someone had five years of experience, or five years repeating the same things each year – ‘are they 1×5, or 5×1?’.

So when we step into an environment where there are more acronyms than we’ve ever imagined, and so many moving parts, organisations involved, and people to talk to that by the end of some meetings we’re not sure who’s who – it’s an unsettling experience, but not a negative one.

It reminds us of the need to get our heads down, read the voluminous documentation, listen to people, and draw lots of pictures to make sure that our understanding the context of the project, and that what we’re delivering matches the pictures in everyone else’s heads.

With each new challenge our knowledge, understanding, and abilities grow, and over time our learning curves build on each other so that we can start creating value for our clients (or our boss) more quickly.

@anthony__lewis

We work on things that people in charge of a budget want their organisations to have. This could be because:

• It looks like it might make some money
• It fits within the organisation’s strategy;
• One of the senior people in the organisation think it’s a good idea;
• A competitor or peer has one and your organisation doesn’t want to be left behind;

And the number one reason:

• It looks like it will save the organisation money it’s already spending (saving money being much easier to predict than making money, as well as being less reputationally risky for the budget holder)

I’ve managed a lot of corporate technology projects over the past decade or so, and almost all have been compromised from the start. They’ve started out with the ‘what’, rather than the ‘why’ and the ‘how’, started with a list of features specified (at best), rather than looking at the undertaking as a whole and asking:

• ‘How can we make the job of the people whose job function it is to use this new process / system easier?’
• ‘How can we help them accomplish their work in a dramatically improved way?’
• ‘What is the purpose that we can unite around?’

Projects and systems are usually commissioned by people several hierarchy levels away from the people whose jobs are going to be changed by them, so there’s an inbuilt tension between the organisation’s objectives (some of which are listed at the top of this post) and the objectives of the people doing the work, which are necessarily focused on more operational concerns.

There’s a huge body of work in the field of User Experience (or UX as those in the field refer to it), which focuses on how people use systems based on observation, rather than the more traditional methodology of documenting an processes and features based on an imagined (and not necessarily shared) view, adding elements that will compromise the real users’ experience with every decision.

In common with many people, my UX starting point was the seminal Don’t Make Me Think by Steve Krug, which I came across when my team were looking for ways to challenge a software vendor who claimed their software was intuitive and easy to use, when it was patently neither. Since then I’ve read a lot of books on UX, and the academic discipline that gave birth to it: Human Computer Interaction (HCI). I’ve listed some of the most helpful (a purely personal recommendation) at the bottom of this post.

In creating Speakr I wanted to build something that worked from the user’s perspective, to make it easy for them to use Speakr to make their school lives better. In this case the users are children between six and twelve, and their teachers.

I didn’t start with a specification. Building on the original idea of self-reporting for children in care, I started with the core idea (Speakr should focus on helping children to articulate how they felt at school) and sketches that I iterated quickly as I talked to schoolchildren and their teachers to understand how they interacted, the environment they spent their days in, and the things they wanted a product like Speakr to do.

A strong idea and a plan of sorts helped to persuade two of the UK’s brightest freelancers (Anna Debenham and Laura Kalbag) to join the cause, and we prototyped our ideas to find out what worked and what didn’t.  Doing this was comparatively cheap and quick, in stark contrast to the waterfall method used in most big projects where all design decisions are made up front. The fundamental weakness in waterfall is that you cannot possibly anticipate the ways that people will use a system, and you’ll need to make expensive and disruptive changes during the development and testing phases when users get their hands on it. See the majority of public sector IT projects for further details – this one being the latest in a long line.

Being a tiny group made it easy to focus on the product, because the whole focus of the ‘organisation’ was the product. This focus is something that we’ll work hard to keep as Speakr moves forward – when talking about Speakr, people often suggest new features; ‘it would be great if it could do X’, but if X doesn’t pass our design criteria (and unless it’s going to add enough value to persuade me to pay for it), it doesn’t get added. These are the design criteria that have served Speakr well so far:

• Focused – the function of each element (how to use it, what it is for, and how it relates to other elements) is clear;
• Friendly – the visual style, tone of content, and interactions are designed to help the user smile;
• Useful – every element has to earn its keep in relation to the core purpose of the system: to help children articulate how they feel, and to make it easy for teachers to see which children need help and engage with them.

I’ve been working on Speakr for more than two years (when client engagements permit) and throughout this time the most rewarding part of the project has always been talking to children and their teachers about Speakr in their school, and watching them use it.

UPDATE 23rd Jan 2014: We’ve always made our best work when we’ve talked to our users, and when we asked the hundreds of children who use Speakr what they thought of it (through the tool itself of course), it was humbling to have this response:

Making something that people like using involves the hard work to understand how it can fit in with their job to be done (rather than trying to bend them to the will of the organisation), and a lot of time spent thinking your way out of dead ends, but it sure beats the first day of User Acceptance Testing carnage on a big waterfall project.

@anthony__lewis

The Field of User Experience design – a starter for ten

Not all of these are  UX-related, but they all focus on understanding why people interact in the way that they do, and that helps.

Designing Interactions – Bill Moggridge

Undercover User Experience – Cennydd Bowles and James Box

The Elements of User Experience – Jesse James Garrett

The Back of the Napkin – Dan Roam

Rework – Jason Fried and David Heinemeier Hansson

Sources of Power – Gary Klein

It’s probably because when someone plays a beautiful concerto, you know that you couldn’t possibly do what they do, but you appreciate what they do. The same is true for a beautiful bespoke bookcase, or a glorious cover drive, but it isn’t true for a fixed gearbox, or a elegantly executed algorithm.

We’re used to things just working – it wasn’t always thus, but thanks to the quality-obsessed six sigma competitive landscape – it is now. When things don’t work we want them fixed. We don’t care what’s wrong with the gearbox, or the electrics, or the app, we just want it fixed. And cheap.

When we’re working on projects and talking about what a system / building / anything needs to do and people hold up their hands and say ‘I’m not technical’, they’re not saying ‘I’ve reached the limit of my technical knowledge, and the things you’re saying are going over my head’.

They’re saying ‘I’m not prepared to try and understand what you’re saying or why it matters, and frankly I’m not interested.’

There are plenty of times when I’ve seen this line trotted out in meetings, by people who should know better – people who should have an understanding of the technical detail they’re nominally responsible for, whether that’s system functionality, or the business rules that govern decisions in a process flow.

Project managers are generalists, almost by definition (even ‘Technical Project Managers’) – we may not understand the detail to the same degree as the programmer explaining it, but we have a responsibility to do our best to understand it, and to make it easy for others to understand – to build a shared language.

Saying ‘But I’m not technical’ often means ‘I can’t be bothered’ – if you can’t be bothered to appreciate someone’s technical skill, why should they bother to do more than the minimum for you?

@anthony__lewis

I’ve been wanting to talk about the transition from corporate life to startup founder (and how balancing the two is often necessary) for a while, and this was a great opportunity to talk about a few of the things I’ve learned over the past 18 months working on Speakr while holding down a demanding job.  The event wasn’t filmed, but here are my slides.

A couple of my slides generated a lot of nodding heads (at least I think they were nodding – it was quite dark). I talked about the gap between thinking about doing something, and actually doing it, using the analogy of The Penny Gap.

Venture Capitalists sometimes complain that entrepreneurs assume an elastic relationship between price and demand (that the line between them on a graph is effectively straight – the higher the price, the lower the  demand). The reality they say is that there is a demand cliff between a free service, and one that charges just a penny, like this:

There seems to be a similar relationship between thinking about ideas and taking action on them, like this:

While we’re fantasising about our idea and the impact it could have on the world – anything seems possible, until we start trying to do something about it. Then it seems a lot harder, and more often than not we let it go. Sometimes though, if the idea is a really good one, we don’t.

That’s where really interesting things can happen.

@anthony__lewis

Like many people who make a living from getting stuff done, problems are an everyday thing: they’re just part of the rich tapestry of projects, and indeed – life. I wrote about problem solving a while ago here and here, but the question made me think more deeply about the different ways to approach problems, and I was pretty happy with what I came up with as an answer, so I thought I’d share a slightly fuller version of it here.

As we work through projects, delivering the building blocks that contribute to a successful programme (as per the figure below), the rate of progress varies, depending on resourcing, focus, constraints, problems and so on. Sometimes problems don’t impact progress for longer than it takes to have a conversation, but others can have a more disruptive impact – taking longer to return progress to the critical path.

1. Validate
In a project team (and even more so in a programme team), there is a variable threshold for uncertainty: one person’s major issue is a line on another’s To Do list. Treating everything that happens unexpectedly as a problem spreads doubt through an organisation, so the first step is to establish whether it merits attention as a problem in its own right (i.e. whether it has the potential to impact key parts of the project), or whether it’s just something that needs to be added to a To Do list.

2. Solve
If the problem is a simple one, then a little thought and a few conversations are often enough. If it’s more involved then I’ll get a few people (3 or 4 seems to be the sweet spot) together and whiteboard potential solutions until we’ve agreed on a solution that;

• will work, and;
• we can explain to the rest of the team, and more importantly the client.

3. Work-around
If we can’t come up with a viable solution, or if constraints (usually time and the associated resource costs) mean that there’s no time to implement a thought-through solution, then we go to the next step – working around the problem.
On well-run projects we can batch most of these together for post-go live resolution. On other projects, they may be ignored and forgotten in time; contributing to a belief amongst people that have to use the systems / processes that a project leaves behind that the term ‘Phase 2’ is a project management joke.

4. Escalate
Successful (or more accurately: ‘successfully perceived’) project management often comes down to deciding when to buffer (if you pass on every problem without resolution, a client can legitimately ask ‘what am I paying you for?’) and when to escalate. These are my tips for escalation:

a)    Provide the background to a problem, to ensure the client is well-briefed. Few project managers will survive the fallout from a client appearing ill-informed about a major issue on their watch;
b)    Articulate the steps you and the team have been through to solve the problem;
c)    Recommend a course of action – ideally the thinking you’ve done will mean that this fits in the context of the project and the wider organisation;
d)    Be prepared for the client rejecting your plan – it pays to have a fall-back position. This is usually when your earlier whiteboarding session proves its value.

Some problems are not resolvable. In these cases it pays to figure out the root cause and make sure that you learn the lessons the project is teaching you.

@anthony__lewis

I’ve read two books recently that made reflect on practicality (and my family), and the role of failure in forming experience. As project managers we often use building analogies, and the books in question: How Buildings Learn, and To Engineer is Human – The Role of Failure in Success use building, as well as engineering case studies in figuring out why things fail, and how to avoid the same things in future.

Building collapses, plane crashes, and bridge failures (especially those that lead to injury or worse) demand rigorous investigation, but in projects where failure is less obvious – like the average software implementation, investigations are sometimes less than rigorous.

Neither book is recent, but the lessons are timeless. In How Buildings Learn, Stewart Brand talks about buildings that succeed (like modest practical buildings that can be adapted to changing uses), and those that have the appearance of success (such as I.M. Pei’s shiny MediaLab building at MIT, which is – according to Brand – restrictive, difficult to maintain, and which prevents the casual exchange of ideas on which great progress depends).

I’m a believer in platforms and frameworks, whether that’s a platform like eBay, Twitter, and so on where users invent new features that are adopted by the platform as they grow, or frameworks like MSP (Managing Successful Programmes – a flexible, practical approach to help practitioners avoid the mistakes of their forebears).

Platforms are more successful over time than prescriptive processes because no matter how thorough the design process, how sound our thinking, we cannot anticipate every way that people will use the systems we build. We cannot design for every edge case and still deliver to time and budget, so we should design for flexibility that can respond to use in the real world. The legendary management thinker Peter Drucker summed it up in 1985 in the seminal Innovation and Entrepreneurship:

A new venture needs to build in systematic practices to remind itself that its product or service is defined by the customer, not the producer. It needs to constantly challenge itself on the utility and value that its products or services contribute to its customers.

I often seem to read that if we’re not making mistakes we’re not learning, and its true that doing new things (even if they’re only new to an individual or organisation) usually involves more mistakes than is comfortable, but if we’re serious about succeeding – however we define success – we can learn the lessons of others’ mistakes, by reading about them, and learning from them.

If you’re interested in learning the lessons of project success (and failure), reading How Buildings Learn, and To Engineer is Human is a good start.

‘When you first start off trying to solve a problem, the first solutions you come up with are very complex, and most people stop there. But if you keep going, and live with the problem and peel more layers of the onion off, you can oftentimes arrive at some very elegant and simple solutions. Most people just don’t put in the time or energy to get there.’

When I’m working on the interaction design of corporate systems for clients, I’m almost always briefed that the design ‘must be simple’, and I’ve been thinking about what that means.

In the wonderful Simple and Usable, Giles Colborne describes four methods of simplifying, using a TV remote control redesign as an example project:

• Remove – get rid of all unnecessary buttons until the device is stripped back to its essentials
• Organize – arrange the buttons into groups that make more sense
• Hide – hide all but the most important buttons…so that they don’t distract the user
• Displace – create a very simple remote control…and control the rest via a menu on the TV screen

These are steps in the journey towards simplicity, but if they’re used on their own, then they’re only impacting the surface of a design without addressing the fundamental purpose of the interface, or the needs of the user. In his book Simplicity, Edward de Bono makes the distinction between Simple (focusing on the core of a problem) and Simplistic (removing complexity), and to me this beautifully summarises a point that I made much more clumsily a while ago.

A lot of people seem to have a hard time thinking through a problem – it’s easier just to cut and paste solutions we’re familiar with, or take stuff away until we have a solution that looks simple. With the first approach we might be solving a different problem or ‘fighting the last war’, with the second approach; despite its simplicity, we might be obscuring the job to be done. If a user cannot see how to perform their task, they are more likely to abandon or circumvent the process we’ve designed.

The world is complex, as are so are many of the problems that we need to solve, and the key to solving them is applied thought. The Feynman Problem-Solving Algorithm, supposedly coined in jest by another Nobel Prize-winning physicist, Murray Gell-Mann, described legendary physicist Richard Feynman‘s innate problem-solving ability:

1. Write down the problem.
2. Think very hard.
3. Write down the answer.

Gell-Mann was apparently being facetious, but with the addition of a couple more loops, the Feynman Algorithm describes the key steps:

Simplicity is subjective, contextual, and difficult to test – this makes it a poor input variable.
Rigorous thought, and focus on the problem we’re trying to solve will give us a fighting chance of arriving at the most useful solution within the context of the problem.
From the user’s perspective, the most useful solution is often the simplest, and we’ll find that the people who use our designs will say ‘oh, that’s really simple’ – bringing to mind Mark Twain’s quip on the effort it takes to give the appearance of simplicity to the reader:

‘I didn’t have time to write a short letter, so I wrote a long one instead.’

Simplicity isn’t an input of the design process – it’s an outcome of a applied thinking.

@anthony__lewis