Neville Kuyt's blog

Running a meeting is an art form. I don’t know anyone who actively enjoys meetings, and I often find myself in meetings which feel like a waste of time. But I’ve also been able to turn projects around just by running a few good meetings. Because meetings are social rituals, and we primates thrive on social rituals.

Purpose

Firstly – define very clearly what the purpose of the meeting is, and whether a meeting really is the best way to achieve that purpose. Usually, a meeting is not a great way to explore new opportunities, solve problems, or even reach decisions. Workshops or other collaborative frameworks are much more efficient – the format invites much more interaction, and they are much better suited to situations where both the process and outcome could change.

In find meetings best suited to situations where a group of people (who don’t normally work together) need to create a shared understanding and (perhaps) confirm decisions.
Another useful scenario is where one party holds information, and needs to broadcast that information to a group.
More generally, a meeting is useful where you can work through a predictable series of topics, and the discussion is limited to a few individuals (in a business setting, that is – I’ve seen meetings in political groups, creative consortia etc. which work well in a much looser setting).

It’s worth explicitly thinking about what a “successful” meeting outcome would be. For instance, “this meeting will have been a success if person X agrees to fund our next phase”, or, “this meeting will be successful if everyone understands and agrees that the situation is x“.

Attendance

Next, decide who should attend, what their interests are, and how they tend to act in meetings. Often, there will be one or two attendees who are key, and understanding their interaction patterns will be a big part of creating a successful meeting. Sometimes, these are the most senior people who attend, but those senior people will often base their opinion on a trusted advisor.
I once stepped into a project that was seriously behind the planned milestones, and looked like it was going to exceed budget. We organised a meeting with the customer to agree next steps; the decision maker was a director-level executive. We knew that he was generally confused and angry about the project, but trusted a programme director to advise on next steps. The programme director, in turn, trusted her two technical and delivery leads. To make the meeting a succcess, we had to get all 4 on side – not just the director.

Once you’ve identified the key influencers in the meeting, it’s worth thinking about their communication style. I know there are lots of personality type theories; for this purpose, I have a simple 2-dimensional model.

Big picture

Some people – including many senior folk – prefer to understand the big picture first, before diving into the detail. In my experience, most senior executives fall into this category. It’s not that they don’t value the detail, but they are interested in the “so what”. They are likely to lose interest unless you phrase the conversation in terms of “big picture” concerns, and they may appear unpredictable as a result.

As a result, it’s worth structuring your agenda topics “top down”: the agenda item should be the conclusion or the question. The conversation should go from conclusion to no more than 3 “because”, “despite”, “as a result of” points; each of those points can then be built up in more detail.

Consider the following hypothetical situation: you want to communicate the likelihood your project is going to overrun, due to a new regulatory requirement.

Your agenda item might be: Project likely to overrun by 5 weeks.
Once you reach that agenda point, you might start with the following:
“The project is likely to overrun by 5 weeks. This is because the government has changed the regulatory requirements. The project is other wise on track; we have looked at ways to mitigate the regulation changes but cannot find a credible option.”
Someone who cares about the big picture can now decide whether to pay attention to the rest of this topic, because you’ve told them up front what’s happening and why.
The trap many people fall into is have an agenda topic along the lines of “Regulatory changes”, and to start that conversation with a detailed outline of the legal requirements before reaching the impact on the project. To someone who cares about the big picture, by the time you reach the “so what” (the project will be delayed), they’ve switched off.

Detail-oriented

At the other end of the spectrum there are people who are focused on the detail, and prefer to build up their understanding “bottom up”. Meetings are usually not great places for exploring a lot of detail, but often the real substance of an issue can be found in complex, subtle details.

One great way to include details in a meeting is to use visualizations. For project progress, burndown/burnup charts, or defect counts, or progress towards milestones can show a lot of information, covering a lot of detail, without needing to discuss every item. I typically find the right level of abstraction to be: what does the most senior person care about, plus one level of detail below that.
For instance, on the project that was at risk, the senior stakeholder cared about “when will it be finished, how much will it cost, and how many agreed features will be missing?”. So we drew up a chart that showed “features delivered”, “features remaining” and “bugs” over time. We accepted (and agreed with the hands-on client team) that some of those numbers were very approximate, but good enough to show the overall trend. We used that graph in our ongoing meetings as the common “now we talk about detail” agenda item.

Substance

Next, we talk about decision making and emphasis. Some people focus very heavily on the substance. When buying a car, they’ll focus on the measurable, tangible qualities of the car (rather than the trustworthiness of the sales person). When talking about a meal at a restaurant, they might discuss the quality of the ingredients, the skill in preparation, or describe the decor (rather than how the meal tasted, or how it felt to be in that restaurant).

When running meetings with people who focus on substance, it helps to stay focused on tangible, and ideally measurable, facts. They will often see success as “the thing we agreed to do has been done”, or “we have 5 things to do and everyone knows what they are”.

Relationship

I’ve struggled to find a better word than “relationship” here – but people who focus on the relationship aspect will use meetings to assess the interactions between people, their confidence levels. They may consider a meeting successful if people formed a better relationship during the meeting. At a more challenging level, they may also judge meetings by the way they personally are treated, and if they feel personally slighted, they will consider the meeting a failure no matter what the outcome.
I once attended a meeting with a very senior colleague who was focused on relationships. It went extremely well – we achieved all the aims we had set out to, and got approval for a large project. My colleague, however, told me in the taxi back that we couldn’t work with those people, that they were not good partners and that we should back out – because he hadn’t been offered a cup of coffee at the start of the meeting.
Annoyingly, he was right – the project never got off the ground…

Combinations!

It’s a very simple model, but by trying to place people on the “big picture/detail” and “substance/relationship” axes, you can prepare your meeting in a way that will appeal to the key stakeholders.

The point of the diagram above, though is to show that most people have preferences along both axes. Most senior executives I’ve met are “big picture” people, and a large number have a preference for “relationships”.

In structuring a meeting for someone who values “big picture/relationships”, it’s important to remember you cannot persuade them with facts alone – you have to create relationships of trust. I do this by focusing on transparency – by being open and owning up to things that aren’t so great, I try to show that I’m a trustworthy person. I also make sure I remember what they care about, and make it a part of every encounter. One of my clients was very focused on relationships, and in one meeting he explained he had a strategic objective to move his hosting setup to a new cloud provider; even though that wasn’t part of our remit, I made sure to include a check-in on every agenda.

People who value “big picture/substance” are often intellectually demanding. It’s important to be on top of your material, and to have a clear structure to your agenda. One of my first jobs was in a management consulting firm, and my boss (or rather my boss’s boss’s boss) was a classic of this type. He was intellectually curious, and his “big picture” dramatically exceeded my own ability to imagine. My first meeting with him was chaos – he kept moving the goal posts, and kept asking questions until I ran out of answers, then moved to the next topic, usually far off the agenda.
I figured out how to run a good meeting with him – we’d start by explicitly agreeing on the purpose of the meeting, and then for each agenda item, we’d agree what we were trying to achieve. This kept the meetings on track.

Agenda

The agenda is actually the most important part of the meeting – it’s how you express what you are trying to achieve with the meeting, and it’s the main tool you have to keep things on track.

The exact format of the agenda isn’t super important – I’m quite fond of a presentation which can combine both the agenda and the information required for the discussion. I have settled on the following format:

• Introduction: date, place, meeting name, start time, end time
• Attendees: names and contact details for all attendees
• Meeting purpose: a brief summary of the purpose for the meeting
• Topic 1: subject, allotted time, topic type (presentation, discussion, confirmation), owner
• Topic 1 supporting information
• Topic 2…n
• Summary: restate meeting purpose to verify it was achieved. Next steps/actions.

It’s usually best to have the most engaging topics as early in the agenda as possible – demos, decisions, significant changes to plans, etc. This means people are less likely to have got distracted, or called out for other meetings.

Timeliness

Running a meeting to time is a real skill – but it really matters. When I worked in a management consulting firm, every meeting room had a clock on the wall; it wasn’t uncommon for someone to remark on the billable hours every meeting cost. For senior attendees, every minute of their day is booked, and your meeting is just one of the hundred other things they could be doing. So run meeting to schedule, and finish early if you possibly can.

That means that you should make sure every agenda item has an allotted time slot, and you should make sure no item exceeds their time slot. If you get to 10 minutes from the end of the meeting and you are worried you’re going over time, step in and do a time check; ask what the options are.

Actions

Finally – meetings nearly always have some kind of outcome – actions, follow-ups, or meeting notes. Get them out the same day, while the meeting is fresh in everyone’s mind.

A few days ago, I wrote about my experience delivering a large web project and compared it to the Hertz/Accenture law suit. A friend asked me to go into more detail – here’s the gist of our conversation.

X: isn’t there a risk that by delivering slices, you’ll introduce lots of duplication? If I want to implement a business rule saying “all orders must have a validated shipping address”, and I have two slices – “website user creates order” and “contact centre creates order”, won’t they duplicate that logic?

Sure – that’s a risk. You could well end up with a mess of duplicate code, especially if you have lots of teams working in parallel. There are broadly speaking two ways to mitigate this risk.

The most common is through “architecture” – you agree a software design where there is a single component which manages orders and their business rules. This is perfectly reasonable – but it often comes with some baggage. There is a temptation to design this architecture in great detail, and assign a team to each component. This often means that the component is designed up front, and cannot change in the light of real requirements that are uncovered during development. I’m all for architecture, and I’m all for cleanly defined components which do one thing and do it well. But I believe architecture should be lightweight and focus on principles and infrastructure, and the actual implementation should evolve along with the application.

The second way to avoid duplication is through process and culture – you make sure the teams communicate about their design decisions, and know how and where to look for existing code which is related to their work. You make sure the team has enough time to refactor and extend existing components, and that everybody understands that the team is evolving the architecture together.

X: What about multiple UIs? What if I want to build a platform that supports web, mobile apps, smart TVs, VR glasses?

Sure, another really important consideration. I’ve worked on projects with multiple brands, multiple markets, multiple devices – the possibility for lots of duplication is even bigger. The same answer applies as above, really – yes, a clean architecture is the answer, but no, designing that architecture up front and dedicating a team to the “re-usable” layer is often a bad idea. The user experience on those different devices is often very different, and it’s much better to evolve the re-usable layer as you learn about what you really need than trying to design it in detail up front.

X: And what about skills? Front-end developers want to work with other front-end developers, you get much better code if you have people work together on the same technology layer.

This is indeed a challenge – especially when you have skill requirements you can’t realistically embed in each “slice” team, or where you have particularly complex requirements in one part of the slice. But in my experience, once developers are used to working in cross-functional teams, they really enjoy it – they learn a lot from working with other disciplines. Some of the most useful code review sessions have come from front-end developers and back-end developers looking at each other’s code – they tend to spot mistaken assumptions, rather than stylistic problems.

I don’t think there’s a nice structural solution to this question – a neat org chart you can draw showing how teams work. I think the solution lies in culture, rather than structure – coding in the open, joint ownership, a shared understanding of “what the project is about”.

X: OK, but how big should a “slice” be?

Good question. As usual, it depends.

The key goal of “slices” is to make sure everyone – developers, business sponsors, QA, designers – has the same perspective on “what the project is”, and “how much is done”. So a slice needs to be demonstrable to business people, in a way that clearly communicates what works and what doesn’t. It needs to have a user interface (even if most of it is placeholder), and it needs to push logic all the way down the stack.

But it doesn’t need to scale, or be fast, or be pretty. It can have some technical debt, and it can cover only the “happy” path. It might only work for one of the different types of users, or one type of content, or one workflow.

X: I think I understand. What do I do after my first slice?

Another good question. I like to structure projects so that we build the first slice as quickly as possible (4 weeks or so is great); I typically ask the entire team to focus on this goal. Once the first slice is delivered, I like to add more slices every 2 weeks. At this point, it may make sense to have some of the team working on cross-cutting concerns (build/deployment, shared look & feel, etc.). It may also make sense to build larger components outside a slice – some things just take more than 2 weeks to deliver. However, I try to keep at least half the team working on the “slice”.

I wrote earlier about Hertz suing Accenture over the failed web replatforming. Again – I have no knowledge other than what I read in the press, and this is all conjecture.

There’s a line in the article that stood out for me. “Despite having missed the deadline by five months, with no completed elements and weighed down by buggy code,….“.

A few years ago, I picked up a large project – looks like it used the same technology stack (Adobe Experience Manager, Angular). The project had been running for a few months, and our client was unhappy – they couldn’t tell if we were making real progress. “Nev, can you have a look and see what’s going on?” asked my boss, so I went for lots of coffee with the team, and ended up taking over the delivery of the project.

The key red flag was this: the team had been working for around 6 months, but didn’t have anything they could show me other than some passing integration tests. We were building a website, but there were no actual web pages. There was some JSON that could be transformed into web pages, there was a content structure that could create and store JSON, but the only people who could assess progress were developers.

Our client was not a developer – they were subject matter specialists, product owners, business people. They understood the “first you have to build the foundations” logic of building the underlying structures before worrying about making web pages. But they felt that 6 months was a long time to wait, and they felt the team was unable to explain when they might see a working web page. They also felt there was a real risk that once we started making web pages, we’d have to revisit lots of “foundation” code. They were right, as it happens.

The first thing we did with the team was to create placeholder pages for the major parts of the site. AEM has the concept of “component” – a widget which shows a bit of a web page – and “template” which defines which components go on the page, and how they fit together. So, we started to build all the templates we needed, and placeholder components to go on those templates. We made sure that the templates and components reflected the key design decisions (how they’d render on different screen sizes, basic colour and styling), and created a basic version of the site.

This took a few weeks, and raised lots of questions. “Where does this content come from? How does this component work on mobile? How do you get from this page to the next?”. It was uncomfortable – we found out exactly how much we didn’t yet know. It also exposed assumptions we’d made in designing the “foundation” which were totally incorrect. We had uncomfortable conversations with the client – as we found answers to our questions, we discovered many areas where we weren’t aligned on requirements. Some of those misalignments reflected significant amounts of effort.

But overall, the trust between our team and our client improved. The conversations were concrete and limited – instead of asking “how should content workflow be set up?”, we could ask “how do we manage content for this widget on the homepage?”. Many of our assumptions were tangible – “we thought the navigation would be a static component, you think it’s data-driven”. By focusing teams on a component (front-end, back-end, design, QA), we could demonstrate that we could make progress in ways our client understood. We’d agree how a component was supposed to look, how it worked, where the content came from, and then assigned a team to deliver that. Within days, the client would see progress, and their level of confidence would grow.

I refer to this as the “layers versus slices” challenge. Logically, it makes sense to build the foundation before you worry about hanging pictures on the wall – but I think there’s a better metaphor than building a house. I see it more like building a city – you want to put down major infrastructure like roads, sewage, utilities first, but then you build each house individually – foundation, walls, roof, interior. You can build several houses concurrently, but you don’t build the foundations of all the houses in the city first, then the walls, then the roof etc. (I may have been playing Sim City).

On a web project, the infrastructure is setting up development environments (a huge pain on AEM!), basic content repository structure (how do you manage sub-sites, language variants etc.), deployment pipelines, BDD/TDD testing framework, design system (e.g. material design) with default styling for the project, and the source code control system.

Once you have the infrastructure layer, I build the user interface, using the basic design system (which may look more like “boxes and arrows” style wireframes than the finished product), and minimum versions of all the components. This should give you a web site with placeholder content, and minimal styling. You now have two layers – infrastructure and user interface.

The next phase is to focus on slices – build up all the components so they work properly (however you’ve defined that!), look right, and have the correct content.

I may be reading too much into the line in the article – but it sounds to me like the Hertz project focused on “layers”, at the expense of “slices”.

I’ve been working on software projects for a living for 30 years. In 1989, I worked on a COBOL application which managed orders, production schedules, billing and payroll for a manufacturing company. Then I worked on a client-server project for professional service automation; next came a range of web projects, along with mobile, video, and VR/AR, and data applications.

The overwhelming trend over that time is that the proportion of effort expended on domain-specific code has increased dramatically, and the cost of infrastructure capital investment has mostly been replaced by pay-as-go cost.

The latest phenomenon that’s about to break through into the mainstream is serverless. The definition is a little bit open to interpretation, but this is probably the best I’ve seen.
The concept is broken down into two parts: “Backend as a Service” (BaaS) provides functionality to applications on a per-use basis – it’s a little hard to say exactly where the boundaries lie, but in principle the commercial trade off is “do I invest effort building feature x, or do I pay on a per-use basis?”.
The second type is “Function as a Service” (FaaS) – developers write code, and the service provider runs it in the location determined by the commercial arrangement. Here the commercial trade-off is “do I invest in a hosting platform (which could be Cloud), which I manage myself, or do I pay a tiny amount every time the code runs, and let someone else sort out the hosting platform?”.

So why is that mostly about money?

Firstly, it (theoretically) reduces the cost of building solutions – you don’t have to worry about scaling, or availability, or anti virus, or back ups, or configuring the run-time for your application just so. More of the effort goes into the unique, special thing your solution does, rather than the plumbing that keeps it up and running.
This is an ongoing trend, and – arguably – the biggest savings came much earlier, with Cloud, containerization and Platform as a Service.

Secondly, you pay for what you use at a feature level, not infrastructure level. In most Cloud/PaaS models, you pay for running a process, whether it’s busy or not, and it is your job to figure out how many processes you need. In serverless designs, you only pay for running the feature you care about.
This is a big deal – it reduces the fixed costs for building solutions even further. This changes the commercial model – the more cost you can move from “fixed and upfront” to “scales with use”, the easier it is to create a business case that works.

That’s because most organisations look at “return on investment” as a key metric for deciding whether a project will go ahead. They typically look for an RoI as a multiple – “every pound we invest will pay back x pounds over y years”. So, every pound you can shave off the upfront cost makes that return on investment calculation easier. This, in turn, makes more projects commercially viable.