Meetings can be fantastic or terrible. I’ve experienced some serious pros run meetings, and when they do, everyone feels great afterwards. Everyone feels like progress was made, that things are clearer than before, that there is continued momentum.
(This is a note I sent to my team of Product Managers, Designers and Researchers at Intercom)
Meetings are expensive. Consider the opportunity cost of people being at a meeting – they could all be doing other important things. Treat other people’s calendars as a scarce resource and know that an empty calendar is an awesome place to be in because you are free to do your own work.
I consider any structured conversation between two or more people as a meeting. Today, at Intercom, we don’t do a great job of running meetings. We’re neither terrible or fantastic, but I want us to get way better. This is simply a process problem; it is entirely within our control. There are clear best practices in running great meetings. This is mostly a solved problem.
This is how we should be running meetings and you should hold your colleagues accountable to this standard.
Meetings must have one owner
This person runs the meeting.
They are responsible for the attendees staying on topic.
They are responsible for ensuring the meeting starts on time.
They are responsible for ensuring the meeting is on track, in the time remaining, to accomplish the goals set out at the start.
If you walk into a meeting and it isn’t clear who the owner is, feel free to leave and go do something more valuable for the company.
Meetings start by sharing the required output
The meeting owner starts the meeting by saying what the goal of the meeting is. For example, “We need a decision on whether to pursue option A or option B”.
The meeting owner clearly defines the boundaries of the topic. For example, “We don’t want UI feedback today. We need to only discuss concept design so we can decide between option A or option B”.
Meetings end with very clear action items, each of which has one owner and a due date
As a meeting progresses, the meeting owner collects and writes down any decisions made, action items, owners and due dates.
The last act of the meeting is for the meeting owner to read out the decisions made, and the action items and owners. This is to ensure nothing has been misunderstood.
The meeting owner must then email the list of decisions and action items to all meeting attendees to really ensure nothing has been misunderstood, and to ensure we have accountability.
If the due date is not going to be met, it is the responsibility of the action item owner to let others know.
Other best practices
If a meeting concludes before the time allotted, end the meeting and leave! Don’t try to fill the time with other random top of mind topics.
If you are in a meeting and feel you don’t need to be there, let people know, and unless anyone wants you to stay, then get up and leave. No-one is going to be offended.
Feel empowered to decline meetings that you don’t think you should be at, or don’t know what they are for. Don’t ever just show up to a meeting without knowing what it is going to be about.
Meetings should never be the reason a decision is unnecessarily delayed. Don’t wait for a meeting when a decision is needed. If you need feedback or help, make that happen before some standing meeting.
Finally, your time is precious and expensive; ensure good meetings are being run. Your colleagues owe you that, and everyone wins.
Horns, horses and wings exist.
Unicorns do not.
Just because you can talk about “proactive infrastructure”, a “dynamically configurable platform”, or “contextually aware flow routing”, doesn’t mean they exist.
There are a lot of folk out there selling Unicorn architectures.
Learn to subject proposed architectures to common-sense, plain-English reality checks.
Every leader and company knows the WHAT. They can describe their products, their industry, and their competitors. Some companies also know HOW they do WHAT they do — their unique differentiators, their value proposition, and their values. But few companies know or articulate their WHY — their purpose, their cause or their belief. The WHY is their reason for being. And the WHY is why anyone should care.
Since the WHAT is the easiest to know and articulate, most leaders and companies start with WHAT. Sometimes they will also discuss HOW, but they rarely talk about WHY. With respect to the Golden Circle, they go outside-in.
Simon advocates that we should invert the order. Go from the inside-out in the Golden Circle. Start with WHY, discuss the HOW, and end with WHAT.
As Simon writes:
“When most organizations or people think, act or communicate they do so from the outside in, from WHAT to WHY. And for good reason — they go from clearest thing to the fuzziest thing. We say WHAT we do, we sometimes say HOW we do it, but we rarely say WHY we do WHAT we do.”
“When communicating from the inside out, however, the WHY is offered as the reason to buy and the WHATs serve as the tangible proof of that belief.”
Enterprise Architecture is still an emerging field. There are not many organizations today that are effectively measuring their EA program with metrics. Here are a few metrics that might work:
IT Total Cost of Ownership (TCO) as a Percentage of Revenue
One of EA’s value propositions is reducing costs by leveraging common solutions and rationalizing processes, technology and data.
This metric is key to the business value achieved by the IT stack. It has appeal to business stakeholders and allows IT costs to be compared with industry or regional averages.
Example: The total cost of ownership of IT is 4.8% of revenue.
Total Cost Savings (TCS)
Often EA is able to achieve cost savings by:
- retiring a legacy system
- consolidating licensing
- introducing common shared services
- rationalizing infrastructure investment
If the EA team can deliver cost savings on a regular basis — Total Cost Savings is a meaningful metric for EA.
Example: EA initiatives saved the organization 5.2 million dollars this quarter.
Percentage Of Spend That’s Strategic (PSTS)
The EA team assesses all projects and designates them as tactical or strategic. The percentage of the total IT spend that was considered strategic can then be calculated using project budget information.
PSTS is a good predictor of the long term heath and efficiency of IT. However, it may be of little interest to the business.
Example: 47% of project spending went to strategic projects this quarter.
Common Services Compliance Rate (CSCR)
Enterprise Architecture often defines common services such as ESB, BPM, Infrastructure platforms etc… The CSCR measures the percentage of new projects that are fully compliant with the common service roadmap.
Example: 67% of projects complied with EA’s common service strategy this year.
Architectural Due Diligence Rate (ADDR)
The percentage of projects that are fully compliant with the EA governance 2 process. A EA governance process involves steps such as updating EA blueprints, architectural reviews and macro design.
ADDR is a good metric for reporting violations of the EA process. It is often helpful to report ADDR by business unit, technology silo or project manager — to highlight problem areas.
Example: 78% of operations department projects complied with EA governance but only 12% of sales department projects were in compliance.
Sunset Technology (ST)
Percentage of the technology stack that is considered sunset by EA. Measures IT’s ability to introduce strategic technology and retire legacy systems.
Example: At the end of the year 54% of production systems were deemed sunset technologies. This compares with 62% last year.
Manage EA with specific metrics aligned with your business strategy and goals. Examples include:
- reducing time to market for launching new products
- reducing human error rates
- speeding up order delivery
- reducing IT costs
- reducing severity and frequency of security incidents
Example: average time to market for introducing a new product decreased from 5.8 months last year to 4.9 months this year.
Significant and measurable business goals that require EA support make good EA metrics.
There are 3 fundamental ways to measure the performance of your EA team:
1. Measure IT
IT metrics are well established — ROI, Total Cost of Ownership, Mean Time to Repair (MTTR) etc..
Such IT metrics are SMART and appeal to the business. They are good measures for IT — but do they translate to EA?
In theory the EA team should be able to increase ROI for IT, reduce Total Cost of Ownership etc… However, there are many factors affecting these measures. The correlation between EA performance and IT metrics may be low.
2. Measure EA Governance
It is relatively easy to measure the success of IT governance. What percentage of projects complied with governance? What percentage of projects were rejected? The problem with these metrics is that they lack appeal for the business.
It is not obvious how governance metrics translate into competitive advantage, customer experience or cost savings.
3. Measure EA Itself
Measuring EA directly is the ideal way to score the EA team. The problem is it is tricky to develop such metrics. The EA team collaborates with business, solution and governance teams.
The fact is that it is difficult to assign a number to collaborative long term planning activities such as EA.
Enterprise Architecture quite simply is all about Strategic Planning. It helps enterprises shape their future structure and dynamics in the face of the changing environment in which they do business. Its purpose is to understand the ends and means that form the strategies needed.
How does an enterprise react to events that do and will potentially occur and arrive at the strategies needed to remain robust, efficient and viable, to continue to deliver value and make profits for themselves?
Enterprise Architecture is the corporate discipline that helps us to understand the questions that need to be asked and get better at strategic thinking. The approach is based on asking the usual Why, What, How, When, Who and Where questions:
- Why does the enterprise need to change?
- What are the drivers for change?
- Are the drivers fully understood?
- What is the mission and purpose of the enterprise?
- What do enterprises need to do and need to understand? What do their customers and stakeholders want?
- What is possible to do?
- What are the strategies, goals and objectives?
- How will these be achieved?
- What business capabilities are needed?
- When should the enterprise react to new opportunities? What are the potential business scenarios that might occur? How will the enterprise react when they do occur? And how should it react?
- Who should be involved?
- Where is the enterprise?
- What environment or markets is it located in?
- How many different environments are there?
- What would success look like for strategic planning?
These should all be open questions. You should take care that the questions don’t upset those executives that are responsible for the current answers and are asked in an ego-less fashion.
All of these answers can be modelled and analysed with your favourite enterprise architecture tool. I like to add a Strategy domain to the usual Business Architecture, Information Architecture, Application Architecture and Infrastructure Architecture domains.
Enterprise Architects should start to think like a strategist instead of just like a technologist.
Prototyping to learn
The team started by quickly building a prototype wall using index cards with mail-merge stickers on them describing each procurement project. This information had previously lived in a spreadsheet. With the work quickly thrown up onto a wall, they asked themselves the question: “What is this wall not telling me?”.
Answer: a lot! There were so many cards it was hard to see what was going on. They were hard to read. And the wall couldn’t tell the team anything about cycle time: how long was each project taking to go through the whole procurement process?
Additionally, one of the team members had a visual disability, so the team wanted something with high contrast and large lettering. This was going to be hard to achieve with cards, given the number of procurement projects which were in flight at any time.
With this learning, the team built a second board, this time from Lego.
Ask 7 simple questions
Gather the team and your subject experts (e.g. ops, legal, security, policy, HR) and ask them these questions*:
- What are we trying to prove or learn?
- Who are the users?
- What are we operating?
- What are we saying?
- What are our assumptions?
- What are the dependencies?
- What capabilities do we need?
A timeline is not dirty
The Waterfall methodologists feel comfortable with long timelines. They typically work ‘right-to-left’ from a desired delivery date; the agilists prefer to work iteratively, ‘left-to-right’ as much as, and where possible. Whatever your preference, timelines are important and an inescapable part of delivering. A timeline is not a dirty concept.
I start this conversation by sticking post-its across the top of a wall with time intervals running left to right. I use 3 or 6 monthly intervals over 1 or 2 years, but whatever is right for you. Choose a timeframe that creates some discomfort for your colleagues to think beyond the immediate “deadline” in everyone’s head and to get them to think strategically.
Place known, real or imagined, time constraints and events across the top too, maybe on a smaller or more muted colour post-it so they don’t become the only focus of conversation.