Push your own flywheel

Today marks my 20 years working in the software industry. I was going to write a post about what I’ve done over that time and my takeaways from all the weird and beautiful things I’ve done. I might still do, but below is something that’s taken me nearly 20 years to realise. I don’t know why it’s taking me so long. Perhaps it’s age, getting things wrong (a lot), reflecting more on what I’m doing or all of the above. Whatever it is, I wish I understood this when I was younger. Who knows what I might have accomplished otherwise?

Either way, I know it now, so let’s see what the next 20 years hold now that I’m pushing myself and worrying a lot less about what happens.

Push your own flywheel.

There are many opportunities out there, but the vast majority won’t look like opportunities. It will only do so after the fact. The best thing you can do is push yourself forward and try different things. There’s no guarantee that the things you try will work or even be successful long-term. But the more you do, the more opportunities you’ll find yourself in. It starts becoming a flywheel, but to get it moving, you’ve got to push it first. One of the most complex parts of this approach is how long and hard you’ll have to push. Most people (me included!) give up too soon, usually at the first attempt, as it didn’t work out as you expected. 

The more comfortable you get with pushing yourself, the easier it becomes to move your flywheel. But suppose you’re constantly looking for external sources to push you or waiting for the right opportunity. In that case, you’ll either be waiting for a long time or worse, when the opportunity comes, you’re nowhere near ready to take full advantage of it. 

But when you are proactive, people begin to spot that you’re the person who can do things. They will start pushing opportunities forward to you – the flywheel starts moving from external sources. People often need to see you are ready (or close enough to be ready) before they likely push you forward for that opportunity. You can try faking it until you make it, but people often spot that you’re faking. Why? Because they’ve never seen you do anything else. So why would you suddenly be able to do it now?

Pushing my own flywheel 

About ten years ago, I started talking at conferences as it terrified me, so what better way to try and get over it than by doing it more? Luckily, it worked. However, I often questioned why I put so much effort into overcoming this fear. It was costing me more (lots of personal time and anxiety) than I was getting out of it (any recognition that anyone got anything from it). But I found things I enjoyed and kept at, slowly becoming more comfortable and better. 

Over the last two years, I’ve also been doing a lot of work around psychological safety for reasons I’ll not go into here. Still, I’m happy to talk more (message me). I have put together a talk on fostering more psychological safety in our teams. However, I was still determining what to do with it. 

Then, in late September 2022, I heard the organisation I work for would have a whole-day in-person internal-only engineering conference. So I approached the organisers to see if I could get a slot. I did, but it was only 10 minutes, so I had to cut back and focus on the message. 

At this conference, I might have given my best talk to date. It’s also one of my shortest but has taken the most effort to put together. It took almost 18 months to develop my understanding of the subject matter to know what I wanted to talk about. Then, getting feedback (massive thank you to all that did) and iterating on it months before to come in under ten minutes. Plus, the ten years honing my presentation skills. 

Jit Gosai standing on stage at the Old Trafford cricket ground for BBC Platform Engineering Conference 2022.

It was not until weeks after the talk that I realised this was one of my most significant opportunities to push forward the work I’m trying to do. There was no way I could have done that talk the way I wanted in the space of 2 weeks between asking to be able to speak and getting on that stage and delivering it. 

This one 10-minute talk led to two other more significant opportunities. My past speaking gigs got me on the radar of a track host at QCon. So when they asked if I had anything suitable, my psych safety work was perfect. But I only had 4 weeks to turn it around while still doing my day job. Luckily, I’d already done much of the hard work and just needed to pull it all together. Speaking on the Staff+ track at QCon in March 2023 was an opportunity that very rarely comes around. Especially for an engineering conference that doesn’t usually have testers (for a 3-day 6-track conference, I may have been the only one); in addition to that, most speakers are invited rather than the usual calls for speakers, making it much harder to secure a slot. 

Jit Gosai standing on stage at QCon London 2023 on the Staff+ track stage.

The second opportunity didn’t come around until another 5 months later and, at first, didn’t look like much. An internal team had seen my 10-minute psych safety talk and asked if I could do one for their upcoming away day. I now had my much longer QCon talk, so I offered them that, which they agreed to. It was a remote talk, so I didn’t get to meet the team on the day, but I got some nice comments after and didn’t think much more about it. 

It turned out that the room was full of HR representatives from all over the other parts of my organisation. Who all went back to their teams and told them this was the talk to see. Let’s just say I’ve run more workshops and talks in the last few months than I’ve done in the last few years! Massively accelerating my work with psychological safety throughout my department and across the organisation. And all because I could react so quickly to the opportunities, it allowed me to take maximum advantage of them. But to be able to do so was taking the gamble months, sometimes years before, without knowing how they would help in the future.

Connecting the dots

This reminds me of a quote from Steve Jobs during his 2015 Stanford Commence speech:

You can’t connect the dots looking forward; you can only connect them looking backward. So, you have to trust that the dots will somehow connect in your future. You have to trust in something–your gut, destiny, life, karma, whatever.

Steve Jobs 2015 Stanford Commence speech

It’s only with hindsight that I can now look back and see how things have connected to where I am today. I had to push myself in the present moment because whenever you look into the future, it’s almost always full of uncertainty and failure. And that’s the thing: there are always more ways for things to go wrong than right, but if you wait for certainty on the outcome, there is a good chance you will be too late and unable to exploit whatever opportunities come your way. 

This is why there are many opportunities out there, but often, they only look like it after the fact. Sometimes, you have to take a risk and see where it gets you. 

This is not to say you shouldn’t bother planning as you can’t control the outcomes, but recognise that your plans may not always go the way you intended. So, being adaptable and having a willingness to change can be advantageous. And more so if you’re willing to push through unknowns and failures. So far, the best way I’ve found to do this is to have a direction you want to head in and follow where the road in front leads you. As long as you look up occasionally to check your heading in the right direction, you will eventually get there. 

The other point to mention is that a lot of things that happen to you are chance. We live in a complex world, often doing quite complicated things. The best way to ensure nothing bad happens to you is to do nothing, but that also means nothing good will happen, either. Sometimes, you’ll get lucky and be in the right place at the right time. But you can improve your odds by doing more, which allows you to see more and be in the right place at the right time more often than not.

So find a way to push your own flywheel, and don’t worry too much about how things will connect. As long as you look up occasionally to ensure you’re still heading in the right direction, you’ll be alright. And you never know; those opportunities you’re chasing might start chasing you instead.

3 traits of Self-leadership

A colleague of mine Qambar Raza recently shared this great Ted talk with me on self-leadership 👏

🎥 🍿🥤 Great leadership starts with self-leadership | Lars Sudmann

In it Lars describes three behaviour traits to improve your self-leadership:

1. Self awareness
2. Self reflection
3. Self regulation

This is a brilliant way to change any personal trait that you would like to be different.

The key to it is Step 1 by recognising what you do want, how that differs to what you do now and then identifying the incremental steps towards it.

The difficulty comes in Step 2 being honest with yourself everyday about how you are progressing towards your goal and what feedback mechanisms you are using.

Finally Step 3 is recognising that situations outside of your control will still occur where you might default back to your existing behaviour. So instead of trying to repress your response reframe how you look at the situation instead that enables you to look at the situation in a different more positive mindset .

Don’t know where to start yourself improvement journey then start by identifying some of the default behaviours you might exhibit.

Three things of 2020

3 minute read

Below are three things that when I reflect back on 2020 that stand out to me. I’ve purposely not mentioned COVID because I think this is one thing that all of us would have on our list so didn’t think there was anything more I can say on this that no one else is already thinking. I’ve also included my three things from 2019 at the end which I still think are important. 

🌳 You can’t stick your apples on other people’s trees

  • Something that Sarah has been trying to tell me for some time but it never really clicked until this year 💡
  • I’ve learned a lot this year about how we learn and what we can do to enable more or it
    • My apples…
  • But there is one thing that keeps coming back
  • It doesn’t matter how many different ways you find to engage people with the content
    • Unless they really care about it they may never have the insights that you think they should have 
    • They may never see the benefits you do or incorporate that that information into their ways of working 
    • This is all about trying to stick your apples on other people’s trees…
  • Usually they are just too busy to even be able to give it the time 
  • The best approach is for them to find ways to incorporate into their own learning 
    • To encourage them grow their own apples…  
  • This takes a lot more time than simply forwarding a link to read or even sending them on workshops/training courses… 

Speaking of apples…

🍎 Informal Relationships

Informal Relationships between team members is the key foundation for high performing engineering teams

  • Most teams members can work with each other quite efficiently but the level with which we do makes the difference between low and high performing teams 
  • We can cooperate and coordinate quite well as can be seen by how well teams can slice up work into tickets and hand them off to the next stage (cooperating). Some teams take this further and begin coordinating their actions using information from their step in the process to inform the next stages (coordinating)
  • But coordinating with teams members isn’t enough we need to be able to collaborate because of the level of complexity we work in means no one person can ever know it all. This essential and often forgotten detail makes team members interdependent 
  • It’s the level of how well we can collaborate and work through problems that gets teams towards higher levels of performance. This performance can be measured by how sustainably the team can deliver end user value (throughput)
  • Psychological safety plays a big part in this interdependence and collaboration and can be characterised by how well people in the team can “just talk to each other” 
    • Psychological safety being the belief of individual team members that it is safe within their work environment to take interpersonal risk 

🎓 Learn more: Fundations of great teams? Start with relationships

🍏 Manager or Leader? 

Understanding the difference between the two can be really helpful  

  • One of the things that has really stood out for me this year has been the difference between management and leadership
  • I always conflated the two and never really appreciated the difference
  • Since then I’ve not looked at software engineering teams the same again
  • Do other make the same mistake? 
    • Leading to confusion on when we should be leading our teams and when we should shift to a more management style 
  • A Hybrid model may also be workable 
    • especially the closer you get to where the work is happening 
    • With a heavy slant towards leadership then management 
    • But the further you get from it the more a leadership style works best 
  • A simple heuristic: 
    • the less experienced a member of staff then a more hybrid approach 
    • but the more experienced they are then a more leadership style is appropriate  

Three things 2019

Teams

  • Working as a team will accomplish more than just working alone 
  • I’ve tried and accomplished some things with some good results 
  • But nothing compared to what I’ve contributed to as a team
  • But it starts with trust… 

Trust 

  • that people really do know what the best course of action is
  • They just sometimes need help thinking things through 
  • Which needs people to listen…  

Listen

  • And I mean really listening
  • This has by far been the most important thing I’ve done this year
  • Just asking very open questions and listening to what people say 
  • I’ve learned more about people and what is happening in our teams from this than any other way 
  • The interesting thing is the people I’ve listened to seem to get so much more out of it 
    • I think this is because not many of our team members get a chance to be listened to… 

What are your three things for 2020?

Let me know in the comments below

Foundations of great teams? Start with relationships

4 mins reading time

tl;dr: check out my miro model to get the key points.

Model of who do we prefer working with 

https://miro.com/app/board/o9J_khGWgWc=/
Good informal relationships are they key to better collaboration https://miro.com/app/board/o9J_khGWgWc=/

Over the last couple of years I’ve started to see that relationships between people appears to play a big role in how successful their teams are. The better the relationship the more willing those people are to share ideas and learn from each other. Which generally leads to much better results for those teams in the long run. Not only that they get those results a lot faster and are typically happier too.

But this is work so shouldn’t we be leaving our personal feelings at the door when it comes to getting things done? What do relationships have to do with anything?

Who do we prefer to work with?

One thing I have seen is that when people like each other they tend to be more likely to work together then people who don’t like each other. Generally for people who don’t get along their interactions tend to be the bare minimum usually resorting to asynchronous methods of communications like email or other group message systems (Slack, Teams etc). They pretty much do anything they can to avoid face-to-face contact.

The problem here is that this can leave messages more open to interpretation and further exacerbate poor relationships. Not only that sharing information this way can at times be slower than simply speaking face-to-face.

But how much do people have to like each other to work together successfully and is there anything we can do to make sure people who do have to work together can get along? 

How much do people have to like each other?

The amount tends to be quite subjective but these types of relationships are usually characterised as work colleagues or sometimes work friends.  They are essentially informal relationships between people who work together where they are very likely to say that the like each other. Multiple informal relationships lead to informal networks which can make working in teams much more productive and enjoyable for the people involved. 

The benefit of informal networks is that they are more likely to lead to collaborative behaviour that enables learning from each other. This in turn can lead to new ideas and innovations. Which all successful teams need.

What can we do to help people get along more? 

By helping people to find more common ground with each other tends to lead people to think of each other as we rather then us and them. This common ground can help people to see that they are similar to each other which can lead to familiarity. Both of which can help towards more positive reciprocal behaviours towards each other. All three of these (similarity, familiarity and positive reciprocal behaviours) benefit us psychologically by making us feel good.

Feeling good to think and collaborate

When we feel good we are more likely to think freely rather than when we feel threatened and are looking to protect ourselves. When we are threatened our brains actively limits resources from working memory. Working memory is a key component for analytical thinking which you need for creative insight and problem solving.  

The level of collaboration is also improved as when we feel good we are also more accepting of people’s differences and more willing to take interpersonal risks with other people.  Interpersonal risks are very personal to the individual but can typically be classified as:

  • Looking incompetent because you don’t know something when you think you should 
  • Thinking you are being disruptive by wasting someones time by asking questions or needing things to be explained in more detail
  • Looking ignorant because you don’t know something  

All three of which can have perceived negative consequences to your reputation.

All these risks need people to be vulnerable in front of others so that they can learn from each other and therefore collaborate more effectively. But if they are unwilling to do this then they are not going to share what they do and don’t know which leads to less effective teams. Essentailly everyone has to figure things out forthemsevles instead of learning it quickly from someone else.

Feeling good means better innovations?

Better team member relationships, feeling good, collaboration and learning from each other doesn’t guarantee that the team will come up with best and most efficient solution to a problem. What it does do is create the right conditions for those solutions to found and implemented.  

Not only that a team that enjoys working together and is able to work through their differences is more likely to keep doing this repeatedly and get better at it every time they do. Therefore leading to more ideas and increased likelihood of the team finding alternative solutions to problems. One of which might just be that innovation your organisation has been looking for to give them the edge over their rivals.

What are the trade-offs to all this harmony?

There is a risks of overly harmonious teams though. This is that they are less likely to challenge each other and are more likely to go with the flow. Which could actually lead to less innovation and creativity. As they are more willing to just accept the first idea rather than challenging it which could risk the team harmony. So some level of “creative abrasion” is needed to help people productively challenge ideas.

But again good working relationships will help stop challenging situations from causing so much tension that people begin to refuse to work with each other.

Is there data that back this up?

Research by Tiziana Casciaro and Miguel Sousa Lobo for their 2005 paper Competent Jerks, Lovable Fools, and the Formation of Social Networks backs up a lot of the ideas above. Their data was based on surveying 4 large organisation and collecting over 10,000 data points on work relationships.

You can find my notes in this model.

My biggest takeaways from AgileTD 2020: The future of testers isn’t in automation or testing

I was lucky enough to speak at AgileTD this year and also attend some of the talks. These are my main takeaways from the conference based on the talks that I was able to make.

My confirmation bias sense is tingling with this but…  

The future of testers is not in automation or testing it will play a part but not as big as – helping teams build quality-in.  

Most teams see testing as either bug hunting or just another cost centre that needs eliminating. Therefore testers (at all levels) need to get much better at communicating the value of testing.

As testers we need to start shifting our skill set from doing the testing to advocating for testing within teams.

The skills we need to develop will take time to build as it’s not a matter of just attending training but having hands on experience of using and applying the skills.   

Otherwise testers risk becoming irrelevant in teams that begin to form without the need for testers if (or when) the next shift happens.

What is working in our favour is the slow shift to adopt new development ideas such as those expressed in Accelerate. But also teams figuring out how to really collaborate and not just cooperate. Think of the dance of passing tickets around that happens in a lot of development teams.

Which talks should you take the time to watch?

So which of these talk further lead me to believe the above. Let me break it down:

The future of testers is not in automation or testing

That is not to say it will go away, but it will not be the main objective of our roles.

Is not automation: Automation Addiction by Huib Schoots and Paul Holland (Day 1)

  • A lot of people’s addiction to automation appears to come from automation tool manufactures marketing (promising the world) and sunk cost fallacy (making it hard for people to stop once they’ve started). I’d also add peoples job spec also asking for automation with no rational as to why they want it
  • It is good for some things, generally things we know how they should behave and especially when we can isolate them from the UI.
    • UI’s can behave in unpredictable ways so not always the best place to put automation that needs to be consistent and reliable
  • So what do you do?
  • Focus on teams and start small: 
    • (Focus on) exploratory testing,
    • (Start small with) a good test strategy that includes what is and is not to be tested
  • Automation should be focused and isolated

Is not testing: Let it go by Nicola Sedgwick (Day 3)

  • We as testers need to let go of testing and start focusing on how we help teams understand what quality is and how they build it in
  • Nicola does this by being a Quality Coach and using Quality Engineers embedded in teams to help them mitigates the risks
  • This was a great talk and something lots of others have been advocating.
  • I think we still need to better define the Quality Coach and Quality Engineer roles but we have to start somewhere
  • I’ve written a little about what testers could do next
  • You can also learn a more about Quality Engineer from my TestBash Manchester talk (paywalled)

Also see

  • Testing is not the goal! By Rob Meaney (See below for more)
  • Beyond the bugs by Rick Tracy (See below for more)

Communicating the value of testing

How to pitch and value testing properly in the age of DevOps by Bjorn Boisschot (Day 1)

  • A fairly simple and affected approach to getting the test team behind a testing vision that they can then use to describe what it is that they do.
  • Rather than the typical dry approach of traditional testing (test scripts, reports, bugs) which all reinforce the bug hunter viewpoint of testing
  • This gets testing focused more towards what the organisation is trying to do (think company mission statement) and focuses the testing vision towards that
  • This helps others understand that it more then just bug hunting but about helping make decisions on the quality of the products and how they affect end users
  • His approach was to create a testing mission based on the company vision statement. With a focus on the why of testing and not the what or the how (see Simon Sinek: Start with why). From there they created a number of goals that would help them achieve that mission. Then they used the goal, question, metrics technique to make it measurable.
  • For some in the org this approach made testing much more accessible and greatly improved their view of it.
    • But for others, well, they still didn’t care 

Beyond the bugs by Rick Tracy (Day 3)

  • As senior members of the test team we need to help our testers understand what value they bring to teams. Then give them the tools (verbal and written communication skills) to make their value relatable to other roles. Otherwise they are very likely to be seen as bug hunters and a cost that can be eliminated.  
  • Really fascinating talk where he showed how everyone outside of testing views our roles (bug hunters that cost money). He then showed how we need to cover three main arguments for others to see the value we bring. These being conceptually (does it make logical sense to them) practically (how can they/others use it) and monetary (what does it cost and what’s the ROI). 
  • He then applied these three arguments to different testing scenarios from doing no testing at all to shifting testing as far left as possible and doing it earlier and earlier in the process. Through this he showed how the initial investment in testing increased but would dramatically decrease the costs later on in the process due to issues being found earlier and therefore easier and cheaper to fix.
  • This all reinforced the idea that testers do much more then add costs to projects and finding bugs. Such as 
    • Manually finding issues that would otherwise affect users 
    • Testing earlier on in the process before code is written by testing requirements and designs to prevent issues entering into the systems earlier
    • Raising levels of team understanding in the product, the processes they use and potential issues that is could be introduced 
    • Types of risk that could affect the team and acting as a type of insurance of that risk 
    • Making testing relatable to non testers 
    • Providing sources of information for innovation and improvements within the teams ways of working 
  • But all of this doesn’t just happen. You have to invest in your testers (and them in themselves!) for them to be able to do this such as their technical skills, improving their awareness, understanding risk, alignment with the org etc. IMO: If you keep testers ‘dumb’ and just bug hunting then that is all you will get 
  • He then linked this investments to potential measures so you can see if your investments was paying off and a way for testers to see improvements. Cycle and lead times where two areas that came up quite often 
  • These measures where then linked to business value. Two main ones being faster time to market and improved customer trust in the product. 

The skills we need to develop

These skills are not limited to just these talk but are great examples of what they are

How to keep your agility as a tester by Ard Kramer (Day 1)

  • Great talk about how he uses the 4 virtues of stoicism to be a better testers. I actually think this would help a lot of people within development teams so if you’ve not heard of it before I recommend checking it out. 
  • This looks like a good resource https://iep.utm.edu/stoiceth/ but this talk focused on just the 4 virtues of wisdom, courage, justice and moderation 

Also see 

  • Extreme learning situations as testers (Day 3)
  • How to keep testers motivated by Federico Toledo (Day 3)
  • Beyond the bugs by Rick Tracy (See above)
  • Testing is not the goal! By Rob Meaney (See below)
  • Introducing psychological safety in a tribe (See below)
  • Growing Quality from Culture in Testing Times by Tom Young (See below)
  • Faster Delivery teams? Kill the Test column by Jit Gosai (See below)

Adopt new development ideas

Testing is not the goal! By Rob Meaney (Day 2)

  • From  testability > operability > observability and his journey with his learning with these techniques and how teams have be able to make use of them.
  • I think one of the really interesting points he made was understanding where your team is in their development life cycle.
    • Are they just starting out or are they an established team and product.
    • Depending on where you on this cycle will affect to what level you will need testability, operability and observability.
    • As the three things are about managing complexity and when you are starting out complexity isn’t the problem, product market fit is. 

Also see

  • Faster Delivery teams? Kill the Test column by Jit Gosai (See below)

How to really collaborate and not just cooperate

Growing Quality from Culture in Testing Times by Tom Young (Day 1)

  • Great story from Tom Young on how the BBC news mobile team have grown over the years and how focusing on their team culture has been one of the best ways to build quality into their product. All they way through the talk Tom shouted out to how the whole team help deliver their product

Faster Delivery teams? Kill the Test column by Jit Gosai (Day 2)

Introducing psychological safety in a tribe by Gitte Klitgaard and Morgan Ahlström (Day 3)

  • Hearing how other people have tried to address psychological safety in organisation was very interesting. There was a lot in the talk that I recognised from Amy Edmundsons work (Teaming and Fearless organisation). They didn’t use Amy definition of what psychological safety is but from what I’ve seen all the definitions are almost the same. Simply put are people willing to take interpersonal risks within group settings. If so they have psychological safety if not then they are considered lacking it. 
  • The things that stood out for me was that all these types of initiatives take time and constant work. They are not things that you run a workshop, take a few questionnaires and you have the safety.
  • Also psychological safety is very personal thing so what one person feels is not the same as another in the same team. 
  • There is also a lot of misconception around psychological safety in that people feel that in psychologically safe environments will no longer have any conflicts and is all about everyone being comfortable. This is not the case.
    • PS environments are about being able to share your thoughts and ideas without the worry that it could be used against you in some way.
    • The main reason for PS is to establish environments conducive to learning from each other – which is what is needed for the knowledge work that we do 
    • But to learn effectively your need some level of discomfort
    • Too much discomfort and it can tip into fear which causes the flight or flight response  
      • and you’re not learning anything other then self protection 
      • The best way to protect yourself? Don’t say anything that could lead to a situation that causes conflict… 
    • So PS environments are about people being able to work through conflict productively that can lead to new insights and ideas

There was many, many more talks at the conference (perhaps too many) that I wasn’t able to make and thats not including the workshops so it is worth looking through the programme and seeing what stands out for you.

Think I missed a talk that should be in the list above let me know in the comments.

What is it about that particular talk that makes you think it should be included?

What above do you disagree with?

The difference between leaders and managers

3 minute read

Tl;dr: Hybrid Leader-managers could be one of the keys to successful software teams but first you need to understand the difference between the two. 

A higher quality version of the model can be found on my Miro board.

The default style for most leadership within the software teams is towards a management style which caters for managing complexity through process and routines.  But by understanding the differences between management and leadership we can better create hybrid leader-managers. This approach is beneficial for software teams as the work they do can at time be highly complex. 

Complex work can be described as work that has an uncertain outcome due to the many variables that can affect it. These variables can be known or unknown either before, during and after the work is completed.

Leader-managers styles are best suited for leads that work closely to where the work is happening as the hybrid model takes into account that some work is routine, and therefore a management style is suitable and some work is innovative and therefore leadership approach is more appropriate. The further up the hierarchy you go the more a leadership style is suited as this enables the organisation to better handle change. 

Being able to adapt to change is a now a feature of almost all software teams and ones that a better equipped to adapt to it are more likely to succeed on more dimensions of success other than just delivering what the users want. Successful dimensions could be sustainable team performance, team member satisfaction and delivering end user value consistently. 

What does this model illustrate? 

Based on a HBR article what do leaders really do by John P. Kotter it shows that management is about reducing complexity through standardisation and making work efficient. This heads organisations towards certainty. Leadership on the other hand is all about creating change within the organisations and embracing the complexity that exists. They do this through communication and motivating the organisation towards that change.

Management

On the left are the management styles for handling complexity within organisations through three distinct approaches. Managers communicate what needs to be done through planning and budgeting. Create networks of people and relationships to do the work by hiring and organising them. Finally making sure the work happens by managing complexity and solving problems.

Leadership

On the right are the leadership approaches for creating change within organisations. Leaders communicate what needs to be done by setting the direction the organisation is heading in and letting the employees figure out how they get there. They create networks of people and relationships to do the work not by telling them to collaborate but by aligning them through that direction. Leaders make sure that the work happens by motivating those people to solve problems for themselves instead of handing them solutions.

Which is better?

As is clear from the model management and leadership do have their differences but it’s not about one approach being better than the other but that they are complementary to each other. It is almost like they balance each other from the extremes of just following one approach.

Do you see a difference between management and leadership?

How have you been led or managed in the past?

Does this model change your approach to leadership and management?

Let me know in the comment below