Introduction

High-quality software demands high-quality management.

That's the subject of Quality Software Management, a four-volume series from the early 1990s that grew out of Gerald M. "Jerry" Weinberg's forty-year love affair with computers and his work helping software organizations improve.

He was a computer scientist, author, organizational consultant, and teacher of the psychology and anthropology of software development. Together with his wife, Dani, a professor of anthropology (the study of the physical, biological, and cultural aspects of humanity) he explored how people, culture, psychology, communication, and organizations influence software engineering. They later designed the Problem Solving Leadership (PSL) workshop which aimed to teach leaders the ability to think and act more creatively in complex situations.

In Volume 1, Systems Thinking, Weinberg tackles the first requirement for developing quality software: learning to think correctly about problems, solutions, and quality itself. Managers need to serve as both planners and catalysts within the organization. They need to continually plan what to do, observe what happens, and then act decisively to bring the actual closer to the planned.

In Volume 2, First-order measurement, Weinberg tackles how to observe properly. Many of the failures to manage software engineering are caused by poor observation. They really don't know what's going on in their organization. Managers must have reliable information, obtained through careful observation and measurement. The book also defines different levels of measurement, and describes the minimum set of activities in order to start a measurement program.

In Volume 3, Congruent Action, Weinberg tackles how to act congruently. That is, managers must not only understand the concept of good software engineering, but also practice them. Effective managers need to know what to do, say what they will do, and then act accordingly. Their thoughts and feelings need to match their words and behaviors. Managers themselves must take responsibility for upgrading the quality of management and for changing their own attitudes and thinking patterns before they try to impose changes on everyone else.

In Volume 4, Anticipating change, Weinberg tackles how to create a supportive environment for software engineering - an environment in which your organization can realize long-lasting gains in quality and productivity by learning how to manage change. Many managers spend their money on tools, methodologies, outsourcing, training, application packages, and what have you, but they rarely spend anything to improve or to remove the management that created those situations in the first place.

I was surprised by how relevant his experience and wisdom from the 1950s, 1960s, 1970s, and 1980s still are for today's software organizations. The technologies have changed, but not the underlying problems and patterns. This article is my personal key takeaway from the four books. I have also mixed in some personal experiences, together with ideas from other sources like Peter Senge's The Fifth Discipline and articles by Tom Geraghty, an organizational ecologist who looks at organizations the same way he was first trained to look at living systems - as complex, adaptive, and impossible to mechanistically control.

My focus here is on Weinberg's approach to steering organizations through feedback control and principles from cybernetics.

What you must have in place to steer your organization

Management's job is to steer a process that produces a desired product, service, or portfolio of products. In simple terms, it's about producing things of value to some people.

Cybernetics is the science of steering, the science of getting a process to go the way you want it to go, even in a world that's not perfect. If we borrow from the field of cybernetics, managers can be seen as controllers of feedback systems. A controller steers a system based on information about what the system is currently doing. Comparing this information with what is planned for the system, the controller takes actions designed to bring the system's behavior closer to plan.

Managers certainly are controllers, but they are not the only controllers. In any real project and organization, there are controllers at every level and everyone is acting as a controller some of the time over some of the work.

A system has inputs and outputs. For an organization that develops and maintains software, the outputs are the software itself, plus "other outputs", which may include all sort of things that are not the direct goal of the organization, such as:

• Increased competence.
• Stronger or weaker teams.
• Stress or happiness.
• Anger towards management.
• Respect for management.
• Trust or distrust.
• Personnel appraisals.
• Failure reports.
• Dependencies between teams.

Most software development methods, if they use feedback at all, focus mainly on the software itself and the state of the product being developed. The "other outputs", however, often give managers much more information about the health of the organization producing the software than the software itself, but my experience is that this is not something one is aware of or trained to notice and understand.

The inputs to the system are of three main types:

• Requirements.
• Resources.
• Randomness.

Requirements should be understood broadly. It includes needs, desires, jobs to be done, problems to solve, and technical and functional requirements. Requirements come from many places, some of which are official. Many other requirements simply leak into the process through conversations, influence, pressure, and expectations. Resources include the human, financial, technical, and organizational support available to help accomplish the desired results.

Randomness is the uncontrolled inputs, those external things that the controller cannot totally predict or control. For example:

• A key person becomes unexpectedly unavailable.
• A relationship between two or more people gets worse.
• A customer suddenly changes priority.
• A business unit is reorganized.
• A security vulnerability is discovered.
• A vendor changes its product or pricing.
• Market conditions change.
• New internal or external regulations.
• A cyberattack.

You can't fully eliminate or prevent all this through more planning and governance. The question is how much you can tackle without losing control. How much buffer do you have against randomness?

The behavior of your organization depends on both its input and its current state. That means steering depends on not only what you put in, such as requirements and resources, but also on what's happening inside the organization right now. Only when you understand the current state of your organization can you make sensible interventions.

My experience is that this is where things often start to break down. There is no shortage of requirements or resources, but you can't steer if you don't understand the current state of the organization. Observing the current state sounds simple, but it is actually extremely complex because it involves understanding what goes on inside another person's head, as well as inside your own. The technology of human behavior is many times more complex than the technology of software. Compared to you and me, an operating system is piece of trivia.

All large organizations spend a lot of time and effort trying to understand themselves through employee surveys, pulse surveys, benchmarks, maturity models and more. But the challenge is that the dashboards, reports, and metrics are not the full picture. Many leaders will still admit that they don't feel like they know enough. Many of the things that matter most in an organization are also the things hardest to measure directly, things like alignment, trust, psychological safety, competence, ambition, and organizational slack or reserve capacity.

This means that if you want to steer your organization effectively, four things must be in place:

1. A desired state. You need an idea of what you want to happen or what you want to produce. Many organizations fail because they never become clear about what kind of product is desired or what are the results they are trying to achieve.
2. The ability to observe the current state. You need to observe what is happening and have an understanding of what those observations mean.
3. The ability to compare the two. You need to compare and identify the gap between the current state and the desired state.
4. The ability to take action. You need to be able to design and take actions that move the organization closer to the desired.

A big part of the manager's job is making sure all four parts are present, because if any is missing, the feedback loops break down and you lose your ability to steer effectively. If you are trying to help an organization in trouble, look for which of these parts is missing. No matter how clever a manager might be, the feedback model says you can't successfully control anything for very long without reliable information about what is actually happening.

Another way of saying the same thing is:

• Your organization can fail when there is no plan for what should happen.
• Your organization can fail when the manager doesn’t see what is really happening.
• Your organization can fail when the manager fails to compare what’s happening with what they want to happen.
• Your organization can fail when the manager cannot or will not take action to bring the actual closer to the planned.

Mental models

As mentioned, if a manager wants to keep projects and deliveries from going sideways, they need an accurate and timely observation of what's happening right now. But the manager must also understand what those observations mean. Has something failed? If so, why? When there is a click from the engine of your car, the information is accurate and timely, but what does it mean? Both you and the mechanic observe the same thing and have the same information. Only the mechanic, however, understands how the engine works and can attach appropriate meaning to the sound. Without the meaning of the click, you don't know the right action to take.

We all operate through mental models - simplified explanations of how things work. A mental model consists of assumptions and beliefs and they are critical because they shape what we see, what we choose to ignore, and what we miss entirely. The way people behave is not based on reality, but on their models of reality.

So as a manager you have a set of mental "boxes" that help you sort everything you see, hear, and notice. One of those boxes may be labelled "not worth noticing." In many bureaucracies, "not worth noticing" can be translated into "not in my department", or "not my job." What goes into the "not worth noticing" box decides more than anything else your success or failure as a manager.

If you are leading a software organization, for example, you need mental models that help you understand how software engineering and software organizations actually work. You need them to know what's important to pay attention to, and how you respond to what you observe. Without it you may observe a project failing, but don't realize that's what you are observing.

In a computer, you can simply erase the memory and load a new software, but people's brains don't work that way. Everything you have ever known is stored somewhere in your brain, so you can never eliminate mental models, you can only add to them. Therefore, the best way to reduce ineffective behavior is by adding more effective behavior. As you develop better mental models, you start using them more and more, and this simply leaves less opportunity for the ineffective ones to be used.

Here are some examples of assumptions and beliefs that can be found in software organizations:

• Engineers will do what I tell them to do.
• Most software projects go sideways because of lack of calendar time.
• If I'm behind schedule, I can add more people to make things go faster.
• The more pressure, the faster they will work.
• That can't be tested.
• Managers should understand software development.
• Managers shouldn't understand software development.
• We will give you a replacement for X with the same background.
• We will assign half (or any fraction) of a person to that.
• Moving people between teams has little cost.
• People are interchangeable resources.
• Large systems are like small systems, just bigger.
• Twice as big a system will take twice as long, unless we use twice the people.
• Governance is followed and understood in the same way everywhere.
• More governance means more control and less risk.
• Software development is a sequential process.
• The more detailed the plan, the more predictable the result.
• The more requirements we capture, the more complete our understanding becomes.
• A change to the plan means failed planning.
• Once the planning is done, the right actions will follow.
• Individuals, not teams, are our smallest unit of value creation.
• If we get a month's worth of code from Sofie and a month's code from Steinar, we now have 2 months' worth of code.
• That can't be measured.
• If I can measure it, I can control it.
• If I can't measure it, it's not important.
• Everything can and must be measured.
• The purpose of measurement is to exercise control.
• Numbers are less biased than people.
• A dashboard showing a green indicator means we are doing well.
• I know what's going on.
• With enough data, the future is predictable and plannable.
• Good performance means hitting budgets.
• An estimate is a commitment.
• Without absolute and numerical targets, people will not know what to do.
• Without absolute and numerical targets, people will not be motivated to perform.
• Without absolute and numerical targets, management will not be able to evaluate performance.
• The earlier and more detailed we allocate resources, the more predictable and controllable things become.
• High utilization means high value creation.
• There will be no mistakes.
• If mistakes happen, they will be small and the people involved will certainly know how to fix them.
• People and organizations behave logically, meaning that everyone will undoubtedly recognize the beauty of the proposal and immediately accept the proposed change with great admiration.
• Perceptions and desires remain fixed throughout the entire process.
• Thinking is a luxury we can no longer afford.
• We can save time for testing by cutting out technical reviews.
• The customers will like it however we build it. What do they know, and besides, what choice will they have?
• My project is unique and have little or nothing to learn from earlier projects.
• Our responsibility ends when the project is delivered.
• People know what they need.
• Leaders should remove uncertainty for their organization.

You may agree or disagree with each of these beliefs, but that isn't the point. When these mental models remain hidden, it's difficult to discuss them. And if they can't be discussed, they can't be tested and improved. And if they can't be improved, you become stuck in your current cultural pattern. Over time, the gap between reality and your thinking grows, and your actions become counterproductive. It’s like using an old map where you keep trying to use roads that no longer exist. You are not incompetent, your map is just outdated.

In large organizations, when we make decisions that other people carry out, we are one or more levels away from their consequences and may not immediately be able to update our understanding. The further we are from the feedback on our decisions, the easier it is to convince ourselves that we are right and avoid the challenge, the pain, of updating our views.

More software projects have failed because of management actions based on incorrect mental models than for all other causes combined.

Systems thinking and feedback loops

To better understand what's happening in an organization, we need a different way of thinking about problems. Systems thinking is a way of seeing what's really going on. At its core, it's about understanding how things influence each other over time. We tend to think in straight lines. A causes B. Something happens, and we assume there must be a single reason. But in many cases the reality is more like circles. What we do influences the system, and the system influences us back.

Take for instance a project behind schedule. Leaders respond by adding more engineers. More engineers create more coordination, more meetings, and more communication overhead. Experienced engineers spend more time onboarding and helping the new people. Productivity slows down, and leaders respond by adding even more people. The problem starts feeding itself.

These circular cause-and-effect relationships are called feedback loops. Some loops, called reinforcing feedback loops, reinforce change and make it grow, just like a downhill snowball or compounding interest. A change creates more of that same change, which makes the original effect even stronger. Other loops work in the opposite direction, called balancing feedback loops, by trying to keep systems stable, just like a thermostat in your house. When the temperature drops, the heating turns on. When the temperature rises, the heating turns off.

By tracing and understanding these loops, we start to see patterns that repeat themselves again and again. These patterns often explain why problems gradually improve or gradually get worse, even when everyone involved is trying to do the right thing.

When you analyze a software development organization, one of the first things to look for is reinforcing feedback loops. They are disasters waiting to happen. Here's one classic example:

1. Senior leadership wants faster results. Perhaps the business have ambitious goals to meet, executives are under pressure to demonstrate progress, or external events require a sudden turn.
    
2. To speed things up, more work is initiated. New strategic initiatives are launched, new investment projects are approved, and additional commitments are made to the business. Adding new things feels productive. People are busy, and the benefits seem just around the corner. It's an intuitive solution.
    
3. But middle managers and teams now have to spread themselves thinner. They switch between more contexts, and juggle even more priorities. On top of the new things, they still need to maintain existing products, deliver committed features and pay down technical debt. The result of more work in progress is less work being completed and less business value realized. The throughput goes down for well-known reasons. There are now more meetings, more dependencies, more coordination, more decisions, more interruptions, and more bottlenecks. Managers therefore get less time to observe and understand what's happening. They stop talking to users, stop talking to teams, stop exploring the actual products they are responsible for, and stop asking the right questions.
    
4. After a few months, senior leadership sees disappointing progress. The organization doesn't seem to be moving fast enough. The underlying cause, having too much going on at the same time, isn't, for them, obvious.
    
5. So yet another initiative to "fix the problem" is launched. A new task force, a new acceleration initiative, a flagship project, or a Transformation with a capital T. Unfortunately, of course, this makes the problem even worse.

This type of feedback loop is self-reinforcing and slow to reveal itself. Balancing feedback loops is the only mechanism that has the speed and power to prevent a runaway. A new dashboard is just one more thing the manager has to understand and keep up with. More status and steering meetings simply add another meeting to prepare for, while the information presented has often been filtered and interpreted through many layers. Starting a task force creates yet another team that needs to be led, coordinated, and followed up, with all the overhead that comes with it. None of these interventions necessarily make the manager less overloaded.

In this example, one balancing feedback action would be to cap the number of initiatives that can run at the same time. If the limit has been reached, no new initiatives can start. Leadership is then forced to prioritize and focus more on finishing ongoing commitments before starting new ones. The more overloaded and slower the organization becomes, the harder it becomes to start something new, and that stabilizes the system. It also forces better conversations. Is this initiative more valuable than the ones already ongoing? Can it wait? Is there something delivering less value that we can pause or stop?

Another option is to get rid of reporting not used to make any meaningful decisions. You can also replace some status and committee meetings with time spent out in the organization, observing and listening at the source directly. What are the teams working on? What are they waiting for? Where do decisions get stuck? What do they see as the biggest problems?

As you have probably realized by now, taking the right action depends on first understanding what's really going on in your organization. Accurate observations don't happen by accident, only by conscious management attention. You don't observe the organization through a form, you are exploring, looking, seeing, sensing, reading what is present and what is absent, and what is thriving and what is struggling. This is not a job where you can arrive with a generic framework or a fixed checklist to tick items off. You need to arrive with a trained capacity for attention, developed over years of looking at many different organizations in many different conditions. You compare what you see against everything you know about what could and should be there, what has been there, and what the current conditions suggest about where things are heading.

Why it's always hard to steer

It's always hard to steer because we are trying to control systems and organizations that are beyond our mental capacity to control perfectly. Our brain capacity is more or less fixed, but software and organizational complexity are not. They tend to grow. This means we may not really know better because what we know may only be simplifications that we have carried over from smaller and simpler situations.

Because managers are playing a game well outside their mental capacity, simplification is necessary. That simplification takes the form of methodologies, frameworks, mental models, and general principles like:

• "Don't add workers late in a project in an attempt to catch up."
• "Use the smallest possible team of the best possible people."
• "Don't punish the bearer of bad news."
• "Always break a project into modules."

Because simplifications like this is an approximation of reality, there are many ways we can fail. You can apply them in the wrong context or at the wrong level. A simplification intended to guide your judgement can become a substitute for your thinking and judgement. Simplifications can hide important variations. Simplifications can become outdated. Or we may start to treat metrics as more important than the outcome they were meant to represent.

And then we have … the customers

A software organization in crisis becomes so consumed by its internal problems that it forgets its fundamental reason for existing. The software organization is not a closed system. There are outside factors influencing the instability of the software development process.

You know your software organization is in trouble when you hear complaints such as:

• "We have too many customers."
• "If only our customers didn't bother us, we could have a great system."
• "Why do they need all this stuff? We know what's best for them."

These customers may be external paying customers, or they may be internal customers such as business units. As you can see in the figure, customers need the outputs of the software organization. To get those outputs, they provide requirements that express their needs, problems, and desires. They also provide resources such as money, subject matter experts, sponsorship, or political support. They also provide randomness which is a potential threat to getting what they want. Requirements change, business priorities change, new opportunities appear, people disagree, and new stakeholders with different opinions enter the picture. And the more customers you have, the more resources you get, but you also get more requirements, which may conflict, leading to more uncertainty and randomness.

Notice that in this feedback control model, the customer looks just like a controller, as indeed it is. They observe things, they have desires, they want the software development system to behave in a certain way, and they try to influence the software organization so that it produces what they want. Sometimes the customer's attempts to control the software development are aligned with the software organization, but not always.

For example, a customer's very specific requirement for a particular solution, where they basically tell the software organization exactly how to solve their problem, may be well aligned with what the software organization also believes is the best solution. On the other hand, this kind of approach can also reduce the software organization's room to explore alternatives. That can lead to less ownership of the solution within the software organization, and this may cause distrust between the two parties, and as a response, the customer starts specifying solutions in even greater detail. So the actions chosen by the customer, based on their mental model of how the world works, can increase the instability they want to avoid in the first place.

On the other hand, a software development organization can be extremely disruptive to its customers. Software can create challenges for the people on the receiving end. That is one reason customers try to exercise control of the software development organization. They are trying to reduce uncertainty seen from their world. This leads to a situation of multiple controllers, and the more controllers you add, the more difficult the system becomes to understand and steer.

Pressure, breakdowns and management overload

Hvis du leder et stort prosjekt og vil det skal gå til h*****e, gjør dette:

• Hopp over alt som heter tenkning og planlegging slik at du kommer i gang med leveransene raskest mulig. Er det ikke da du føler deg mest produktiv? Spesielt når du er presset på tid. Da føles jo planlegging og sånne ting som helt bortkastet tid.
  
  
• Ok da, hvis du finner ut at du faktisk må planlegge, bruk masse tid på å skrive lange abstrakte rapporter, fargelegge grafer og diagrammer, og fyll ut bokser i flytskjemaer. Sett deg ned og tenk, og tenk, og tenk litt mer. Det er det planlegging handler om. Ikke prøve ting ut for å se hva som fungerer, og dermed gjøre noe annerledes basert på læringen, før man går all-in og svir av kruttet. En plan basert på eksperimerintering og erfaring? Det er vel noe Silicon Valley-greier ...
  
  
• Gå for magefølelsen, og lås beslutninger og valg så tidlig som mulig (når du vet minst) slik at alle vet hva de har å forholde seg til. Da slipper man å bruke tid på avsporinger. Og len deg på overfladiske best-case estimater, det er jo best-case som er mest sannsynlig, er det ikke?
  
  
• Ignorer irriterende folk som begynner å stille spørsmål som "Hvorfor gjør vi dette prosjektet egentlig?", "Hva er problemet vi har blitt bedt om å løse for kundene våre?", "Hvilke resultater ønsker vi å oppnå?" Nei takk. Få prosjektet i gang. Prosjektet er et mål i seg selv vet du.
  
  
• Ikke gå for prosjektlederen og prosjekt-teamet med mest erfaring, taus domenekunnskap, og dokumentert evne til å lykkes med det du prøver og få til. Og velg leverandører du aldri hverken har hørt om eller jobbet med før.
  
  
• Se på ditt eget prosjekt som heeeelt unikt i verdenssammenheng. Ingen har noensinne gjort noe som ligner på ditt prosjekt! Derfor har du selvsagt ingen sammenlignbare prosjekter eller erfaringsdata å lene deg på når du skal estimere kostnad, tidsbruk og verdiskapning. Du har ingen å lære fra. Så da slipper du i hvert fall å bruke tid på akkurat det. Og hvis prosjektet blir forsinket eller bruker for mye penger, er jo problemet alltid selve overskridelsen. Ikke at man undervurderte kompleksiteten, omfanget eller usikkerheten fra begynnelsen av. Eller at det man sammenligner seg med er helt urimelig.
  
  
• Når det kommer til teknologivalg, gå alltid for det nyeste. Jo nyere, jo bedre. Alt som er "one of a kind" bør være musikk i dine ører siden prosjektet ditt er helt unikt. Standard hyllevare, repeterbarhet og modularitet passer dermed ikke inn. Store ting bygges best som en stor ting, ikke mange små ting.

Ja, gjør du dette stikker du deg i hvert fall ikke ut. I en database med 16 000 prosjekter fra mer enn 20 ulike felt i 136 land så er det kun 8.5% som har levert på både kost og tid. Og 0.5% nailet det de lovde på kost, tid og verdi. 99.5% av prosjektene brukte mer penger, eller ble forsinket, eller leverte mindre verdi eller en kombinasjon av dette.

Lykke til!

Muscle makes up about 40% your mass, and muscle is a major predictor of resilience, metabolic health, and survival.

Muscle health has two major components: 1) Physical and 2) Metabolic. The physical involves strength and mass, while the metabolic affects insulin sensitivity, glucose regulation, fatty-acid oxidation, and mitochondria health.

Through strength training you increase the density of muscle mitochondria which allows your body to use nutrients, such as carbohydrates and fats, and convert them into energy that can be used to power everyday activities. Losing skeletal muscle means losing the mitochondria that produce energy in your cells. And we all know the feeling of having low energy.

After age 30, you lose 3 to 8 percent skeletal muscle mass per decade. After about age 50, muscle mass decreases at an annual rate of 1 to 2 percent. The decline in muscle strength is even higher. Without progressive strength training, this loss is guaranteed.

Your skeletal muscle acts as an amino-acid reservoir. If you become sick or injured (infection, physical trauma, cancer etc), the body will pull amino acids from your available muscle tissue to repair and protect itself.

Your muscle also releases small signaling proteins, known as myokines, in response to exercise. Myokines are a collection of small proteins and peptides that travel through the bloodstream to regulate metabolism, reduce inflammation, and improve immune function. Myokines even improve your sense of wellbeing and capacity to learn.

Protein is not a single macronutrient, but a delivery system for twenty different individual amino acids. We don't eat for protein, per se, but for amino acids.

Proteins are the master regulators of all that is happening in your body, controlling function in all tissues and organs, including muscle.

Leucine is the most important amino acid for muscle health. Leucine activates a component of the mTOR signal complex, which plays a vital role in initiating and sustaining protein synthesis within cells. The muscle-protein synthesis is where amino acids are bounded together to build and repair skeletal muscle tissue.

Think of leucine as the key you turn in your car to fire up the engine. mTOR is the engine, and all the amino acids your body has available supply the fuel.

The mTOR mechanism is a binary on/off switch. The dose of protein you eat in a single meal is either sufficient to trigger muscle-protein synthesis or it isn't. But the system is nuanced, and one factor is age. When you are young and growing, mTOR is regulated by hormones, but as you age your body become less responsive to hormones and more sensitive to diet quality and leucine.

This is why I ensure my first meal of the day contains a minimum of 30 to 40 grams of protein, sufficient to trigger the leucine threshold (about 2.5 to 3 grams). And I'm aiming for a 1.6 to 2.0 g/kg daily intake.

Tim Ferris interviewed more than 200 world-class performers to deconstruct their success habits.

Here's my favorite tips and insights:

• Kids don't do what you say. They do what they see. How you live your life is their example.

• Good stories always beat good spreadsheets. Never forget that underneath all the math and the MBA bullshit talk, we are still emotionally driven human beings.
  

• How do you thrive in an unknowable future? Choose the plan with the most options. The best plan is the one that lets you change your plan.
  
  
• "First, ten." Tell ten people, show ten people, share it with ten people. Ten people who already trust and like you. If they don't tell anybody else, it's not that good and you should start over. If they do tell other people, you are on your way.
  
  
• If you want to do something extraordinary, you have two paths: 1) Become the best at one specific thing. 2) Become very good (top 25%) at two or more things. The first strategy is nearly impossible. But everyone has at least a few areas in which they could be in the top 25% with some effort. Make yourself rare by combining two or more "pretty goods" until no one else has your mix. At least one of the skills in your mixture should involve communication, either written or verbal.
  
  
• If I have a problem, I will own it. For example, do you blame your boss for not giving you the support you need? Plenty of people will say, "It's my boss's fault." No, it's actually your fault because you haven't educated her, you haven't influenced her, and you haven't explained to her in a manner she understands why you need the support that you need. That's taking extreme ownership of a problem.
  
  
• You should have a running list of three people that you are always watching. Someone senior to you that you want to emulate, a peer who you think is better at the job than you are and who you respect, and someone subordinate who's doing the job you did - one, two, or three years ago - better than you did. Learn from them, and you are going to be exponentially better than you are.
  
  
• Every time you meet someone, just in your head say, "I love you" before you have a conversation with them, and that conversation is going to go a lot better. Just assume everybody is doing the best they can with what they have, which is really hard for a lot of people to accept.
  
  
• "I'm busy" has become the default response when you ask anyone how they are doing. "Better to be busy than the opposite." This is something we have chosen. Work and obligations we have taken on voluntarily. We are busy because of our own ambition or drive or anxiety. It makes us feel important, sought-after, and put-upon. But what exactly is getting done?
  
  Busyness is not an inevitable condition of life. We need more idleness. Idleness is not just a vacation, it is as indispensable to the brain as vitamin D is to the body. It is, paradoxically, necessary to getting any work done.
  
  
• Never serve anything you would not want to eat.
  
  
• What makes a good commander? Humility. You've got to be humble, and you have to be coachable. Have the ability to listen, open your mind, and see that, maybe, there's a better way to do things. The arrogant guys can't take criticism from others, and can't even do an honest self-assessment because they think they already know everything. Stay humble or get humbled.
  
  
• Write in order to think. You actually don't know what you think until you try to write it. You think you have an idea, but when you begin to write it, you will realize that you have no idea.
  
  
• To blame someone for not fully understanding you is deeply unfair because, first of all, we don't understand ourselves, and even if we do understand ourselves, we have such a hard time communicating ourselves to other people.
  
  
• When you go into a conflict or a difficult situation, say less. That's it. Just say less.
  
  
• Honor those who seek the truth, beware of those who have found it.
  
  
• If you don't do something well, don't do it unless you want to spend the time to improve it.
  
  
• "Strong views, loosely held". Most people go through life and never develop strong views on things. They go along and buy into the consensus. You should have strong views, but you need to be able to adapt in light of new information.
  

A personal value I strive to live by, both as a dad and as a professional, is leading by example.

If I'm not willing to change, why should anyone else? I must behave in ways that are consistent with the values, norms and changes we have agreed on as a team. Practice what I preach.

It's my actions that send the strongest signals about what matters and what others should be doing. Consistency between words and actions also signals reliability. It builds trust.

This means my actions and behavior need to be visible and present. I need to show up and let people see what I stand for.

I am not always great at expressing expectations or coming up with a fancy uplifting speech on the fly, but I can step forward and carry some of the weight. Go first. Be willing to do the hard work alongside my team. It’s my way to demonstrate my investment in what we are trying to achieve.

If I want others to be committed, then I have to be 100 percent, without doubt, fully committed myself.

But there are pitfalls. I risk becoming a bottleneck if I feel the need to be involved in everything or be the “best” at every task.

I also believe our actions and behavior tend to come back on us. You get what you give. If I act in a disagreeable or negative way, that's often what I will get in return.

For example, want more proactivity in your team? Or a stronger tolerance for uncertainty?

I can take the first small step before everything is defined. I can share imperfect ideas to signal that it's okay not to have all the answers. I can meet new ideas with curiosity instead of reacting with doubt or negativity too quickly. I can stay open and calm in ambiguity.

Little by little, we adopt the thoughts, the attitudes and standards of the people around us. It's contagious - for better or worse.

I can never expect people around me to be more open and willing to learn and improve than I am.

It always starts with me.

Food for thought.

If someone mirrored your behaviour, what would that look like? What are people likely to pick up from you?

What is one behaviour you expect from others that you don’t consistently model yourself?