This lizandmollie post really speaks to me. Title and pay are only part of the story…and reality is a small part. Might only be applicable when you reach a certain salary and could argue that “a good team” is another slice of the pie.
Great flowchart that John Cutler shared on twitter on strategy and structure.
Great check to make when building or refreshing a strategy.
Charlie Kindel – how to achieve focus in any endeavor you embark on by simply writing down the Purpose, Principles, Priorities, People, and Plan (the 5Ps). An endeavor could be a software development project, a job search, or a phase in your life. I have personally found the 5Ps a useful tool for small projects (e.g. prepping for a VC demo/presentation) as well as large scale projects that include 1,000s of people.
- Purpose: Why do we exist? Why are we in business? Where do we want to be in the future? What will we deliver?
- Principles: What are the non-negotiable rules and key strategies? How will we act?
- Priorities: What’s the framework for tradeoffs? In what order do you do things? How much mass or energy do you apply to each element of the plan? What is not important?
- Plan: How are we going to stage and tackle solving the problems? What are the known dates & forcing functions on the calendar?
- People: Who’s accountable for every key part of the plan?
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.Melvin Conway
Conway’s law was not intended as a joke or a Zen koan, but as a valid sociological observation. It is a consequence of the fact that two software modules A and B cannot interface correctly with each other unless the designer and implementer of A communicates with the designer and implementer of B. Thus the interface structure of a software system necessarily will show a congruence with the social structure of the organization that produced it.
Easily observed in organisations today Conway’s law still has merit and should be considered when designing software or reviewing organisational design.
Why being imaginative is stifled within most businesses. A great chart from
@rorysutherland describing the consequences of different modes of decision making, whether things go right or wrong.
There’s no such thing as shadow IT; there’s just business change you’re involved in, and business change that you’re not involved in.https://twitter.com/EnterprisingA/status/1038099506108227584 https://twitter.com/_tony_richards/status/1206479464026320896
Have you ever found yourself saying things like:
- Why are enterprises so slow?
- How do they decide what to buy?
- Why is it so hard to deliver things in an enterprise?
I worked for a large ‘enterprise’ organisation for a few years trying to deliver infrastructure software change, and found myself having to explain these things to developers who worked there, salespeople, external open source engineers, software engineers who worked for enterprise vendors, and even many, many people within that organisation.
A few of those people suggested I write these explanations up so that they could pass it on to their fellow salespeople/engineers etc..
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.