Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • The Daily Stand-up - can we make it better? | jimiwikman.se
    Jimi Wikman

    Jimi Wikman is an experienced and much appreciated consultant that have worked as team lead, scrum master and project manager for many years. He is also a popular work process designer and educator with a specialty in the Atlassian products. With more than 25 years practical experience as a frontend developer, graphic designer, tester and requirement analyst he knows the pain and pleasures of what the teams face on a daily basis.

    The Daily Stand-up - can we make it better?

    Posted , 102 views, 0 comments ,

    Photo by fauxels from Pexels

    If you have worked in IT in the past 10-15 years or so, you probably have endured the endless regurgitation of meaningless information in a daily stand-up. You have probably felt the anxiety of being judged and been annoyed over your teammates doctoring their results to look more productive. You probably also wished you did not have to go to the meetings once or twice. What if I told you there is a better way to manage daily stand-ups? Because there is.

    First let us figure out what the purpose of a daily stand-up is and where it comes from. The need to organize groups and to collaborate is as old as time itself and while many consider the daily stand-up, or daily scrum to originate from the Scrum framework, that is not true. Regular meetings have been a common practice since long before Scrum, and it is also why it is the most used aspect of Scrum in less than Agile work processes.

    What Scrum did however was to add psychological stress to the formula with the intent of increasing productivity. This was done by putting emphasis on proof of progress rather than collaboration. It is an effective way to shame people into becoming more productive, and it is a typical behavior for extroverts to seek the admiration and praise of others. The downside is increased levels of stress, which is counterproductive. In many cases it also leads to manipulation of data and fragmentation of work, especially in continuous delivery situations where people tend to work on multiple things at the same time.

    For many years Scrum had three questions that was the law to regurgitate every daily meeting:

    1. What did I do yesterday that helped the development team meet the sprint goal?
    2. What will I do today to help the development team meet the sprint goal?
    3. Do I see any impediment that prevents me or the development team from meeting the sprint goal?

    In the 2020 scrum guide they have backed off from this a bit, but they still focus on the feeling of guilt by pushing the conversation towards progress.


    "The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work."

    This is even more emphasized in the statement of the benefits of the daily stand-up:


    Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.

    Again this is clearly written from the perspective of an extrovert because for many introverts this is NOT a forum for improved communication. The idea that the daily stand-up eliminate the need for other meetings is not true. It most certainly can consolidate questions into a more focused forum, which does reduce the need to bother developers and others multiple times, but you often find reasons for more meetings, not less.

    How do we make this better?

    Let us first decide why we want to have daily meetings in the first place. The most obvious reason is to gain control. This is how most managers that are detached from the team see the daily stand-up because it is the only way they can stay on top of things, so they can look good in other meetings. That is not what daily stand-ups are for however and as a manger you should instead manage your time and make sure you work with the team and not act as a proxy.

    The reason we have daily stand-up should be to make sure everyone in the team have a voice and to make sure everyone is informed. By making sure everyone in the team get a voice we can find impediments and help each other solve problems. We can lift concerns and ask questions in a safe setting that allow the team to feel safe. It allows for a common forum for information, so everyone can feel that they have the information they need at all times.

    We do this because questions and doubt are the bane of productivity and team health.

    The first thing we do is to remove the time cap. Our minds are very sensitive to time and performance under pressure, so we remove that. Instead, we add a 30-minute slot every morning where we spend as much time as we need. Sometimes it is just 5 minutes, sometimes we extend the 30 minutes and change it into another type of meeting.

    The second thing we do is remove the need to report what has been done. This is the cause of much anxiety and in a healthy team you should not need that type of information anyway. Instead, we focus on questions, impediments and requests for help. We make sure everyone in the team get a chance to speak, and we make sure that everyone feel safe, so they dare to say what is on their mind. This is important because one thing we want to capture is if time estimates need to be extended or if new tasks might be needed.

    We sort things that come up as team related or personal, so we can focus on the team related issues first and then take personal questions after the meeting to make the disruption as small as possible. To make this disruption even smaller we put the daily meeting as early as possible without limiting peoples freedom. This means that you most likely have people in the team that have kids or other family situations that require them to have some flexibility in the morning and afternoon. 9 or 10 are common times, but you can just as well do this after lunch for example. The aim is to avoid disrupting the team as content switching is bad.

    The final part is for the team lead and architect to inform the team of things happening outside the team that is relevant to the team.

    I strongly suggest that you make this daily meeting as comfortable as possible instead of actually making it an actual stand-up. The reason for that is that most people are more likely to raise questions and ask for help when they are comfortable. If you can align this around a coffee break or breakfast, then that is excellent.

    The summary:

    • Schedule the meeting as early as possible without limiting the flexibility of your team members.
    • Go around the team and let everyone ask questions, request help and raise concerns if there are any.
    • Team lead and Architect give information relevant for the team.
    • Confirm activities such as additional meetings or request for information or to solve impediments
    • Grab some water or coffee and then return to work again.

    I find that these types of daily meetings often lead to better productivity for the simple reason that people feel less stressed when they get information and can get their problems solved. The outcome of these meetings often lead to technical discussions to answer technical questions and sometimes new activities to refactor things that might not have been captured otherwise.

    So if you are stuck in a daily routine of regurgitating Jira numbers where you feel the need to adjust numbers a bit just to look good, then I suggest you give this approach a try instead. 

    Management by fear and intimidation is a poor substitute for making your team feel safe and informed.

    • Interresting 1

    User Feedback

    Recommended Comments

    There are no comments to display.

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Similar Content

    • By Jimi Wikman
      Over the years I have seen many claims to what flavor of Agile is king. In this article we will look at Scrum and Kanban to see if we can determine which of these two flavors are the best for you and your team. I have a feeling you will be surprised at the answer, but I hope you will not be.
      I recently read an article called "Scrum Is Dead. All Hail Kanban, the New King" where the author Emanuel Marques praise the Kanban flavor of Agile as his experience of Scrum have been less positive compared to Kanban. One of the responses to that article was written by Maarten Dalmijn, and he made some good points in his article on how flawed the initial article was.
      To anyone who work with Scrum in multiple projects and multiple companies you probably recognize Emanuel's story. It is in no way a unique experience he has that Scrum, like many other Agile flavors, are misrepresented due to adjustments by the team or the company. Here are some examples from Emanuel's article:
      A common thing that happens way too often. When you are inexperienced with Scrum, estimations and you do not set sprint goals, then this happens a lot. We see that the team is not working properly in the burndown chart as well.

      This is a typical Agile burndown when using story points when you either have issues that are too big or you do not close issues properly. For a team working with story point, which I think is stupid in any case, a burndown chart is completely useless.
      This is again inexperience in making proper estimations and because of that you did not have room for the unexpected. In all processes, methodologies and frameworks you need to be able to make proper work assessments. Agile make that easier by letting you make arbitrary measurements that are more like "guesstimates". If you fail doing that, then you are in real trouble regardless of what process methodology or framework you choose.
      Emanuel's team choose to go to Kanban because of their inability to adjust their way of working away from the production line of thinking to an Agile way of thinking. What was it about Kanban that attracted them?
      So out of all the things that Kanban offer, Emanuel's team choose to focus on these. As you can see all of these are about commitment and responsibility. If you combine this with the reasons Emanuel and his team felt the need to move from Scrum to Kanban you probably can see the same thing as I can and that is that this is a team that no one has taught how to work properly.
      They have been left in a work environment where things are difficult to navigate and control and as a result they feel they are unable to commit to anything. I assume this is because failure, as diffuse as that definition might be, happens frequently. They also seem to be working with a poor scrum master, possibly also inexperienced or limited in his capabilities by the work environment.
      Sadly I think Emanuel and his team will soon find out that Kanban with the focus on escaping accountability and control is a bad choice. Kanban is not going to make failures go away. In fact, it will probably make things worse as the stakeholders will find the Kanban way of working, especially the bare-bones version Emanuel and his team are describing, very annoying as they have little to no control in that flow.
      What does this have to do with what flavor is king?
      Well this has everything to do with what flavor is king. They all are. If you use them properly. Sadly many work places implement Agile in all its forms in the wrong way. They try to make Agile work in a project based organization with an ITIL based steering structure with multiple teams on the same products.
      If you add inexperience and poor coaching resources, then you are setting up all flavors of Agile to fail. With that comes frustration and stress for the teams, and they will naturally try to distance themselves from management and any form of accountability as they are destined to fail regardless off their effort.
      This is referred to as a MOD project by some of us that work with process and methodology design. MOD is short for "March of doom" meaning that the project or the team are already doomed before they start due to the restrictions already placed on them. It is also in reference to how managers often refer to them MODifying the Agile way of working, which often result in a poor experience.
      If you work with Scrum, Kanban, DevOps or any other flavor of Agile, that can be king for you and your team. If you use it correctly and you actually take your findings in retrospective to adjust it to fit your way of working. You can even mix them to find the optimal workflow for your team, because they all come from the same source: Agile.
      You have the power to make your flavor of Agile king
      This might seem strange for anyone who work in workplaces where your way of working is dictated by management, but there is hope. In all organizations you have two ways of working: The Steering and the Operational. If you can find the way to meet the steering, so they can do their job, then what happens in your team should be up to you. If you are sharing responsibilities with more teams, then you should build your way of working together with the other teams. Never work in isolation if you share responsibilities.
      In order to do that you need to figure out what steering need so you can provide that. Usually this is the holy trinity of time, money and quality. Time and money comes through time reporting and proper estimations. Quality comes from requirements and testing alongside prioritization. So no matter what flavor you choose you need the following:
      A handover of translated need - you need to understand what the need is so you can take ownership. A Prioritization meeting - to decide what to do next. A common practice to make estimations - learn to make proper estimations instead of "guesstimations". Log time at least once per day if you have time estimates. Break down tasks as small as possible and close as soon as they are done if using story points. That is usually all you need, regardless of flavor.
      So go out and make whatever flavor you prefer KING today.

      View full blog article
    • By Jimi Wikman
      I must admit that I am amused at the sheer number of posts that flood the Internet the last months that all revolve around how to make remote teamwork work. They all seem share one common thing and that is that they are written by, or for, managers. The thing is though that for most of us that work in IT this has worked for decades and it is for many of us a part of our daily routine.
      It is with a sad smile that I see the complete hysteria from middle and upper management when it comes to working from remote. It is as if the last 20 years of advancement in that area never actually reached this group. Their futile need for control and the withdrawal symptoms from not getting your daily meeting "fix" is in my eyes nothing new, but it becomes so very obvious in times of crisis.
      We see large organizations cutting away their workforce and while they try to trim away across the organization it is pretty obvious that it is people who are close to the consumers that suffer the most. Stores, restaurants, hotels and travel are all sadly on the brink of extinction. On the technical side of things we see less work as well, but not because the work is no longer needed, but because investments are more careful when the cash flow is less stable.
      We see an upswing for collaboration tools such as Miro and Trello while at least my daily feed is filled to the brink of articles on how to remain productive from remote. Most articles are so basic that I have to wonder who they are written for as most development teams have this as part of their daily work. Things like "focus on direct calls instead of chat" and "make sure your team know how to reach you" is utterly ridiculous however and in many articles I feel like I am being patronized and addressed like a five year old.
      Working from home is not something that should be strange or confusing in 2020. If you do not have work processes that work for that, then I would argue that you have been neglecting to evolve as an organization for a long time. To be a manager that are having problems functioning within a remote teamwork environment is not only a liability in this crisis, but for the foreseeable future. If you are having issues with that now, then I suggest you start looking into improving that right now. It is a skill that you must have in this day and age.
      The silver lining with this situation however is that many organizations now are forced to transform. We see it already that some larger organizations are reducing the middle management section for faster communication and more direct management. Meetings are heavily reduced, which is because many meetings at middle management levels are just to transfer information. In a remote workforce that is wasteful, so sharing information are done more efficiently.
      We also see how badly communication between business, IT and Operations are working. I don't think I have seen this many articles about DevOps or Incident Management in the last decade. I have seen a big upswing in Quality Assurance discussions, especially surrounding requirements and facilitating workshop on remote. Portfolio management is on the rise and I get more questions about Portfolio for Jira, BigPicture and Structure than I think I have ever had. Clearly people are in need of ways to get an overview of the work to satisfy their need for control.
      It is also interesting that I have not seen a single request for Jira Align...
      While business and management are in a bit of panic mode at the moment I see the opposite in the development and test areas. People are working well from home and I see productivity is skyrocketing. The pressure on management is increasing to get better requirements and improve communication, but as long as the development teams get the information they need, then they are golden it seems. I hear people are less stressed, better focused and I even hear that things like system stability and technical debt is getting a bit of focus lately.
      I hope that this crisis can lead to some change in management in the long run. Having more time to actually think and being forced to learn how to communicate more efficiently should benefit management greatly. Having the tools and processes to work from remote is a good way to future proof your organization. I also hope more managers will realize that working from home does not make you less productive. In fact it will greatly benefit some groups that not only can get more focused, but also can work when they are most productive.
      If you are a manager that are struggling with remote teamwork, then don't chase articles that give you platitudes and nonsense advice. Talk to your development teams instead. They most likely already have this in place for working from home or to collaborate with other teams or offshore. Take this opportunity to slow down, process the information and then communicate it clearly instead of just running all the time. If you lack the tools or infrastructure to work efficiently on remote, then invest in it now. It is a good investment, not just for a crisis like the current one, but also for meeting the future demands of the employees.
      Embrace Remote Teamwork, just like the rest of us did back in 2005. ūüėČ

      View full blog article
    • By Jimi Wikman
      As a manager you often work harder than anyone else in the team. Long hours, often after the workday has ended, or even weekdays sometimes, is unfortunately not uncommon. There are conflicts to be resolved and content switching that will make anyone exhausted. This is a sure way to burn yourself out if you let it and this is why it can be a good thing to take a voluntary demotion once in a while.
      This may sound like a terrible idea, but I have found that not only will a voluntary demotion renew your energy, it will reinvigorate your passion for the craft, update you with the latest changes to the craft as well as reconnect with the people you normally lead. It is also incredibly humbling to "step down" and I tend to feel a bit of relief as that fear of not being allowed to fail or loose my position goes away.
      For me I like to dive into the design part of my work. This is because I tend to spend time with test and requirements in my management role any way and I prefer to code with no pressure to deliver. I am also not very good with java script, which you pretty much must know inside and out these days.
      Design on the other hand is diverse and while the tools change over time, the fundamentals does not. The psychology behind stay the same, even if a few new studies may show interesting changes now and again. In no way is it as fast paced as the world of front end development or as complex as the testing the increasingly more complicated infrastructures of businesses today.
      It is also pretty much the opposite of management where you often feel that you have accomplished nothing at the end of the day. This is of course not true, but it's very hard to see concrete evidence of your work when you work with people all day. Design on the other hand is very obvious and it's amazing to see the things you can create using tools like Sketch or Photoshop.
      For me this works wonders to renew my energy and I try to add something like this in once every 2-3 years or so. It's usually short assignments, but that is just the way I like it. I did this for Svenska Färghus Gruppen that was even more amazing since I had two colleagues that were design leads and I was just a simple designer for a change. I learned a ton and had an amazing time, much thanks to my awesome collegues Victor Werning and Camilla Romander that took me under their wings.
      Currently I work  with ChessIT as a digital designer and again I am having a blast. I am diving into Sketch with new eyes as this is a time sensitive assignment so things must be done quickly. Creating dynamic symbols and font styles is key here. It's also locked down as the front end framework is already in place so I have to work within that constraint. It's a challenge and I am just loving the fact that even if it's fast paced I do not get stressed and I love every minute of it.
      As a side effect of taking these design assignments I not only get to be creative for a change, I also stumble upon new tools and work processes which is going to benefit me greatly in future management assignments. It is truly a win-win situation as I get renewed energy, feel happier and also grow my knowledge and understanding of design with hands on experience.
      I also get much needed time to reflect and I recently wrote about being caught in my own mental trap. This is that feeling where you fear loosing income or position because it would somehow make me less successful. It's a silly thought because position or level of income does not define your worth or your level of success. It also paralyze you and make you afraid of failing. As failing is the basis of growth and learning that lock you in a self imposed vacuum, which makes you miserable.
      So, if you have the opportunity to demote yourself then I suggest you take it. Take a step back and relive the passion that once led to the management position in the first place. Let go of your ego, release your fear of failure and once more become the student so you can grow, as a professional as well as an individual.
      I promise it will be worth it.

      View full blog article
    • By Jimi Wikman
      In the last 3-4 years I have noticed an increase in the speed of which things are done within companies. By that I do not mean that we produce things faster, I mean that we take decisions or share information faster. That may sound like a good thing, but as always when things are done fast the quality drops. What I see however is even worse and that is that people, often young people, are getting hurt.
      Management is not an easy profession, regardless of position in an organization. There are important decisions to make, ton of information to absorb and people that need to be cared for. This is nothing new, but what is relatively new is a sense of urgency,  that seem to spread to an almost frantic pace these days. In some cases it's more like full panic mode even.
      I have seen organizations that spend more time in meetings than actually do anything on a management level. Some organization even take this to a whole new level. The lack of proper communication and a complete lack of trust within the organization lead to hundreds or even thousands of people who spend most of their days shuffling information back and forth in meetings.
      This is a very, very dangerous situation because when managers process information with no context and little to no actual knowledge of the topic they process then poor decisions are taken. If you add a constant stress to that situation where managers spend 30+ hours in meetings with other managers then the decisions quickly become erratic and irrational.
      I see this in many large organizations these days and I hear it from friends and colleagues in other organizations as well. Most agree that while this has always been the case in management to certain extent, it has never been as bad as it is today. No one seem to think that this is something that will change anytime soon either. Quite the opposite as we have seen this slowly escalate over the years and it has come to the point where people are getting hurt mentally and physically.
      I have seen people pass out in meetings and more than one person that leave mid day to never come back to their work again. I see daily people in the development areas with dark rings below their eyes and tired eyes. I hear people almost weekly that ask to leave their assignment due to health issues or mental fatigue.
      Everywhere I see the same tragic trend and that is that management is running frantically making poor decisions with little to no communication. People are frustrated, confused and more often than not they are becoming defensive as their managers mistrust everything they do. More often than not there will be control mechanisms that are implemented to control rather than improve the work.
      This will make people feel like they are constantly being judged and mistrusted. With an increased pace from the managers demands that comes with unclear information and little to no access to clarification there is no wonder people are breaking down. In some companies there are even activity based offices as icing on the cake to make things even more stressful for the already battered employees.
      People are getting hurt from this and you have most likely seen more than one employee cringe when you mention the Agile word or the Activity based Office. That is not because they are against these things, it's just that they are so abused by managers to avoid taking proper responsibility for making sure that communication and interaction are working.
      There is still hope!
      It is easy to blame the managers for the situation, but the fact is that most managers are really, really great people. They are also suffering from the situation of an increased pace and stress.  I know more than one manager that have taken a time out in the bathroom where they silently cried over their hopeless situation. So the managers are not the problem, it is the collective sense of urgency and lack of control.
      Step 1 - Reduce the meetings.
      Meetings are the cause of many issues today. We have meetings for almost everything with little to no thought of why we have them. Many managers are easily in 20-30+ hours every week and most meetings include 10+ people where half is just there to make sure they do not miss information. If you want to measure something, then this is something to measure to reduce waste of resources and cost.
      Make it mandatory with one full day with no meetings. This allow managers to process the information and make educated decisions what to do next. For best effect, make it the same day for everyone.
      Also follow up on meeting statistics to make sure that no more than 15 hours each week can be allocated to meetings. That is 3 hours each day, which should be more than enough if you have the communication and information strategies in place.
      Step 2 - Establish trust.
      Control is a big problem if there is no trust in the organization. The reason for that is that no matter how well the development teams are doing it will not matter of the management chain can not feel sure about that. If all managers are always sitting in meetings, then how will they get the information they need and how will they have time to forward this information up the management chain? The first step is of course to free up time by reducing the time spent in meetings.
      The second thing is to clarify responsibility. It is very difficult to provide the right information if you do not know what is expected from you. Once you know what information you need to provide, then the flow of information will improve with relevant information.
      Once you clarify responsibility and expectations you will reduce confusion, which in turn will reduce frustration. Clarity also will make it possible to provide accurate information from the development teams when it comes to estimations. This will make it easier for manages to feel that they can trust the information from the development teams. This is done by having clear role definitions and a proper process for clarifying requirements for the development teams.
      Step 3 - Establish proper communication channels.
      The last "easy" fix is to make sure you have communication channels. One thing that I see often is that just to implement a documented decision process will improve the understanding in the organization a lot. If you can understand what a decision mean, why it was taken and who took the decision, then it is much, much easier to understand. Verbal decisions are easily misunderstand, easy to override and easy to ignore. So make sure that important decisions are clearly documented and easily accessed.
      No common way of working is also a big problem. You should define a baseline for everyone to avoid that everyone in your organization create their own way of working. This is especially important in the handover points where you handover information between different groups. If this handover is done in dozens or hundreds of different ways, then that will not only cause confusion and frustration, it will cost thousands upon thousands of dollars.
      Having a common way of working does not mean that you can not have different ways of working. It just mean that you can understand the reason for having a different process as there is some need that the common way of working can not fulfill. The changes are not arbitrary as they are when there are no common way of working.
      Step 4 - Take care of your people
      No matter where you are in the organization you have people around you that you work with every day. Make sure you take a moment on a regular basis and look at the people around you. If you see someone that does not seem to feel well, then make sure you act on that. You can support the person by talking to them and listen to their problems, you can tell your manager or your managers manager and you can contact HR. 
      If we fail to see the people around us that are slowly being broken down from stress, then that person could end up being sick. Some refer to this as "hitting the wall", others being "burned out". This is one of the most devastating events in  a persons life and it is something that you never really get over.
      So take care of yourself, the people around you and please, please....
      stop running, because people are getting hurt.

      View full blog article
    • By Jimi Wikman
      It seems that the terms "leader" and "manager" are used a bit casually when you look at role descriptions and titles. The thing though is that they are not interchangeable, but actually have a very distinct definition in my opinion. Leaders lead and managers manage after all and those are two different skill sets.
      Are you a project manager or project leader? That is a question almost no one ever ask, because in most people's mind they are the same. I would argue however that it is not because for me there is a very big difference between someone who lead and someone who manage.
      A manager manage.
      "Management (or managing) is the administration of an organization, whether it is a business, a not-for-profit organization, or government body. Management includes the activities of setting the strategy of an organization and coordinating the efforts of its employees (or of volunteers) to accomplish its objectives through the application of available resources, such as financial, natural, technological, and human resources. The term "management" may also refer to those people who manage an organization. "
      - Wikipedia
      Someone with the title manager is often someone who do not directly interact with the people they manage. They handle things like finances, stakeholder communication and reporting. In many ways managers work upwards to satisfy the need of those higher up in the hierarchy. People are often handled indirectly by managers and focus is on delivery and the promise given to those higher up in the organization.
      Henri Fayol have a definition I think is quite accurate:  "to manage is to forecast and to plan, to organize, to command, to co-ordinate and to control."
      Managers need strong skills in strategic planning and structured organization. As they often do not directly work with the people they manage they don't need strong charisma or empathic abilities. That is not to say that managers have these abilities, just that it is less required than for leaders.
      Managers focus on the promise of delivery.
      A leader lead.
      "A leader is one who influences or leads others. 
      Leadership is both a research area and a practical skill encompassing the ability of an individual or organization to "lead" or guide other individuals, teams, or entire organizations. Specialist literature debates various viewpoints, contrasting Eastern and Western approaches to leadership, and also (within the West) United States versus European approaches. U.S. academic environments define leadership as "a process of social influence in which a person can enlist the aid and support of others in the accomplishment of a common task"
      Someone with the title leader is someone who directly interact with the people they lead. These are people who manage day to day activities within the team to ensure that the team are doing well. Leaders work downwards towards the team they lead and will shield them from the demands from those higher up in the organization.
      Unlike management, leadership cannot be taught, although it may be learned and enhanced through coaching or mentoring. Erika Andersen, author of "Leading So People Will Follow," says,¬†like most things ‚Äď leadership capability falls along a bell curve. So the fact is that¬†most folks who start out with a modicum of innate leadership capability can actually become very good, even great leaders.
      We can define a leader and someone who possess a degree of leadership. Leadership can be defined as "The act of inspiring subordinants to perform and engage in achieving a goal."

      In order to have others follow you, you need leadership skills and the respect of those that you lead. Empathy is a crucial skill as is charisma and compassion. As a leader you are also responsible for the promise of delivery and need organizational and strategic planning skills. It is just less required than for a manager.
      Leaders focus on the promise to take care of the people.
      Blurred lines between manager and leader.
      It may seem that I make a hard distinction between managers and leaders. I know that the lines between the two are not as cut and dry as this article may suggest. Many managers are also great leaders and many leaders are great managers. The point I try to make is that the titles are not interchangeable, but they actually have a definition.
      I think this is important because as long as we mix these roles when describing what role we actually are looking for, then we will continue to get the wrong skill set. This is even more confusing when adding a role definition based on an ability such as leadership.
      Are you a sword or a shield?
      This is a question I often ask when someone tell me they are a manager or a leader of some sort. Being a sword means that you will sacrifice the people to fulfill the promise of delivery. A shield on the other hand will protect the people even if it means sacrificing the promise of delivery.
      Both of these types of managers are needed in an organization and you can often see the correlation when an organization are over representing one of the two. To many swords lead to a detached workforce and health issues among the teams. To many shields lead to difficulties to grow and economical issues.
      In my perfect world we have a mix of both types throughout the organization. A higher focus on swords are at the top of the hierarchy and a higher focus on the shields are at the bottom. If we combine this with good communication and an organization model that focus work, then you have a perfect work environment.
      So...are you a manager, or a leader?

      View full blog article
  • Create New...