Holding the pen is a power move

How often have you gathered a work group around a whiteboard only to be surprised by how little people seem to want to contribute? All the ideas that have been raised individually or added to documents or Slack threads suddenly missing from the discussion. 

It can feel frustrating, like you’re the only person who cares about the problem. Often this results in you, or someone else going off alone to work out a solution by themselves, because if no one else cares then you might as well be the one to sort this out. Right?

Well, in many of these cases the problem is a simple one. Simply, you didn’t give them the pen. 

The person holding the pen in a whiteboarding session is the person in control. Standing beside the board holding a pen with the rest of the group sitting facing you is a power dynamic. You’ve placed yourself in the teacher role and no matter how much they like it the others are here as your audience. 

When you hold the pen you get to be the one to represent the problem to the group. You get to draw out the options and you get to manage the pace of the discussion. 

For someone who wants to demonstrate authority this can be a really simple way to do so. If you find yourself in a room with a group of senior people and you want to demonstrate that you know what you’re talking about try picking up a pen and drawing the problem out. 

But If you want other people to take a more active role in a discussion simply hand them the pen. 

The Best System Architecture

Your system architecture says many things about you; often it says you didn’t design it, or that you decided to follow the crowd, in the best cases it says you know what your needs are and have designed accordingly. There are many opinions about what good architecture looks like and depending on your situation there is likely to be an architecture that better suits your needs. When designing from scratch you have the freedom to design the best possible architecture.

Brownfield applications are a little different. Any system that has withstood more than a few years of operation should be celebrated; it has demonstrated its ability to do what it needed to do. Unfortunately, a system that’s been running for several years probably also shows its age and probably doesn’t look exactly as it would if you were to design it today. Some of the decisions might have been bad ones, but mostly they’ll have been the right decision at the time and need re-visiting to bring them up to date. 

So how do you re-architect a system? My preferred way is to do it gradually. 

As tempting as it is to stop working on features in order to rebuild part of a system, or even to build an entirely new system to replace the one that went wrong, this probably isn’t the best decision. Stopping ‘normal’ work to focus on rebuilding can help kickstart a tech-debt paydown project but it misses the opportunity to teach teams how to make incremental improvements alongside their regular work. Without these skills or discipline the ‘new’ system is likely to end up in the same poorly architected state within a few years. 

By gradually reviewing and replacing or removing parts of an old system you can turn a poorly architected system into something that exactly meets you needs. Focusing on the areas that cause the most pain, or are most frequently changed is a great way to start. By gradually removing dependencies, or bringing in new tools or technologies the system will start to improve. For many teams the best end state isn’t a complete re-design for 100% of the system but a more pragmatic approach to deal with the greatest pain points and isolate the infrequently changed areas.

But the work doesn’t stop here, system architecture is a constantly evolving being. Every day that you add or remove code you’re changing your architecture. When you decide to add or remove a dependency you’re changing your architecture. Even the decision not to change something is a decision on how your system architecture should be. 

Many teams look to successful companies to decide on the right architecture for them. This may work but it ignores the unique team and problem that you have. Knowing what you value, and knowing where you need to be are essential for designing a great architecture. If you value team autonomy then make sure the system architecture supports this. If you value throughput, or robustness, or ease of learning then take the time to understand exactly how your architecture will support this. Create shared values for the end state to remove the need for day to day decision approval and instead allow everyone to focus their efforts on analysis, education, and progress. 

When building new features teams should be working to move the architecture forwards at the same time as meeting their delivery goals. Sometimes that means a small change to a message, sometimes it means building a whole new microservice. Making this work means that every team needs to know exactly what their current architecture looks like, and also needs an opinion on what a better design would be. Regularly gathering around a whiteboard to discuss system design helps normalise design discussions and builds awareness of the pros and cons of every decision. 

Make time to build the architecture forwards by building awareness of the current situation and its impact. Help everyone to understand what needs to change and why. When estimating work factor in the time and cost of building it the right way, the way that allows you to get the feature you want AND the architecture you want.

A system that is under active development will never have a textbook perfect architecture for long because it isn’t a static being. Systems needs to evolve to support new decisions and ideas. So whether you have a monolith or services, microservices or mono-repos, the only thing that really determines how good your architecture is is whether you know it well enough to work with it. 

Reflections from 2019

2019, it’s the end of the year, and the end of the decade. This time 10 years ago I had just been made redundant, it ended up being perfect timing and the decade that followed was amazing and challenging. I’ve been lucky enough to work with teams full of smart and friendly folk and through the fantastic LondonCD Meetup and Pipeline Conferences discovered Continuous Delivery which ended up leading me into Engineering Management. 

Along the way I’ve spoken at conferences and meetups, contributed to a book, co-led Weekend Testing Europe, appeared on some podcasts, and launched Humans + Tech. Whoo. 

Not everything has gone exactly to plan and I leave this decade with greater patience and tolerance. Yes, really. I know that every situation teaches you something and for me at least, I need to look for that opportunity and focus on it. Moving into Engineering Management has given me great opportunities to learn about things that I had never even thought about. From coaching people to Kubernetes, and with an awful lot of AWS too, I’m loving the random things I get to learn day to day through work. 

I love to read and this decade has been accompanied by some of my favourite books. I’ve loved Radical Candor, The Unicorn Project, Deep Work, Resilient Management, Powerful, and The Coaching Habit as well as many, many others. I could read all day, every day but in the past few years I’ve started to realise that filling my mind with endless ideas doesn’t necessarily translate into successful execution. Reading a little less and working to apply the best ideas either to myself, my writing, or my teams is a better approach and one that I’ll be continuing to work on in 2020. 

In the next decade I’m going to be more intentional. I’m not very good at being bored and often end up agreeing to things without really thinking about what I want to do. In 2020, and hopefully in the years that follow, I’ll be choosing just a few things to really focus my attention on. The results may feel slower, and I might actually need to learn to accept boredom, but the end result should be far more satisfying. In 2020, my (out of work) focus will be on Humans + Tech, my book, and working out how to pull the millions of threads of ideas into a coherent story or tool that actually makes sense. 

Huge thanks to everyone I’ve had the pleasure of working with, getting to know, drinking coffee with, or sharing ideas with over the internet. Happy New Year!

Book Review – The Unicorn Project by Gene Kim

It’s been nearly seven years since The Phoenix Project made The Three Ways a regular topic of Tech conversation. These days most tech companies are at least aware of, and hopefully embracing Systems Thinking, fast feedback loops, and learning cultures to deliver value to the customers. 

In his new book The Unicorn Project, Gene Kim revisits the fictional company “Parts Unlimited” to explain the five ideals of Locality and Simplicity; Focus, Flow and Joy; Improvement of Daily Work; Psychological Safety; and Customer Focus. For anyone looking for, or undergoing a digital transformation these five ideals will be very familiar. Just like with The Phoenix Project, The Unicorn Project excels not from introducing radical ideas but in helping to highlight a path through the chaos. 

The Unicorn Project is set at the same time as The Phoenix Project and follows Maxine and a “Rebellion” team as they battle to break team dependencies, and operational silos to allow teams to deliver customer value, fast. For many people working in tech the description of discovering valuable customer features hidden in Jira backlogs and having to raise tickets with multiple different teams to access code, environments, and even to release will be painfully familiar. I loved seeing enjoyment and job satisfaction getting so much focus, Kim did a great job of capturing the levels of frustration that poor build and deployment setups can bring.  

Following a fictional team in a fictional company gives great creative licence and allows many of the most painfully secret Tech practices to be included and resolved. Not everyone will love the fable style of storytelling but I think it’s a powerful way to share the darker side of many tech teams; we see the power struggles that can play out, and the resistance to change surfaced. In one section the “Rebellion” team accidentally cause a Production Incident as they work to build an independent release pipeline. These are the realities of many tech teams but are rarely covered in real experience reports.

On the flip side the fictional storytelling does lead to some fairly incredible situations. Firstly the timeframes, whilst I know that developers only needing days, or sometimes hours to solve the trickiest of problems is useful to keep the story moving, it is incredibly unlikely that any company would manage to solve so many issues with this level of ease. Secondly Parts Unlimited seems to have somehow hired, and retained, a huge number of talented people, all of whom have been sitting waiting for this opportunity to come along. Again I know this helps keep things moving along nicely but anyone going through even a fraction of these issues needs to prepare themselves for at least a few months of code and platform wrangling. 

Despite this the story is engaging and does a great job of following the team as they fix things, step by step. In the real world dependencies, data needs, security, and more can end up becoming so entangled that it’s difficult to see a way out. In The Unicorn Project we get to see the whole messy, uncertain path to fixing things. It shows that things do go wrong, people lose trust, and maybe you make the wrong decisions along the way. Despite this by working together, and having a really clear end goal you can make a huge impact on your job, and on the company.

In conclusion I’d say that The Unicorn Project does a fantastic job of covering many of the current tech challenges. Anyone working in tech should read this book and either celebrate that they don’t have to work in an environment like this, or be encouraged, and inspired, to see how much different an individual can have. Now go and find your own Rebellion.

Full disclosure: I received a pre-release copy of The Unicorn Project in exchange for a review. All views are my own. 

Great development is about more than code

Most developers start out focusing solely on learning how to write code; usually a specific language and specific techniques. I started out with BASIC; spending many hours tinkering with games and graphics. I loved creating things just to see if I could create them not because there was any need to do so. 

Later I used the same approach to learn the syntax and capabilities of Java. It was easier this time, many of the skills I’d learned from BASIC were applicable despite the language differences. As my knowledge increased I created more sophisticated, and complicated solutions. I felt like I was becoming a better developer and I was, but I still wasn’t what you would call a good developer.

It took many years for me to really appreciate the importance of fully understanding a problem before even thinking about the solution. Spending time, often way more than you feel comfortable spending, thinking about the problem before writing a single line of code is hard. It feels counter-intuitive to see a problem and not immediately start trying to solve it. Experience taught me that good code design does not come from writing code.

Believing that complicated code is better code is a mistake, and one commonly made. Good code is the right code for the problem. It’s the right code for the team (language, tools, level of documentation), and it’s the right code for the problem (testability, maintainability, extendability). Often that means that the best code for the job is the most boring, simplest code. The kind of code that anyone in the team can pick up and work with.

Great developers are those that can see a business problem, collaborate with others, and design the simplest solution to get things done. They’re able to balance their time to support others, investigate ideas, as well as writing code. Being proficient in the language is a big part of their success, but it isn’t the only part. Anyone wanting to increase their development skills needs to look past simply writing code and start learning how to design great (simple) solutions.

How to stop being so busy

Busy people are not successful people.

We mistake being busy with being productive. We get hit after hit of dopamine, the so-called “Happy Hormone” as we check off items on the to-do list, or smash out emails, all the while boasting on Twitter that we are “Just so busy”. It feels good, and it can become addictive.

Many companies reinforce our behavior by creating a heavy meeting culture or constantly hitting employees with short-term deadlines that they have to scramble to meet. Of course there are times in life when we really do need to be busy; the day before a deadline, or when we’re planning a big event we might need us to push our sleeves and get things done.

The problem comes when we get stuck in the “busy mode” either through our own choice or because of someone else’s. Over time we lose the ability to even see that we’re permanently reactive with little ability to control our own workload or direction. For many of us, going home tired at the end of the day makes us feel satisfied. We equate tiredness to productivity, and come to think that we should always feel this tired as proof that we’re doing our job.

But being busy is a choice.

When we spend all our time being reactive and busy we lose sight of the long term. Even with the best intentions, you won’t find time to be strategic if you’re always fighting against the tide of being busy. Not being strategic means we’re not planning our choices and miss the chance to prevent reactive situations from occurring.

Maybe as managers we’re too busy to see or deal with someone who’s unhappy in their role. When they quit we’re forced into a reactive situation. As an engineer we can get stuck shoring up a crumbling architecture, desperately fixing bugs to keep things working. But at the same time we’re missing the chance to stop and design a system that scales, or is secure, and maintainable. Anyone seeking a promotion needs to find time to stop, look around, and work out what the strategic work really looks like. Otherwise you’ll be stuck where you are, all the time wondering why your manager isn’t rewarding you for fixing 5 million bugs or running 200 meetings.

When we get stuck in the permanent busy mode we need to work twice as hard just to stay where we are. All the while we miss the opportunity to make the right choices to help ourselves or our teams move forwards.

Strategic thinking is the only way to progress.

To create time for strategic thinking we need to do less stuff; either we need to delegate things or we need to reject things.

An Eisenhower Decision Matrix can be a great way to separate tasks into the Important, and the Urgent. Anything urgent but not important can be delegated, anything not urgent and not important can be rejected.

Everything else is either done now or scheduled in. Make sure you include self-care in this group. Self-care is often de-prioritised by busy people but neglecting yourself severely hinders your ability to stay healthy and sharp.

The Eisenhower Decision Matrix can be a great way to see when too firmly stuck in Tactical or Strategic mode. If all your tasks sit in one part of the matrix then you can clearly see that you place too much emphasis on tasks of this type.

EissenhowerMatrix

For anyone in a senior or leadership position having tasks in your Urgent, Not Important quadrant is a strong indicator that you’re not delegating enough. When you fail to delegate you fail to give other people opportunities. Correct this as soon as you can.

Once you’ve decided what you’re going to work on, and more importantly, what you’re not, you need to tell people. Make your priorities or calendar visible to the people around you and fiercely defend it so they know you’re serious. If they disagree with your priorities ask them to help you decide what gets de-prioritised to make space for their task. Be clear about the trade-offs.

If you have strategic work time scheduled in make sure you protect it at all costs. Lara Hogan has some brilliant advice on how to set up your calendar to be most effective for you. When you know the times of day that you’re most effective you can use them for the most important tasks. It seems obvious but many of us try to squeeze in important work when we have the time rather than carving out time for it. It should go without saying that important work is important. Give it the respect it deserves.

Finally, learn to say no. It doesn’t need to difficult, simply thank someone for thinking of you and politely decline.  You can’t do everything and you won’t be able to meet everyone’s expectations but that’s ok. Take control of your life and spend your time in a way that gets you to your goals.

2018 in Books

Books_of_2018_-_Google_DocsSometimes we read the book we need to solve the problem at hand. Other times we read a book and only afterwards see the situations that it has taught us to see.

2018 was a little lighter on reading than I would have liked but I did discover, and rediscover some gems.

First up was a reread of The Phoenix Project: A Novel about IT, Devops, and Helping Your Business Win. Five years on from its first publication and it’s starting to feel a little dated but still an excellent book with relevant lessons. Focusing on flow, and making work visible were key takeaways for me this time around.

Next up I read, and loved, Powerful by Patty McCord. Patty writes about recruiting, motivating, and creating great teams based on her experience developing the culture at Netflix.

What takes the place of rules, processes, approvals, bureaucracy, and permissions?” The answer: Clear, continuous communication about the context of the work to be done. Telling people, “Here’s exactly where we are, and here’s what we’re trying to accomplish.”

And

“You want to be a lifelong learner; you want to always be acquiring new skills and having new experiences, and that doesn’t have to be at the same company. The fact is that sometimes you’re hired by a company to do something, and then you do it and it’s done. If I hire people to rebuild my garage, when they’re done I don’t need them to rebuild the back of my house.”

The most practical book I read in 2018 was Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, Jez Humble and Gene Kim. This is a book crammed full of tips for helping teams achieve success, I particularly appreciated the focus on burnout that threaded its way throughout the book. Important reading.

Radical Candor by Kim Scott was my book of the year. “Radical candor is the sweet spot between managers who are obnoxiously aggressive on one side and ruinously empathetic on the other. It’s about providing guidance, which involves a mix of praise as well as criticism—delivered to produce better results and help employees achieve”. There are many, many great stories and transferable tips shared in this book. A joy to read, and a book that has changed the way I manage and want to be managed.

I ended up highlighting most of the book but this quote neatly sums up how it made me feel

“If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea.”

My final book of the year was Switch by Chip Heath and  Dan Heath. Years ago I struggled through Thinking Fast, Thinking Slow, enjoying the message but finding it hard to recall accurately. Switch does a great job of sharing the same message in a far more accessible format. I absolutely loved the Elephant and the Rider metaphor to describe our minds, and I found the stories in the book to be interesting and highly motivating. I can’t wait to put these ideas into practice in 2019.

How was your 2018? Did you discover any books worth shouting about?

The Reverse Pilot

Growing effective teams requires a lot of experimenting. As people join the team and grow they’ll change the team dynamic. New ideas will be suggested and new difficulties will appear. Adapting to proposals and challenges naturally leads to changes and it feels productive, and positive to introduce new ways of working.

When we look back on situations we tend to focus on what was missing. Missing requirements, understanding, or more practical things like missing alerts or monitoring. We add in extra technology, or meetings, or process to try to fix the problems we see.

It can be easy to forget that sometimes we need to be removing things to be more effective.

Measuring Change

When we introduce processes or tools we usually bring them in after considering the options. We agree on a trial period and consider who needs to be involved in the trial. Usually we’ll have something to measure, or assess to give a measurable assessment of the change.

If we don’t see the hoped benefits, or especially if we experience new discomfort from the introduction, we’re happy to abandon our experiment. Abandonment doesn’t necessarily mean we give up entirely, instead if the pain is bad enough, we might seek out a new change or tool to achieve our goals.

Critically assessing our current tools and process in the same way could bring similar benefits to team effectiveness.

Learning By Doing

I once worked on a team that was having difficulty releasing our code. Building and testing each release was painful, the actual release itself took much longer than expected, and we often had unexpected problems once we got the code into production. Each time we hit a problem we discussed what had gone wrong and usually added another safeguard to the process.

Over time we Introduced sign offs from the design team, the product team, and the test team. We become more cautious about who could release and when. Releases became less frequent to reduce the impact on customers. Eventually we ended up with a slow and inflexible process that made releasing anything at all painful and stressful.

It would have been easy to keep tinkering with the existing process and most likely adding more safe-guards and checks to try to improve the quality of releases. Experience tells us that when things are going badly we’re missing something and we keep on adding steps and tools to our process until things work.

Luckily a new team member came in with fresh eyes and forced us to step back and re-evaluate. Instead of trying to improve our current process we went right back to the beginning and evaluated what we wanted to achieve. We defined the values that mattered to us, and we worked out what success would really look like. Afterwards we designed a new, totally different, process that met our values. Surprisingly it removed almost all of the safe-guards that we previously thought were needed to make releasing safer. The result – a process that actually did what we wanted it to do, and ended up being more effective than our original one too.

Take An Intentional Step Back

Taking the time to step back and consider exactly what you hope to achieve with your process is a great way to start cutting it back. A daily practice like standup can become a habit without necessarily achieving the goal of improving team communication. Realising this is the first step towards experimenting with alternative communication styles. Take the time to define your values and then assess your current approach against these values. Are you meeting them? If not, why not?

Focus On The Small As Well As The Large

Not all change needs to be large to have a significant impact. Sometimes a number of small changes can have a far bigger result and will almost certainly face less resistance than a single big-bang change. Skimming off small but unnecessary tasks will save you time and lead to a streamlined, effective culture.

I once produced a weekly, company-wide, email newsletter to summarise all the changes that were going on in the Technology department. I described the experiments we were running, translated the technical release notes into English, and explained why these changes were important for our users. The newsletter took a lot of time and effort to produce. Often the technical description of releases was meaningless, and missing the critical ‘why’ explanation. for each one I had to track down the original author to find the answers I was trying to give to others. Once I had the details I had to write the email, create and attach screenshots, and email it out.

People were reading the email but there was no real feedback. Even more significantly I couldn’t see any change in behaviour as a result of the email. I still had to hunt for the information I wanted, and the recipients still asked questions about things that I had covered. The email didn’t appear to have the impact I had hoped so I decided to run a reverse pilot and simply stopped sending it.

A week later and nothing. No one asked about it. The questions about technologies changes were the same. I took that as a positive result to my own experiment. If the email wasn’t missed then it clearly wasn’t adding enough value to justify the time I was putting in.

Several years later someone asked me why I didn’t send the emails anymore. They remembered the email and had found it useful. Not useful enough to follow-up when I stopped writing it, but useful enough to remember it having existed. Together we found an easier way to produce a shorter email that provided ‘enough’ value without taking so much time to create.

In Summary

Finding the ideal tool or process takes time and will likely require us to add or remove a number of steps to get to the ideal place. The “reverse pilot” provides an easy way to test out whether you can remove things from your process. Approach it in the same way you would an introduction of a new tool or process and be prepared to reinstate the change if results show that you should.

Manage the energy for successful meetings

Successful meetings, workshops, and even smaller group discussions rely on creating and managing the right energy. A meeting where everyone has low energy will feel long and boring, whereas a small group discussion with too much high-energy can feel like an argument waiting to happen. 

Experienced workshop designers will know that scheduling breaks at the right time is important, as is the essential “after lunch energiser” to get people engaged again. Meetings and work discussions are no different. 

Finding ways to generate energy is an important part of a successful meeting. A couple of minutes of light-hearted chit-chat as people get settled can help set the tone (if appropriate for the meeting content). If the meeting is mostly about relaying content then it can be easy to rely on powerpoint presentations but finding a way to incorporate physical items such as paper cut outs, or port-it notes can be very effective at engaging the audience. Simple tasks such as grouping statements on bits of paper instead of reading them a list, or asking for agenda items to be written on post-its rather than typed into a document can make the meeting feel collaborative and energising. 

Movement is another great way to generate energy. Having people stand up and move around completely changes the energy in the room and can serve as an excellent switch between stages of a meeting or workshop. Workstations where attendees move around to focus on smaller topics or tasks are fun and help keep people engaged, but even something simple like standing up to stick a post-it note on a wall can be enough to get people focused. Movement can be an effective way to break people away from laptop distractions too, something which can be a big culprit in sucking energy from the room. 

Spending time sitting and writing will reduce the energy and also give people time to think and reflect. I’m a big fan of having people sit in silence for a set amount of time, for example silently writing topic suggestions for 5 minutes at the beginning of the meeting to encourage deeper thinking. In “Time to Think” Nancy Kline writes about the importance of giving people space to think, but also the power of them knowing they won’t be interrupted for a set amount of time, freeing them up to really think. 

Not everyone can think on the spot, and not everyone will be comfortable speaking up in front of a crowd so mixing up the meeting formats can help different people engage in a way that suits them. Having time to prepare and then choose what I’m comfortable sharing is a much kinder way to encourage engagement than putting someone on the spot in a meeting. Sharing the meeting format in advance can give even more time for participants to plan their contribution. 

Bringing groups of people together can have unpredictable results and learning to redirect energy is essential facilitation tool. It can be hard to know in advance that energy will need to be managed but signs such as an unresolved discussion, or lack of actionable outcomes can be good indicators. When discussions becomes heated they can get stuck in a head-to-head energy battle that is difficult to resolve. Re-directing this energy into a different form can really help move things along. Whiteboards, or post it notes for example, can be a new focus for the energy, even a simple request such as “can you sketch that out for me on the board” can help to move the discussion along in a low-conflict way. 

Creating meetings that include both movement and deep thinking can lead to thoughtful discussions with energised attendees. Keeping people engaged and knowing how to resolve deadlocks will lead to more enjoyable, and effective meetings. Try introducing one change with the intention of shifting the energy in your meeting and see whether you see an impact.

Teach people to ask “Why?”

Why

Schools kill creativity. From a young age students are taught to listen to the “expert” and believe everything they’re told. Very few lessons focus on teaching young people to form an opinion, or question the facts being presented.

As adults we join workplaces that have strong hierarchies. Information and policies flow down from the top and everyone underneath is expected to follow along without causing a fuss.

We attend conferences, read books, and hear people tell us the right way to do things all day, every day.

But really good teams are formed of people who can work together and push each other to be better. They’re formed of people who respect each other, listen to each other, and then question the ideas. Pooling our collective experiences allows us to be greater than the sum of our parts and working together allows us all to learn and improve.

For most people having to justify themselves, and explain the thought-process they went through to drive at their argument helps them be better. So often we decide things instinctively, without examining our own biases or influences. It can be easy to design something, or build something for the wrong reasons, and it is easy to do because we generally don’t have to explain ourselves to anyone.

To change things we need to start teaching everyone to question decisions regardless of where they come from. When someone proposes a new way of doing something I expect them to present their argument with the pros and cons of adopting the change. When we reflect back on things, that have either gone well or not so well, we should take the time to think back over the pros and cons we identified. Were we right? What did we miss? How can we better next time?

Successfully changing people’s decision-making requires time and consistent expectations. As leaders we should encourage everyone in the team to question others on their thinking. Changing the format of meetings to encourage upfront prep, and discussion time before we get to the decision making can help. Making sure we have a safe space to allow everyone to actually have a voice is critical.

When we present decisions or direction we should set an example and present the options we saw and the advantages and disadvantages we can see from the route we chose. Invite others to question your ideas and tell them if they successfully help you change your mind. We should celebrate having input from others.

It can be hard to change the way people work, and we can seemingly be making our own work harder by inviting everyone to have an opinion on it, but questioning and justifying decisions is essential for team health.