Amy Leadership, Management, Teams

What is an Engineering Manager?

Introducing Engineering Managers

Engineering management is a discipline and role that has been growing in maturity over recent years, now almost all but the smallest tech teams will have an Engineering Manager there to manage and grow engineers. 

A typical Engineering Manager will have a technical background and be actively looking to move into people management, they’ll mostly concern themselves with hiring and growing engineers but may, or may not also be writing code, introducing ways of working, conducting code reviews, leading on architecture, ensuring delivery, setting the strategy and pretty much everything in between. 

 

Styles of Engineering Manager

To help with job hunting and meeting role expectations I think about the variety of Engineering Management elements as being grouped into four distinct styles based on time and energy spent on each of the primary responsibilities – Code (writing, and reviewing), Architecture (designing and setting technical direction), People (hiring, managing, growing), Team health (ways of working, productivity, happiness), and Product strategy (what to build and when). 

The Tech Lead Manager

Engineering Managers who play the Tech Lead Manager role will line-manage people as well as lead on technical decisions. They’ll be hands-on with code and code reviews and usually work with a single team to deliver on team goals. 

The Tech Lead Manager is often the most senior engineer on the team and will work alongside someone setting the product direction (possibly a Product Manager) and possibly an agile coach to guide team health. Companies with a Tech Lead Manager style of Engineering Management will usually have an architect designing the system architecture and ensuring all teams meet architectural guidelines. 

The ideal candidate for this role will have deep technical knowledge usually in the language or technology that the team is using as well as being a proficient people manager. 

The Tech Lead Manager will spend most of their time and energy on code followed by people. TechLeadMgr

The Architectural Lead Manager

Distinguished from The Tech Lead Manager by not being hands-on writing code. The Architectural Lead Manager will still set technical direction and be involved in code reviews as well as managing people. Compared to the Tech Lead Manager, the Architectural Lead Manager can more easily work across teams without causing too many bottlenecks since they’re not expected to be contributing code (although they often will write non-critical path code). 

This Engineering Manager will work alongside someone setting the product direction, and possibly an agile coach to guide team health. There may still be an Architect involved with team direction but they’re likely to be less hands-on and work in an advisory role with the Engineering Manager leading on most technical direction decisions. 

The ideal candidate for this role will be a people manager with technical skills but they may have a different technical background to the team. Job requirements are more likely to focus on technical strategy skills over technical execution. 

The Architectural Lead Manager will mainly focus on technical strategy and people.

ArchitecturalLeadMgr

The People Manager

The People Manager Engineering Manager will primarily be responsible for managing the engineers on the team. As a dedicated People Manager this Engineering Manager is more likely to manage people with different skill sets to their own, they can more easily work across teams, and with a single focus, they have the ability to create a superior environment for coaching and people development. 

This Engineering Manager will work closely with people who are responsible for the team’s delivery and direction as well as technical decisions. In some cases, this could mean the Engineering Manager works closely with a Product Manager, Tech Lead, and Agile Coach as well as an Architect. 

People Managers may come from different backgrounds although must still be technical enough to gain respect from the team. Coaching skills are likely to be more valuable than coding skills. 

Almost all of a People Manager’s time and energy will be on the individuals in the team.

PeopleMgr

The Team Lead Manager

The Team Lead Engineering Manager is responsible for managing everything to do with the team. They’ll usually line-manage the engineers in the team as well as being responsible for the direction and delivery of the product/project.  

The Team Lead Manager will usually manage engineers who are at least as senior as they are, and often more senior as they focus on the team’s health and direction over specific technical decisions. Additional roles such as Agile Coaches, Architects, and sometimes even Product Managers are less likely to be found on teams with this style of Engineering Manager.  

Technical leadership and project management abilities are likely to be more valued than a specific language or technology. 

The Team Lead Manager has a more even spread of focus on the team’s direction, health, and individuals.

TeamLeadMgr

Engineering Management Expectations

Confusingly these four styles of engineering management and numerous variants of the four are all referred to as Engineering Management despite being very different roles. Succeeding as an Engineering Manager requires you to work out exactly which version you’re expected to be and then to focus your time and skills on the relevant parts. If you’re expected to be an Architectural Lead Manager but you’re spending all of your time focusing on engineer happiness and no time on the technical roadmap then you’re unlikely to succeed. Likewise, if you’re meant to be a People Manager but you’re constantly getting involved in code reviews and maybe even trying to write code then you’re probably missing expectations as well as stepping on other people’s toes. 

Working out the style of Engineering Manager

The easiest way to work out which style of Engineering Manager you’re expected to be is to find out which other support roles exist in the team. If you’re joining a team that also has a Tech Lead and a Product Manager and an Agile Coach then you’re likely to be a People Manager or an Architectural Lead. But if you find there’s no Tech Lead then understanding if you’re expected to contribute code or not might help determine if this is a Tech Lead Manager role or not. 

For people already in the role, or for identifying the style of other Engineering Managers consider how you prioritise your time. Are you more likely to miss a team retrospective or a technical roadmap session? Do you prioritise one-two-one meetings over all else or are you finding a way to squeeze them in besides writing code? 

The style is just the starting point

A great Engineering Manager builds and grows a team to be achieving to the best of their ability. As the line-manager it’s up to you to create opportunities and support people in order for them to achieve their goals, it’s also up to you to create the environment to allow the team to succeed.

If you’re working as an Architectural Lead but have a great engineer who wants to get involved in technical road mapping then make it happen. Flex in and out of your responsibilities to better support your team or create space for others as needed. Maybe a critical project needs more of your hands-on time to make it succeed, or perhaps you want to give someone more responsibility to help them grow. Sometimes people will leave and you’ll need to pick up some slack, or you’ll end up overly busy and need to drop things. Use the style of your Engineering Manager role to determine your core responsibilities and make sure you’re always hitting them, everything else can be scaled up and down as needed. 

Amy Leadership, Teams

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. 

Amy System Design

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. 

Amy Management

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!

Amy Book Reviews

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. 

Amy Engineering Principles, Management

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.

Amy Decision making, Leadership, Management, Productivity

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.

Amy Engineering Principles, Leadership, Management

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?

Amy Engineering Principles, Leadership

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.

Amy Leadership

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.