Analytical-Mind

I bumped into Steven last week. Steven is director of application development in a large organization and like most manager in his early forty’s, he looked tired and although he is usually a happy individual, his smile wasn’t radiant this time.

In agreement with his teams, Steven initiated an Agile transition a few months ago. I was part of the team who presented to Steven the benefits of a transition and the impact on the team members and their managers. I saw Steven again in a group training I was giving a few weeks after the beginning of the transition to managers and executives. That time again, Steven was very excited and motivated about what he was hearing, except that during the training I could see the light bulbs over his head and in the questions Steven was asking – how is this going to impact my role as a manager? Steven saw the obvious benefits and understood some of the changes he would need to make to his leadership style but I could tell, it hadn’t fully sinked in.

So here we were, less than 3 months in the transition and Steven wasn’t as chipper as he used to be…

• Me: “Hey, Steven. You look tired. How are you doing?”
• Steven: “I’m OK… I’m tired… [silence] The transition is killing me!”
• Me: “How so?” [I asked anticipating what he would tell me next]
• Steven: “The team is having a blast and I can see their performance has increased compared to the past but I don’t think I can cope with this new approach”
• Me: “You seemed so excited about the transition when we started. What changed?”
• Steven: “I now realize what you meant when you talked about changing my leadership style and my role. I’m still up to the challenge but my boss is totally clueless about all of this”
• Me: “What do you mean? Haven’t you brought him in the loop from the beginning?”
• Steven: “Yes. Yes, I have but that’s not the problem. The team’s performance increase is directly linked to the new approach they have been using and the fact that I leave them a lot of autonomy but my boss still asks me to behave like I used to – like he manages his team today. That’s where it hurts the most. I can pretty much deal with everything else but I feel like I’m stuck between a rock and a hard place”

Unfortunately, we (as consultants) do not do such a good job at highlighting this fact before we begin a transition. We work closely with the teams to help them adopt better methods and practices, to increase their overall performance by allowing them to be self-organized. We work on getting the teams to a highly performing level. Then we go get executive sponsorship to secure the initiative (and the budget) and make sure we get support to handle difficult issues but what about the people in the middle?

We develop training programs for Agile managers and we support them with organizational coaching but we don’t do such a good job at telling them upfront how much pressure they will be under once the transition begins. How much their role is likely to change and their leadership style needs to be adapted to the new reality.

For those who haven’t yet have felt the pressure, here are some examples of what to expect:

• You may be willing to trust your team and let them self-organize but is your boss in agreement with this new approach? Will he be as involved (micro-managing) in your activities as he used to be? And more importantly, will he be expecting you to be as involved with your team as you used to be?
• You may be willing to tolerate mistakes in order to increase your team’s learning and with a strategic perspective to increase long term performance but will you hear about your inabilities to control your team during your next performance review?
• You already produce status reports, dashboards, emails and others information to keep everyone (including your boss) informed of what is going on in your unit. Will you need to translate everything that the Agile team is producing to fit the traditional reporting mechanisms? Can you challenge what information is currently being produced to ensure it does bring value to people?
• You expect your team members to handle the details of their activities and you believe in actually seeing (touching, feeling) the end results while your management team expects you to assess progress using Gantt charts. Do you need to educate your entire organization to the new approach? Does the fact that you are adopting Agile make you the evangelist for the entire organization?

Obviously, I don’t mean to scare anyone – especially the managers – with regards to adopting Agile. The approach has a lot of merit and value for many organizations but in order to help with adoption, coaches and consultants need to pay attention to the people in the middle and help them find their new place, otherwise we are very likely to find serious resistance and potential failure of such initiatives – nobody likes to be stuck between a rock and a hard place…

My colleague François Perron launched a very interesting discussion on our private wiki – “As a coach, what to do when executives and upper management force the project team to do over time in order to meet deadlines?”.

As you can probably guess, this initiated very interesting discussions and an obvious reaction to such an approach.

Everyone agreed that due to the project visibility and the position of the organization within its market, the project launch date was critical. Everyone also understood that the organization had very few options so nobody debated the need to achieve results. The discussion was strictly around which measures to use in an Agile context.

I’ll admit up front that I am biased toward intrinsic motivation (I really loved Drive by Dan Pink) and the fact that it is well suited for an agile environment.

As such, my first impression to the conversation that was going on were:

• Does the organization wish that employees spend more hours at the office (attendance) or would they prefer more engagement (commitment)?
• If their choice is to increase the hours of attendance, imposing overtime will achieve this goal while giving them a false sense of increased performance. People will show they are working longer hours but the real throughput is unlikely to be much higher. In addition, software development is a brain intensive activity and reducing the amount of rest people get is likely to increase the number of mistakes they make.
• On the contrary, if the organization wanted more involvement, the inclusion of team members in determining the best way to achieve the results would probably come to a better decision – even possibly leading the willingness to do over time

It appears to me that by forcing overtime, the executives and senior managers will probably collect their bonus and congratulate each others in the short term only to realize in the longer term that they have simply pushed the problem forward for others to deal with – and possibly request more over time in the long run.

At the Agile 2010 Conference this week, out of the two hundred or so sessions presented, a number of them talked about the role of the manager in an Agile team. A few people believe managers are no longer necessary once the team has self-organized while others say people managers are still required. Either group failed to provide compelling arguments for their position.

The notion of self-organized teams keeps gaining visibility and acceptance. Those who have adopted the approach can’t stop talking about the benefits. At the same time, people realize that managers are unlikely to disappear from the organizational landscape anytime soon. In this context, it is with a mixed-feeling that Agilists talk about the role of the people manager in an agile organization – mostly as something not so useful but that the team needs to keep around in order to maintain their autonomy – something similar to the appendix.

The most common explanation for the appendix’s existence in humans is that it’s a vestigial structure which has lost its original function – source wikipedia

Then a few things happened.

First, I got to attend Michael Spayd‘s session called “Blueprint for an Agile Enterprise: Plans, Tools & Tech to Build a Human Enterprise”.

Want your whole organization to be more like an Agile team? Starting teams is well understood; expanding Agile to the organization is definitely not. Using 8 years experience applying organization development to Agile, we’ll unfold a 7 layer organizational architecture for building a human enterprise. Each level has an overall perspective, specific tools and key practices. Part tutorial, part demo, we’ll create a change plan for one participant’s organization, exploring culture, leadership, change, team performance, and management’s role. You’ll leave with a plan template and many ideas – source Agile 2010 Program

Then, I went to Damon Poole’s session called “Getting Managers and Agile Teams Out of Each Other’s Hair”.

One of the most talked about and least well understood concepts in Agile is the “self-managing” team. This session will provide a new perspective on self-management by examining the external roots of the practice and by taking a bottom-up look at what it is, the benefits, and how it works. We’ll see how twelve widely adopted Agile practices contribute to self-management by reducing and/or redistributing traditional management activities. These practices provide a framework for delegation, communication and coordination; and encourage team ownership, commitment and accountability – source Agile 2010 Program

Finally, I also attended Jim Highsmith session called “What do Agile Executives and Leaders Do?”

In some circles agile executives and leaders are admonished to buy pizza and get out of the way. In others they are asked to be supportive of self-organizing teams. But leading agile organizations requires more. There are specific activities that help build agile organizations that can weather business turbulence. This session will explore those activities that an agile leader or executive must “do,” including: revising performance measurements; facilitating self-organizing teams; developing strategies for operational, portfolio, and strategic agility; and assessing how agile to be source Agile 2010 Program

After the sessions, I sat in the lobby of the conference and read some of the blog feeds I subscribe to and came across these…

• Esther Derby’s ONE-ON-ONES WITH SELF-ORGANIZING TEAMS
• VersionOne’s Self Organizing and the “M” word

Obviously, something’s up!

The role of a traditional people manager

In many organizations and depending on their level, people managers are expected to plan, direct, organize and control (Deming‘s Plan-Do-Check-Act) – more specifically, the role of the manager is to:

• Define the individual objectives
• Assign work to team members
• Determine priorities of the tasks
• Monitor progress of the activities
• Make decisions for the team
• Get visibility into the work of the team
• Mentor and train employees
• Protect the team’s financial and human resources
• Provide career development opportunities
• Build relationships with other departments and teams
• Motivate the team members
• Communicate information

What self-organization removes from the equation

Once the concept of self-organized team is implemented, there are a few things that were traditionally the responsibility of the people manager that now fall on the team. The activities are:

• Assigning work – team members now select their tasks instead of the manager
• Determine priorities – team members now determine the order in which they should to complete their work
• Monitor progress – team members track their own progress and make it visible and accessible to those who need to know
• Make decision for the team – within the team, team members get to make their decisions
• Get visibility into the work – team members track their own progress and make it visible and accessible to those who need to know
• Mentor and train employees – when possible, team members may decide to implement a mentoring program within the team
• Motivate – self-organized individuals are known to be more motivated than traditional teams, hence the reduced need for the people manager to retain this activity

So what is left for the people manager?

In order for the people managers to transform into Agile leaders and feel as part of the team, we already stated they need to modify their role. The agile manager will achieve higher level of performance and possibly increased personal job satisfaction by macro-managing – working with an increased perspective as opposed to getting into the details. As such, the activities the agile managers need to retain are to:

• Define high level objectives for their team and department instead of focusing on the tasks
• Determine priorities in the objectives of the team and department instead of the activities
• Monitor progress toward achieving the objectives
• Coach employees
• Continue to protect the team’s resources
• Support employees in their career development
• Build relationships with other departments and teams

I realize that this type of transition is easier said than done but with the willingness to recapture an important role as part of the team and with some external help, the traditional managers don’t have to became extinct professionals.

So you have initiated an Agile transition and have faced some resistance to change! Or maybe, you assessed your current level of Agile Maturity and are hoping to achieve the next level. Better yet, you and your team are planning to launch an Agile transition that is not driven by the wrong reasons.

That’s great!

If you haven’t already done so, you may want to read: Getting Started – Reference Material for Managers Who Wish to Understand Agile and Scrum and What consultants don’t tell you before you begin an agile transition.

Let’s cut the chase and get to the point. Are you ready? Here it is. The secret to a successful Agile Transition -> Make people look good!

Yes. That’s it. Surprised?

I’m not talking about psychological manipulation. I’m talking about finding what drives the people you are working with and the managers around them and then capitalize on their drivers in order to get them to get on board with the transition – and better yet become evangelist for your transition. Here are some examples:

• Suzy is hoping to get promoted to Vice-president within her organization. She heads a business line from which you need support and a dedicated Product Owner. Why don’t you explain to Suzy how innovative her group would appear to others if she agreed to embark on the Agile initiative?
• Peter is struggling to increase the performance of his group. So far, he hasn’t shown much interest in the transition but you found out that he has been under high pressure from his manager to increase the performance of his team. Why wouldn’t you show Peter how using an Agile approach could help get his manager off his back?
• Monica is a project manager who has lost several key people in previous months. She is usually by-the-book (i.e. PMBoK) but during a recent lunch, she admitted that she would be willing to try something different if only it would help her retain the contributors she needs to make her project successful. Why don’t you take this opportunity to get the project manager on board with Agile by offering to help her?

Don’t get me wrong. I am not asking you to lie, to cheat or to fake the objectives and expected outcome. I’m telling you to get others on board and working WITH you by telling them the whole story and helping them understand that there is something in it for THEM too.

Agile relies heavily on communications and interactions. Why don’t you start with all the people directly and indirectly impacted by the transition? Sure, it will require more time in the short term to influence people into supporting you but in the long run, you will be glad you did it.

Go ahead. Try to figure out what drives people around you or what issues they are facing. Find a solution that can help them and you’ll end-up with a win-win scenario and a successful transition.

As an Agile coach and working for a consulting organization that specializes in Agile Software Development, I get to meet people who have decided to adopt or are thinking of adopting Agility within their organization.

I have to say, most people understand what an Agile transition means for them and their organization and are willing to make the changes required to make their transition a success.

And then, there are others who are most likely adopting Agile for the wrong reasons and as such, aren’t really interested or even aware of what it means for them.

I’ve put together a short list of 7 (real life!) conversations that made me wonder if common sense had left the building. Feel free to share your conversations…

Time estimates

• Client: I don’t understand. Since we’ve adopted Agile, our developers consistently exceed the time estimates for their tasks.
• Me: Interesting. Who provides the time estimates?
• Client: The project manager…

Change Management

• Client: We are really serious about implementing Agile within our organization.
• Me: Great! You realize Agile is not a silver bullet that will magically eliminate all your issues?
• Client: Of course, we are fully aware. We would like to start with a new project that is scheduled to start shortly.
• Me: Good. Following our earlier conversation, you realize you will have to make changes to the way your team is currently working and that might impact their productivity in the short term.
• Client: We can’t impact the team’s productivity. The project budget, scope and time lines have already been defined and the project is already 2 months behind schedule…

Trust

• Client: We have identified a list of issues that we need help with. Here’s the list. Can you help us?
• Me: Possibly. Let me look at your list. Who came up with the items on this list?
• Client: Me and my direct reports.
• Me: Has the team been involved in putting this list of issues together?
• Client: Absolutely not. We asked them to put together a list of issues they were facing and most of the items were related to lack of trust, micro-management, and bad communication so we threw out their list and put this one together for them…

Retrospection

• Client: We are just about to begin a new iteration but our last iteration was a disaster. We missed our time lines, the product owner is upset at the development team and morale is very low.
• Me: Have you done a retrospection at the end of your iteration?
• Client: No. We need to start development on the new project immediately.
• Me: Wouldn’t there we be value in evaluating what went wrong in order not the repeat the same mistakes?
• Client: We don’t have time for that and quite honestly, we don’t want the team’s morale to get worst once they realize how bad the situation is…

Management Support

• Client: This Agile thing is great! I’m going to impress the management team with our success.
• Me: How so?
• Client: The development team asked me if they could use Agile for their next project and from what I read, Agile can help them improve their performance and reduce the time to market.
• Me: Yes, if it’s done right you may get those benefits.
• Client: Wonderful! After I gave them the go ahead to start immediately, I told them I now expected to project to be delivered in 9 months (instead of 18 months) and cut their budget by half…

Collaboration

• Client: Agile has done good things for our development team but we keep facing issues with project members that don’t report into our department.
• Me: Who are those external contributors?
• Client: The architects and the DBAs.
• Me: Do you keep them informed of your project progress? Do they get involved in defining the stories? Do they estimate their work?
• Client: Hell, no. We simply assign them the work they need to do and complain to their boss if they fall behind…

Scrum Master

• Client: I don’t understand why things aren’t working well.
• Me: What is the issue?
• Client: We took the Certified Scrum Master training you offer, we read a few books, and we’ve started implementing Scrum but nothing seems to be working.
• Me: What do you mean?
• Client: The only thing we didn’t do is take a natural leader to be the Scrum Master. Robert was available so we asked him to be the Scrum Master.
• Me: Who is Robert?
• Client: Robert has been with the company for 22 years. He’s one of the few Mainframe project managers who preferred not to learn the new web technologies and since he didn’t have any assignments, we thought he could do the job…

Do you have any hints you would like to share?

As a follow-up to my post on Agile Leadership, I have described the 7 dimensions of an Agile Project Team and what it means to deliver results in an Agile context. This forth (out of five) post briefly looks into the Agile Work Environment (or Agile Work Space) to successfully support the delivery of results by the project team.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done – Principles behind the Agile Manifesto.

As suggested by the Manifesto, providing the right environment will support a fast paced, entrepreneurial, flexible and autonomous culture allowing the project team to focus on their objective while enjoying their environment.

A few questions to assess the work space configuration of the project team:

• Are all team members co-located?
• Does the physical environment support effortless communication?
• Are team members within 10 meters (30 feet) of a white board?
• Are team members allowed to stick post-it notes to the walls around them?
• Does the project team have access to natural light?
• Are team members allowed to decorate their work space?
• Do the project team members have access to free good-coffee?
• When necessary, do team members have access to private rooms to concentrate on their activities?

Needless to say, the right work environment can have a significant impact on the project team’s performance. More specifically, the right work environment should support the team’s autonomy, ability to communicate and collaborate. It should support the use of the right processes and tools to be efficient while allowing them to enjoy their surroundings.

Agile Leadership is the application of the Agile principles (as defined in the Agile Manifesto) to the leadership of software development endeavours.

In addition to encompassing the processes, tools and rules of Agile Scrum, Agile Leadership extrapolates them to change how teams and projects are managed within the context of the work environment and new leadership paradigms to deliver better results.

Agile Leadership Model

Where Agile Scrum mostly focuses on the organization of the project team, the roles and responsibilities of the team members, the artifacts, and the rules under which the project team operates, Agile Leadership includes the work environment as well as the specific leadership abilities expected from the managers and stakeholders.

Agile Leadership is a fundamental paradigm shift with the objective of making the project team successful and the people within the team happier in order to deliver better results. The shift mostly comes from the leadership (aka management style) and the rules used to govern the actions, the behaviours and the outcome of the team.

Getting managers to become more Agile requires changing behaviors and to use a more democratic approach to management. More specifically, Agile Leadership requires to:

• Transfer certain powers to the team members themselves to let them determine how best to accomplish their tasks;
• Empower the project team through self-organization and commitment to results;
• Transfer decision-making to individuals who are closest to the activities;
• Demonstrate a greater openness to ideas and innovations emerging teams;
• Clearly define the desired vision and to adapt to the context of each team to ensure alignment with the overall objective of the project and to ensure cohesion between the team members;
• Provide the necessary support and resources to the project team so they successfully accomplish the expected results;
• Become a change agent within the organization by accepting and publicly endorsing the idea that the status quo is not acceptable and that the old methods are no longer adapted to the new reality;
• Systematically involve business people in the definition and execution of solutions;
• Adapt the style of management so as to use an inclusive and democratic approach.

In addition to bringing new concepts, Agile Leadership also revisits and adds to some of the concepts on which Agile Scrum relies. There is already much documentation (books, blogs, podcast, etc.) on the topic of Agile. In an upcoming blog post, I will add details to the areas of focus listed below and associate the underlying concepts with theories explained at length elsewhere in other areas of expertise such: as organizational behavior, organizational development, management science, and coaching.

A few days ago, we invited representatives from a potential customer over to visit our office. They are seriously considering a transition to Agile but some of the managers had questions with regards to what an Agile work space could look like. The potential customer is a large insurance company and like most insurance companies, people working there are used to a traditional (very traditional) work space. We could see they had some reservations about the open-concept before coming for a visit.

Their visit lead me to wonder what other Agile work spaces could / should look like, so I came up with the idea of launching a friendly contest…

The “Best Agile Work Space” Contest

I invite you to email me a picture of your Agile work space (martin [at] analytical-mind.com). In the spirit of sharing best practices and getting ideas from each other, I will post your pictures and your company’s name for people to get inspired. You can also share with everyone what makes your work place the Best Agile Work Space. We’ll even ask people to vote!

Let the contest begin to determine the “Best Agile Work Space“. Tell your friends to email their pictures.

Examples of other Agile Work Spaces found on the web

Windows are often a scarce commodity and are doled out to an organization’s favored employees. One of the nice things about an open workspace is that windows are shared. Even if the view is only of our parking lot and can only be seen across three messy desks, at least I can see the window and some natural light - The Ideal Agile Workspace | Mike Cohn’s Blog – Succeeding With Agile®.

Our New Agile Workspace - Our New Agile Workspace on Flickr – Photo Sharing!.

I started to respond in his comments and then remembered that it would be better to capture our workspace on video to share with others.  I am hoping other agile shops will do the same.  We are always eager to see how others are doing things so we can continue to improve - Attempting to Achieve the Ideal Agile Workspace | Derek Neighbors.

Ward Cunningham among others was a big influence early on in making it happen.  The patterns & practices team workspace is optimized for agile development practices.  The workspace features writeable walls, configurable workspace, speaker phones, projectors, focus rooms, and a customer room - Shaping Software » Blog Archive » Microsoft patterns & practices Agile Workspace Tour.

Welcome

If you did not already notice, Pyxis is a different company. You have surely seen that the number of smiles per hour is much higher than in traditional organizations. There are several reasons contributing to this phenomenon but for now we just want to explain the governance model used so that you understand exactly what is expected of you.

What is governance?

Corporate governance is the set of processes, customs, policies, laws, and institutions affecting the way a corporation or company is directed, administered or controlled. Corporate governance also includes the relationships among the many stakeholders involved and the goals for which the corporation is governed. - Corporate governance – Wikipedia, the free encyclopedia.

What is the management philosophy?

The management philosophy of François relies heavily on the work of Peter Block and more specifically on the audio book “The Right Use of Power: How Stewardship Replaces Leadership“. If you do not know this audiobook, we invite you to invest 3 hours to understand the philosophy. The alternative is that you will have to reconstruct the enigma over the coming weeks, so this is certainly a good investment.

What does it mean to work at Pyxis?

Before going further, it is important that you know the values and mission of Pyxis and our perspective of capitalism in the 21st century. Then comes the most difficult challenge for a new employee, you must rid yourself of your mental model of a traditional business because most of your references will not apply at Pyxis. Want examples?

What are the teams at Pyxis?

Pyxis works in “communities“.

What do I do now?

If you have more questions than answers after reading this page, it’s normal. Most people need time to assimilate new concepts and our mode of operation. If you have questions, ask them to the people around you or help others by adding them to our wiki.

Does your organization’s compensation model and your personal attitude support prostitution?
[Note: The definition of prostitution is provided at the end of the blog post. In the context of this post, I am referring to the second and less often used definition.]

The Scenario

As the head of a large Information Technology department, you walk by Michael’s desk one afternoon and to your surprise, you notice that your system administrator is frantically switching from Google to Chat to a discussion Forum. You recall similar observations a few weeks ago so you quickly wonder if, at $80K per year, you are getting your money’s worth for a system administrotor who always seems to browse the internet. To make matters worst, you don’t even remember when was the last time your company ran into serious systems issues. Do you need Michael on your team? Maybe he is a good candidate for the headcount reduction you have been imposed by Finance.

A few days later, on your way out of the office around 7:15 pm you hear key strokes and notice that Kim is still working. You remember approving Kim’s over time report last month and start to realize that the increase in ERP support calls might be starting to impact Kim’s work-life balance. Remembering your conclusion about Michael, you wonder if you shouldn’t close the system administrator position and add resources to Kim’s team. At $55K per year, you would still be able to cut your budget spending. Pleased with your conclusion, you briskly walk to your car hoping for a nice family dinner.

A New Concept

Here’s a new concept. For people working in most traditional organizations, this will sound like a really weird concept but what if employees decided their own working hours? I’m not talking about the flex time concept where people decide what time they wish to start and end their work day but actually decided how many hours and which hours they worked?

Typically, the traditional work week varies by company and by country. A standard work week in Canada is somewhere between 35 and 40 hours per week. Some would argue they work many more hours per week but that’s not where I want to take this discussion.

Imagine for a moment you stopped controlling the hours worked and focused instead on the results. Granted, this is a much more complex endeavor but in my opinion much more suited to year 2010.

The Old Paradigm

At the beginning of the industrial age, many employees were paid “by the piece”. For every bolt fastened, shirt sowed, or widget delivered they received a small amount of money. Eventually, companies realized that it would be more predictable and easier to manage if people were paid by the hour. Needless to say, the model has somewhat evolved and employees are currently paid by the hour, by the day, by the week, or by the year but the model pretty much remains the same.

The New Paradigm

The new model I’m proposing is to offer a fixed salary (or a risk salary), without any expectations of number of hours worked. Instead of expecting people to work 40 hours per week, people would be expected to deliver value or results. As I mentioned, it is certainly more difficult to set up the type of results expected but on the other hand, isn’t this the basis of commerce – I pay you $x for this good or service without any consideration about how many hours were required to produce it. The production piece is the responsability of the seller, not the buyer.

Back To The Scenario

Pleased with the previous day’s conclusion, you call into your office Michael and Kim’s direct supervisor to share your thoughts. Michael’s boss explains that since hiring him 2 years ago, systems outage have dropped 92% as Michael is consistently looking for ways to improve systems availability. He heavily praised Michael for creative and pragmatic solutions and despite the fact the Michael rarely has to do overtime, he would recommend him for a promotion.

Slightly shocked, you turn to Kim’s boss and ask for comments on her employee. With a grin on her face, Kim’s manager tries to hold back her answer as it certainly wouldn’t make you look good. She explains that Kim clearly lacks analytical abilities which is why she has to spend more time than all her colleagues solving similar issues. In addition, Kim is a poor team player. She likes to think of herself as a super-hero and she prefers trying to handle problems without the help of her team mates which often leads to repeated issues as the root problems are rarely solved properly the first time around. Despite many attempts at helping Kim with her shortcomings, she doesn’t feel the need to improve since she is often praised by the head of the department for putting in long hours…

(Silence in the room)

Embarrassed and apologetic toward both managers, you realize your attitude toward the number of work hours per week may have had the opposite effect that you were originally looking for. You genuinely thank your employees for their valuable feedback and wonder if you shouldn’t aim to leave early today…