Skip to content

Posts tagged ‘Management’

Agile managers do not act like cowboys

Image by anyjazz65

Managers are expected to get their teams to deliver on the objectives that are established. Managers are also expected to keep their people happy and motivated. How can one accomplish these two seemingly incompatible expectations?

Let’s first distinguish management from leadership.

Management books often make a distinction between managers and leaders, depicting leadership as if it is more about heroics than management. […] Managers are then advised to transform themselves to leaders, turning employees into willing followers, instead of herding them like sheep. […] Separating leadership from management is like comparing women to humans. It doesn’t make sense. […] Comparing women to men seems more logical to me. – Management 3.0: Leading Agile Developers, Developing Agile Leaders

I agree with Jurgen that leadership is one of the ways to accomplish a manager’s role.

Along the same lines, I hear from time to time conversations within Agile circles and read Agile related blog posts promoting soft leadership, leading without authority and laissez-faire [The latter is sometime mistakenly perceived to be self-organization. Self-organization is something else and requires clear boundaries, but that’s for another post] as the answer to the management conundrum. Is that really the silver-bullet?

In almost all organizations, the manager’s role is fairly similar.

Management in all business and organizational activities is the act of getting people together to accomplish desired goals and objectives using available resources efficiently and effectively. Management comprises planning, organizing, staffing, leading or directing, and controlling an organization (a group of one or more people or entities) or effort for the purpose of accomplishing a goal. […] Since organizations can be viewed as systems, management can also be defined as human action, including design, to facilitate the production of useful outcomes from a system. This view opens the opportunity to ‘manage’ oneself, a pre-requisite to attempting to manage others. – wikipedia

For a large number of individuals in management responsibility, authority is perceived to be the most effective tool to ensure compliance and to get people to do with is expected. Please bear with me, the analogy isn’t perfect but the image is powerful. For me, authority is similar to carrying a gun [or whatever your preferred weapon happens to be].

It is easy to obtain compliance and get people to do what we tell them to do when we – the managers – are the only people carrying a weapon. It is especially true if the weapon is constantly out of the holster and pointing directly at the team [figuratively speaking, of course]. So authority gets us compliance (for most part) and may allow us to meet our objectives (some of the time) but authority doesn’t bring the best out of people. Authority certainly doesn’t make people happy and motivated.

On the other hand, if we aim to keep people happy and motivated first, we are more likely to adopt a laissez-faire approach.

Lewin often characterized organizational management styles and cultures in terms of leadership climates defined by (1) authoritarian, (2) democratic and (3) laissez-faire work environments. Authoritarian environments are characterized where the leader determines policy with techniques and steps for work tasks dictated by the leader in the division of labor. The leader is not necessarily hostile but is aloof from participation in work and commonly offers personal praise and criticism for the work done. Democratic climates are characterized where policy is determined through collective processes with decisions assisted by the leader. Before accomplishing tasks, perspectives are gained from group discussion and technical advice from a leader. Members are given choices and collectively decide the division of labor. Praise and criticism in such an environment are objective, fact minded and given by a group member without necessarily having participated extensively in the actual work. Laissez-faire Environments give freedom to the group for policy determination without any participation from the leader. The leader remains uninvolved in work decisions unless asked, does not participate in the division of labor, and very infrequently gives praise. – wikipedia

When nobody carries a weapon, such as in the case of laissez-faire leadership style, people are freer to select goals that appeal to them and are more likely to be successful at reaching their objectives. Unfortunately, managing people (as in the wikipedia definition “getting people together to accomplish desired goals and objectives”) becomes extremely difficult and maybe impossible in a business context (trust me, we have tried that unsuccessfully).

To be an agile manager doesn’t mean to avoid using authority and to strictly rely on our influencing capabilities. It doesn’t mean to let people determine the business orientation that the organization will be taking either. As in many fruitless debates, taking an “either or” perspective doesn’t lead to the best answer. Agile managers need to be able to use authority, but not as their primary tool.

Let me explain.

Agile managers need to take the time to explain the objectives they aim to achieve and get people to follow them (leadership) into attempting to reach the objectives. Just like good diplomats, agile managers should begin with good listening skills, influence, and negotiation when they are faced with people resistance and challenges. Only in extreme cases should we turn to authority to get people to do what we need them to do. Like many things in life, using authority comes at a cost (diminished commitment from the team, reduced motivation) and as such, should be used wisely.

This leads me to my last point. In addition to management skills, people’s tolerance to stress needs to determine if they should be entitled to manage a team. As most psychometric tests can tell, we – humans – tend to operate differently when we are within our comfort zone (low stress) or outside our comfort zone (high stress). While in our comfort zone, we usually take advantage of many of our built-in or acquired skills which doesn’t increase one’s anxiety level. By contrast, stepping too much outside our comfort zone leads to decreased performance and substantially increased anxiety levels. People for who management is within their comfort zone or people who have better abilities to deal with stress are less likely to use authority as their primary tool. As such, agile managers are more likely to wait until the situation is critical before they even think of going “Clint Eastwood” on people.

So next time you are thinking of promoting someone in a management position, do not simply look for their skills. Assess their ability to manage their stress level.

Real-life laboratory for human experiments – The case of an Agile organization

Our organization is well known in Canada, France, and other French speaking countries around the world as a leader with the Agile approaches. We are one of the few organizations in North America with over 20 full-time agile coaches (employees).  For most part, our governance model relies on self-organization, the absence of hierarchy, and transparency in our decisions. This is what is well known from customers who have worked with Pyxis and potential employees who wish to join the organization, but what is much-less known is how Pyxis is a real-life laboratory for management, organizational behaviours, and team dynamics.

Most of the people who come in contact with people at Pyxis or who have worked with us will agree that the organization is different and throughout this year, I will share some of the inner working of our organization.

Pyxis helps software development companies to become places where results, quality of life, and fun coexist sustainably by being first and foremost an example of what it proposes to its clients and by coaching them.

We help our customers transition to Agile because we know it works – not because it is written in books but because we have been living the Agile way for 10 years now.

As the first post on the inner working of our Agile organization, I will explain the root cause of this difference. More posts will follow on self-organization, agile management, governance models, and growing a profitable organization by leveraging people’s inner motivation (remember autonomy, mastery and purpose?).

The fundamental reasons why Pyxis is different

After observing the organization from the inside for over two years, I have had the opportunity to appreciate that we are fortunate (and one of very few organizations) to have a real-life laboratory for human experiments – no, not the kind usually reserved to white rats. Our structure allows us to experiments with governance models (the way people are managed) and observe first hand the organizational behaviors that arise and the impact on team dynamics. We pride ourselves as being an incubator for highly performing teams and as such, we often experiment new concepts within our organization before trying them out on our clients – which is not often the case in consulting, but I digress…

The first reason behind our uniqueness is the philosophy of the founder. François sees the world differently from most people and although he has an opinion on many topics, his real contribution is that Pyxis is not a profit-maximizing organization. Like every organization, Pyxis wishes to generate a yearly profit but that is not the reason why Pyxis was originally created. Pyxis was born with a purpose to improve how software development is made and more importantly to improve the quality of life of people within those organizations.

This is critical to understand the organization because it leaves rooms for experiments (making mistakes is a critical part of learning), for employee satisfaction (people truly enjoy working at Pyxis), and deliver great results (highly motivated employees deliver better results).

There are other reasons why the organization is different but in my opinion, this one is fundamental.

The Surprising Truth About What Motivates Us

Picture by topshampattiIf you work in an Agile environment or better yet, if you manage people who have embraced the Agile principles, you have certainly bought into the concept of self-organized teams. The underlying assumptions are that:

  • People are more motivated when they are self-organized;
  • People take their own commitments more seriously than the commitments made by others on their behalf;
  • Teams and individuals are more productive when they are not interrupted;
  • Teams improve when they can settle their own issues;
  • Changes in the composition of the team affect the productivity of the team members;
  • Face-to-face communication is the most productive way to share information.

Needless to say, management hasn’t changed much in a hundred years with its need to control and its chief tools remain extrinsic motivators.

Taylor believed that work consisted mainly of simple, not particularly interesting tasks and that the only way to get people to work on them was to incentivize them properly and monitor them carefully. Later on, Maslow developed the field of humanistic psychology in the 1960s (which questioned the idea that human behavior was purely ratlike seeking positive stimuli and avoiding negative stimuli) and McGregor challenged the assumption that humans are fundamentally inert (in the absence of external rewards and punishments, we wouldn’t do much).

In his most recent book (Drive: The Surprising Truth About What Motivates Usaudiobook format), Daniel Pink presents many factoids taken from scientific researches to demonstrate how people can (and can’t) be motivated. Although the author brings a scientific perspective to people motivation, the book is easy to read in addition to being entertaining.

Scientists then knew that two main drivers powered behavior. The first was the biological drive (comes from within) and the second comes from without – the rewards and punishments the environment delivered for behaving in certain ways […] The third drive – performance of a task provides intrinsic reward. The joy of the task is its own reward.

Autonomy, Mastery, and Purpose

In his book, Pink states that human beings have an innate inner drive to be autonomous, self-determined, and connected to one another.


The opposite of autonomy is control. Control leads to compliance; autonomy leads to engagement.

Pink’s book provides valuable scientific explanations to the concept of self-organised teams. He presents the ROWE (Results-Only Work Environment) concept and the Self Determination Theory (SDT) to demonstrate the relationship between autonomy and well-being. He goes further to associate autonomy with higher productivity, less burnout, and greater level of psychological well-being. More closely related to software development, the author presents the level of authority given to employees at software giant Atlassian where people decide: what they do, when they do it, how they do it, and whom they do it with.


The desire for intellectual challenge (the urge to master something new and engaging) was the best predictor of productivity.

Daniel Pink explains that people are motivated by self-development and learning of new skills or developing existing abilities. The actual challenge of mastering a discipline is often a better motivator than money can be (assuming a minimal level of income). Similar to children who easily get motivated with playing – which is a way for them to learn and master a skill – managers can leverage that ability to motivate individuals.

As such, human beings are said to have an inherent tendency to seek out novelty and challenges to extend and exercise their capacities to explore and learn – which are in themselves powerful motivators.


The science shows that the secret to high performance isn’t our biological drive or our reward-and-punishment drive, but our third drive – our deep-seated desire to direct our own lives, to extend and expand our abilities, and to live a life of purpose.

The author points out that many psychologists and economists have found that the correlation between money and hapiness is weak – that is past a certain level, a larger pile of cash doesn’t bring people a higher level of satisfaction. As such, contrary to traditional motivational techniques, money does not increase happiness and performance – some research have actually demonstrated the opposite effect! It is possible to keep people highly motivated without constantly leveraging money as a motivator.

Human motivation seemed to operate by laws that run counter to what most scientists and citizens believe. When money is used as an external reward for some activity, the subjects lose intrinsic interest for that activity. Rewards can deliver a short term boost but the effect wears off and worse can reduce a person’s longer-term motivation to continue the project.

In direct contravention to the core of tenets of motivation 2.0, an incentive designed to clarify thinking and sharpen creativity ends up clouding thinking and dulling creativity. Why? Rewards, by their very nature narrow our focus. That’s helpful when there’s a clear path to a solution. They help us stare ahead and race faster but “if then” motivators are terrible for challenges. The rewards narrowed people’s focus and blinkered the wide view that might have allowed them to see new uses for old objects.

Carrots and Sticks – The Seven Deadly Flaws

  1. They can extinguish intrinsic motivation
  2. The can diminish performance
  3. The can crush creativity
  4. They can crowd out good behavior
  5. They can encourage cheating, shortcuts, and unethical behavior
  6. The can become addictive
  7. The can foster short-term thinking.

The relation to software development

Algorithmic tasks are tasks in which an individual follows a set of established instructions down in a single pathway to one conclusion. That is, there’s an algorithm for solving it.

A heuristic task is the opposite precisely because no algorithm exists for it, individuals have to experiment with possibilities and devise a novel solution. Software development is a heuristic task.

During the twentieth century, most work was algorithmic but as McKinsey & Co. estimated that in the United States, only 30 percent of job growth now comes from algorithmic work, while 70 percent comes from heuristic work.

Researchers have found that external rewards and punishments – both carrots and sticks – can work nicely for algorithmic tasks but they can be devastating for heuristic ones.


If you need scientific explanation and useful examples to explain to people around you why a self-organized (autonomous) team with team members who are striving to develop their skills in an attempt to reach a common purpose is possibly the most impactful motivator, you may want to read this book.


Survey results are in… People would wonder about their management style

The results are in!

In the survey I recently posted, to the question How would you react to bad news? most people would “wonder if their management style had anything to do with the current situation”.

How would you react to bad news?

Rest assured, this survey didn’t pretend to be scientific and the statistical method could easily be challenged. Nonetheless, it is nice to see that people would display what I would think to be the right behavior.

I can’t quite understand why 21% of the people would curl up in a foetal position :-p

How do you react to bad news? Assess your management skills

Picture by dsevilla Have a few minutes? Want to quickly assess your ability to react to bad news? Try this short exercise.


Working for a large multi-national organization, you are the head of a 40 people software development team. Your team’s ability to deliver on their commitment continues to decrease despite implementing new measures to help boost productivity.

During a recent lunch meeting, you were informed that things on the floor are really bad by one of your external partner. In an attempt to help you, the partner offers to present some key findings about your team – their processes, their tools, their skills, their environment, etc.

In order to share the suggestions of your external partner with your team, you invite your direct reports (managers) to the presentation. It’s a sunny day outside and despite some technical glitches, the consultants begin the presentation by stating the objective of the meeting and inform you they intend to be very candid. After a few introductory slides, the real content of the presentation begins…

Slide 6

Lack of Team work

  • No ownership of the project by the team members
  • No shared commitment by the team members
  • Team members not working with a common goal in mind
  • Seperation of responsabilities leads to a silo work environment


  • Lack of efficiency
  • No sharing of knowledge
  • Team members have no common focus

Slide 7

Lack of Technical Skills

  • Testing (Unit, Functional, Acceptance) non existant
  • No knowledge of Object Oriented Programming
  • No knowledge of Web Development Skills
  • Sound engineering practices absent
  • No time for learning


  • High and increasing number of bugs
  • Quality is constantly low
  • Maintenance costs are increasing
  • Will have a negative impact on future projects

Slide 8

Difficult Work Environment

  • Micro management and interference by management
  • Lack of communications and transparency
  • Maintain a culture of fear and blame
  • Dictates the ways of working
  • No time for learning


  • Overall unpleasant work environment
  • Team members want to quit the project
  • Overall quality is suffering

How would you react?

Enter your answer below. I will publish the results shortly.

We need better management – we need agile management

As mentioned in my guest post on Management 3.0, times are changing and many organizations are finding ways to lead people to deliver better results.

Having spent most of my professional career in the software development industry, either as a consultant or as an employee of large corporations, it is obvious that many of my inspirations for leadership came for the technology side of things. I quickly realized two things:

  1. Working with technology opened my perspective to more innovations and allowed me to develop a willingness to continuously improve what was around me – not only the technology but the tools and the processes in order to derive better performance from people and later on to strive for a more balanced work-life,
  2. I noticed that many people in organizations who could change the way people were managed were caught in their old paradigms:
    • Senior managers who had power refused to change and were counting the days until retirements,
    • Middle managers who had an open mind, had no time to implement innovations or had no power to do so,
    • Support departments were more interested in maintaining status quo after years of implementing policies and procedures and weren’t so inclined to look for better methods.

Once in a while, an external consultant would present some promising avenue to help improve performance and morale but their attempt would vanish once they closed the doors behind them.

Then came Agile. Although the Agile Manifesto was published in 2001, I discovered the underlying principles years later and it became obvious to me that what was recommended for software development organizations would certainly work, outside the technology departments. For almost two years, I have been analyzing the principles, reading books, and working with colleagues and clients to derive an improved method of working. From my “Rebel Leadership” concept came the “Agile Leadership” approach.

Book I have Read – February 2010

Another monthly update on the books I read during the past month. For a complete a list, you can visit my virtual bookshelf.

1 Free Audio Book -

The Halo Effect: … and the Eight Other Business Delusions That Deceive Managers – (also available in audio book format)

My Rating:

Stumbling on Happiness

My Rating:

le manager agile: vers nouveau management affronter turbulence

My Rating:

Comments from the peanut gallery…

Let me start by affirming I am in favor of democratic structures in “for-profit” organizations. I believe people should have a say in decisions, no doubts about that. In my opinion, the concept of democracy is closely related to the wisdom of crowds where diverse opinions from a larger group of people systematically leads to better decisions and solutions.

Comments from the peanut gallery

Comments from the peanut gallery

Now that’s established, I want to make a distinction between democracy (participating in the selection of the decision) and the discussions leading to decisions – which I will call the debates.

The debate is not a democratic process. Let me use an example to explain why I have an issue with opening debates to crowds.

Following another disappointing loss of our local hockey team, a few colleagues gathered in the cafeteria were loudly debating their opinion on the cause of the team’s poor performance…

  • Paul: “Price [the goal tender] doesn’t deserve to play with the team, he lacks consistency…”
  • Mario: “What do you mean? Price did what he could but he can’t do everything. With Markov’s and Gill’s injury our defensive line is weak and Price is too often left to himself…”
  • Richard: “Did you guys watch the same game I did? We have no offensive line. We gave a lot of talent to bring Cammalleri to Montreal but he is just not the scorer we need and nobody actually has the right skills…”
  • Mary: “No, no. It’s the referee who influenced the game…”

I’ll stop here but that is enough to show my point. How many of these people do you believed played in the NHL? None.

How many of these people took coaching training or even played junior hockey? None.

How many of these opinions are actually useful to make the right decision? None. That’s right!

This is what my wife calls the “comments from the peanut gallery“.

Let me use another brief example to prove my point further.

Assume a skilled people manager joins his highly technical team for a brain storming session. The team is looking to improve performance of their Java application and the tension in the room is high.  The manager – for sake of clarity, doesn’t have a clue about computer programming except maybe for a 3 hours introduction to Microsoft Excel taken 5 years ago – suggests to replace the framework and maybe the sorting method. What are the chances that his suggestion will be accepted? None.

The same situation applies when people with no management experience or training jump into a discussion about people management or organizational strategies. To take part of the discussion there needs to be a few pre-requisites. It is not enough to want to participate in the discussion, to really contribute people need: knowledge of the topic being discussed, experience, and a willingness to move the debate forward.

What is not needed is a personal opinion without facts, knowledge or experience but this is exactly what happens when a debate is open to the general public. When these conditions are met (knowledge, experience, and willingness), people should be welcomed to join the discussion so to take advantage of the wisdom of crowds. When these conditions aren’t met, people should stay on the sideline waiting for the debate to end and propositions to be open for selection.

Just like in the Canadian Parliament, a selected (elected) number of people were selected to represent others in the discussion. Once options are selected, the democratic process can allow people to vote.

Stop telling me HOW to do my job

Americans hate their jobs more than ever” … “Majority of Americans dislike their jobs” …

These are only 2 examples of a quick google search that returned over 44.1 million pages. Try “I hate my job” and the content of the pages returned is also very sad.

I don’t intend to go into socio-psychological analysis in this post but I wonder if something as simple as trusting your employees to do their job properly would actually increase job satisfaction?

For most people, enjoying their job would simply mean doing the same type of work but in a different work setting. Many people have spent years studying to develop their expertise in a specific field that they love. Then, one day, they start working and life becomes miserable – not because they hate what they are doing but because of the way the are treated at work. Once again, I don’t want to go into harassment or this type of treatment. The only point I’m raising is that letting professionals determine the best way for them to complete their work would is such a simple of increasing job satisfaction.

“Yes, but I’m the boss” – you reply.

So what? The fact that you were hired to lead or manage people in achieving a team or departmental objective doesn’t make you the most qualified individual to resolve day-to-day issues.

“Yes, but I’ve done this job before” – you insist.

Once again, so what? The individuals performing the job now bring different skill sets and expertise to the equation and as such are qualified to address their work as they see fit. You may provide guidance or answer your employee’s questions when they come ask for help but not tell them how to do their job.

Put together a community of expertise so people doing similar work can support each other. Provide tools if they need, support your employees in finding the right answers to their problems but don’t tell them how to do it.

There is a small Japanese car-manufacturer that understood that concept a while ago. They are now the largest car manufacturer in the world. Don’t you wonder how they achieved their success?

Defining Agile Management – part 1

Following a post I wrote a few months ago, I keep trying to define the principles behind agile management and so far I came up with the following:

  • Be humble: When it comes to the details, your team knows more than you do. Tell your team what you are trying to achieve and the reasons why but don’t tell them how to achieve the goal. Offer your help if they need it.
  • Provide space for experimentation: Not all outcomes are known at the beginning of a project. Give your team time and resources to experiment. Playing is highly educational.
  • Try quickly: When someone has an idea, try it out immediately with a trusted audience. No single brain can anticipate all potential issues. Share the ideas as soon as possible to get feedback.
  • Start small: In line with the previous principle, use prototypes. An incomplete tool will provide far more information than a simple explanation. People need to see and feel things, don’t just rely on their imagination.
  • Learn from mistakes: Allow failures and learn from them. Nothing significant has been accomplished in a single iteration.
  • Do not punish failures: In line with the previous principle, failure is part of the learning process. Penalizing people for their mistakes sends a strong message that your team is risk averse.
  • Maintain constant communication between the demander and supplier: Communication is key to building relationships. Bi-directional communications will help prevent assumptions and increase chances of success.
  • Have strong integrity: Say what you will do and do what you have said. People will respect you for it.
  • Do not be afraid to commit: Nobody likes indecisive people. Commit to other people will give you increased credibility.
  • Make sure to re-negotiate: In line with the previous principle, if you are unable to meet your commitment re-negotiate them immediately. Do not wait.
  • Focus on results and not process: The methods used to achieve results are much less important than the results themselves.

What are your thoughts? Have I missed anything important?