Don’t waste your time on who’s to blame

Whenever errors occur, some people have a natural tendency as their first reaction to look for someone to blame. Specially in group activities. As if having someone to blame would somehow make the error less harmful. This is a big waste of time and energy. Let me explain why.


Waste of time

An error occurred. Errors happen. This is a fact of life. No matter what you are doing, designing software, deploying code in production, operating on a patient, cooking dinner, building a house, playing guitar, playing soccer, etc. chances are that erros will occur.

When you spend time trying to find who was responsible for the error, you’ll delay your most important tasks regarding the error:

  • understanding what happened
  • figuring out how to fix it
  • find ways to prevent it to happen again

Waste of energy

When you spend time trying to find who was responsible for the error, people may naturally try to hide because they are afraid of the consequences. Will I be fired? Will I be excluded from the group? Will I be punished? Will people mock me?

When people try to hide who was responsible, you’ll again delay your most important tasks regarding the error listed above because it will be more difficult to understand what happened. People will not tell the whole truth and nothing but the truth about the error and the circumstances surrounding the error.

Deal with the responsible in private

If in the process of understanding what happened you find out that someone was responsible for the error, deal with him in private. Most probably he caused the error without intention to do any harm. So on one side you need to help him improve so he doesn’t do this kind of errors in the future. On the other side you have the responsibility to create an environment where it’s safe to tell about the errors so these errors are detected more quickly.

Lessons learned

  • When an error occur, don’t waste your time on who’s to blame.
  • Focus your energy on understanding what happened.
  • Figure out how to fix it.
  • Find ways to prevent the error from happening again.
  • If you find out someone was responsible, deal with him in private, and help him improve.
9 people like this post.

The IT problem

I have talked to some people lately about IT departments and how they seem disconnected from the companies they belong to, often being very reactive to business demands. It is common to hear complaints from the business people about IT saying they almost never deliver what was asked and that it is hard to understand what they say. On the other hand, it is also common to hear IT folks saying that the business area does not know what they want and that IT cannot answer “zillion” high priority demands of the business. This lack of understanding between IT and the business area of ​​the company is so common that it even became a subject of cartoons of all kinds:



But what is wrong? What is the IT problem?

Software development

For those who live in the part of IT that has to do with software development, this problem has been addressed for some time now. The Agile Manifesto, from 2001, makes this clear:

  • We have come to value customer collaboration over contract negotiation.
  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Business people and developers must work together daily throughout the project.

As the software developers need to deploy their software somewhere, they decided to involve the people who takes care of the production environment in this new way of thinking that bring together IT and business. Thus was born the DevOps movement in 2009:

DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals. DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services.

Source: Wikipedia

In these software development teams it is common to see someone with the role of Product Owner or Product Manager. This is a role I’ve already described earlier:

Product Manager is responsible for all aspects of a software product, from strategic objectives to the details of the user experience. She is responsible for making the connection between the business strategy and the problems and needs of customers through the software that should help the company achieve its strategic objectives while solving the problems and needs of the customers.

The IT problem

Now imagine the IT department of Gap, American Airline, Disney, MIT or any other non-tech company. These IT departments will have among its scope the following functions:

  • Hardware inventories.
  • Software inventory and installation.
  • Server availability monitoring and metrics.
  • Security management.
  • Anti-virus and anti-malware management.
  • Anti-manipulation management.
  • User’s activities monitoring.
  • Capacity monitoring.
  • Storage management.
  • Network capacity and utilization monitoring.

As you can see, these IT departments already have enough stuff to worry about and will hardly develop software. If they choose to develop software, they will most likely use third parties to do this development. Even if they decide to develop internally, software development is still a small piece of IT. The concern of these IT areas is with how to integrate off-the-shelf software and make them work to meet the business needs.

The problem is that unlike software development, which already discovered the importance of having a product manager to help deliver results more aligned with the business, all other functions of an IT department does not have this bridge between IT and the business.

One possible solution to the IT problem

I would like to propose a solution to the IT problem: have more people with the role of “product manager”. I believe that name does not fit very well when the IT delivery is not software. That person will need to create a bridge between IT and business. Perhaps a more appropriate name is “business manager”.

This person would have the following responsibilities:

  • Gather IT needs in all areas of the company and identify and propose solutions to any conflicts between these needs.
  • When these requirements have impact on the end customer of the company, understand this impact on these customers.
  • Negotiate requirement implementation priorities with all business areas.
  • Work with IT teams to ensure that deliveries are made in accordance with the requirements gathered with the other departments of the company.
  • Act with the demanding areas and IT teams on any relationship with suppliers / partners. (e.g. banks, consultants, etc.)
  • Inform all areas of the company on new IT implementations as well as upcoming implementations. Prepare training as needed.
  • Work with marketing to inform customers when the new implementations are customer facing.
  • Define, track and analyze usage metrics from IT, to use them as further relevant information for decision making.

And to be able to carry out these responsibilities, this person needs to have:

  • Experience working with IT teams to deliver quality projects within expected deadlines.
  • Good understanding of IT and technical topics to be able to negotiate delivery options. Having been in the IT field is not required, but may help in the function.
  • General knowledge about the company’s products and services, as well as an understanding of the different departments of the company.
  • Good oral and written communication skills.
  • Negotiation skills between different stakeholders with different priorities.
  • Ability to documente requirements and use cases.
  • Leadership.

As you can see from the above description, this person have a senior profile. It will be a pair of the IT manager.

A question that may arise while reading this proposal to add a “business manager” to the IT team is why IT managers can not assume this role? Actually, they can, but they shouldn’t. IT managers already have many concerns. The IT manager has two main focuses, technology and people. She needs to be up-to-date on the technologies in her area to learn how to better meet the needs that arise. And she needs to manage the team, finding and coordinating good IT professionals is no an easy task. Putting on the IT manager the additional burden of business requirement management can lower the overall quality in current tasks.

In software development we’ve realized that it’s better to have a separate person taking care of business needs. Why not apply the same role separation for other IT areas?

11 people like this post.

More thoughts on participative management

By the end of October I went to Business of Software conference, an interesting conference about, well, the business of software. Many interesting speakers and interesting people in the audience to chat.

One of the presentations was given by Scott Berkun, who was team lead at from 2010 to 2012. has over 10 billion page views per month, fewer than 200 employees and everyone gets to work from home making it a very interesting environment to think about the future of the workplace. He told us about the advantages and challenges of a distributed work environment, what we can consider as an innovation in management. His presentation was very interesting but when he got to the Q&A session, he got the inevitable question about Yahoo! and their move back from the remote working policy. His answer was very straight forward: since Yahoo! is in a crisis, they cannot afford the management innovation, it is natural that they revoked this policy and returned to traditional management practices, in this case, co-location of workers.

So this got me thinking, whenever a company faces a crisis, it should stop innovation management and should go back to traditional management?

Participative management in a crisis environment

Today I had again the opportunity to join a conversation with Clóvis Bojikian and Heiko Fischer. This was the third or forth encounter we had and, as always, the conversation was very interesting, full of ideas, examples and how-tos related to participative management.

Heiko    Clovis

At a certain point Clóvis told about a crisis at Semco, during the Collor president years, where the market was abruptly opened to foreign companies. That impacted Semco and forced them to do a downsize, which is always painful. Clóvis discussed with the workers how they wanted to do it and the workers told that they would provide a list of people that should not be laid off either because of age or personal issues and they said to the managers that, preserving the people in that list, the manager could select who should be laid off based on technical criteria. Two things we can pick from this episode:

  • Even in a crisis there’s no need to abandon management innovations such as participative management. It’s a good test for the management innovation, to see if it’s capable to cope with the crisis at hand. In this case, participative management was able to cope with the need for lay offs due to a crisis in the market.
  • There are a lot of numbers between 0 and 1, i.e., it’s not a matter of participative management or non-participative management. There are options in between, there are decisions that workers are willing to cope with and others that they don’t want to cope with and each issue will require a different mix.

It takes a tyrant to sustain participative management

Back in 2008 I read a very interesting article entitled “Sometimes It Takes a Tyrant to Support Collaboration“. We were in the initial steps agile implementation at Locaweb and this article showed that even though one of the outcomes of agile implementation would be self managed teams, this was not a natural outcome, and it requires a constant push from leaders to move into that direction.

Now I have the impression that the same happens with participative management. Even though this is an outcome appreciated by many workers, this is not a natural outcome. It requires that someone forces and sustains the move into this direction. Clóvis and Ricardo Semler did that at Semco. Heiko did that at the largest video game maker in Europe. I did that with my teams at Locaweb. We need to force and reinforce this behavior until it is imprinted in the company’s or team’s culture.

Heiko told about a decision they made in a company facing an economic crisis where the options where to either lay off people or cut 20% of the salaries of everybody so there won’t be any lay offs. Obviously the team preferred the second option. I said to Heiko that in Brazil that’s not an option since we can’t reduce salaries. He told that this is not possible in Europe either, but they figure out a way to do it. Employees would deposite 20% of their salaries in a company fund. At this moment Clóvis told that they also did that at Semco, in agreement with the Union.

Another exemple given by Clóvis was about employee time tracking. In Brazil it is required to have time tracking of all employees but at Semco they wanted to free up the workers from this hassle and show them they trust them. Even though they were subject to a fine if they didn’t do time tracking, they decided to pay the fine but keep off the time tracking to show workers their trust. So they found a way to support participative management even if it has costs.

This is an interesting paradox: in order to implement participative management you need to force it’s implementation, it doesn’t just happen. You need to force and sustain the movement into this direction, even more in crisis.

11 people like this post.

Dicas de liderança para um gestor de produto

Um gestor de produtos tem a difícil tarefa de liderar a evolução do produto sem ser “chefe” de ninguém, ou seja, ele deve convencer a todas as pessoas que trabalham com seu produto de que o caminho que ele definiu para o produto é o mais adequado. Em vários textos sobre gestão de produtos encontramos que o gestor de produtos é o CEO do produto. Não gosto muito dessa analogia pois um CEO, em última instância, tem ao seu dispor a liderança direta de todas as pessoas da empresa. Por outro lado, um gestor de produto trabalha em uma relação matricial, ou seja, não tem liderança direta de nenhuma das pessoas envolvidas com o produto. Aliás, esse é um excelente exercício de liderança e uma qualidade extremamente importante para um gestor de produtos: liderar sem ter a “chefia” organizacional.

A meu ver existem duas dicas principais que um gestor de produto, ou qualquer líder, deve se lembrar para liderar de forma eficiente, uma estratégica e outra tática:

Setar o contexto

Do ponto de vista estratégico, o gestor de produtos tem a obrigação de entender, comunicar e explicar o contexto onde o que está sendo trabalhado se insere. Ajudar o time a entender onde o produto se insere na estratégia da empresa e no mercado. Como os clientes utilizam o produto e o que esses clientes esperam do produto. Qual o objetivo do produto para o cliente e para a empresa. Como uma determinada feature, ou seja, um novo desenvolvimento que o gestor de produto pede para o time se insere no produto e na estratégeia desse produto.

Remover impedimentos

Remover os impedimentos é fundamental para que as pessoas do time possam desenvolver o produto. Isso é importante para poder ter aquela gostosa sensação de progresso, de que estamos fazendo algo, construindo algo. Recentemente li o artigo “What Really Motivates Workers” (O que motiva os trabalhadores) na Harvard Business Review que mostra uma informação importante. Fizeram um estudo para encontrar o que acontece em um excelente dia de trabalho. A resposta, em uma palavra: progresso.

Pesquisa que mostra o que é um bom dia de trabalho

O conselho no final do artigo resume bem a segunda dica:

Evitar escrupulosamente o que estiver impedindo o progresso, evitar alterar objetivos autocraticamente, evitar indecisões, ou segurar recursos. Eventos negativos geralmente têm um efeito maior sobre as emoções, percepções e motivações das pessoas do que os positivos, e nada é mais desmotivador do que um revés – o tipo mais proeminente de evento nos piores dias dos trabalhadores do conhecimento.


Apesar de esse artigo ser bem curto em comparação aos outros que tenho escrito mas, mesmo assim, vou fazer um resumo pois acha essas dicas essenciais para qualquer líder, incluindo gestores de produto, por isso que repeti-las mais uma vez. Para ser um bom líder, deve-se:

  • Setar contexto
  • Remover impedimentos


E vc, que outras dicas de liderança vc utiliza no seu dia-a-dia?

Be the first to like.

HR, participative management, democracy in the workplace and leadership

Readers of this blog already know Clóvis Bojikian, former Semco’s HR director. Back in 2009, when I met Clóvis, I wrote a long post about Clóvis experience in participative management.

One month ago I received a Linkedin invitation to connect with Heiko Fischer:

Salut Joaquim,
I follow your blog and love it! My team made HR redundant at Europe’s largest videogames company. We called it the Way of Resourceful Humans, basically democratic entrepreneurship. I was wondering if you could get me in touch with Clóvis Bojikian. I would love to invite him! Thank you!

Doing some research I was able to find this TED presentation:

It’s easy to see that Heiko’s ideas are in synch with Clóvis experience. I instantly put them in contact and arranged for them to meet over Skype. This meeting occurred last week and it was a pleasure and an honour to be part of the conversation between those two top HR professionals so ahead of their own time. The conversation could certainly generate many posts, but I’d like to write specifically about the beginning and the end of the conversation.

In the beginning of the conversation, Heiko told a bit about his history. He told that his father worked in HR at HP and there democracy in the workplace was a value brought by the founders, so Heiko thought this was common place. Following the steps of his father, Heiko decided to work in HR as well and to his surprise, companies were far from democratic and HP was much more an exception than the rule.

At this moment, Clóvis congratulated Heiko for following his father’s steps. Normally children tend to go the opposite direction of their parents, just for the sake of opposing their parents’ opinion. Heiko replied that actually he went in the opposite direction of his father. While his father believed that in order to maintain democracy in a company it is needed a strong HR department, Heiko’s view is that the perfect democratic company is one where HR is no longer needed.

After that, the conversation followed with Heiko and Clóvis exchanging experiences, telling each other how they implemented participative management and democracy at workplace and their motivation to do so.

At the end, after Heiko hung up, I was walking with Clóvis on his way out when I mentioned how interesting Heiko’s view on HR that the perfect democratic company is one where HR is no longer needed. Then Clóvis completed “and managers are no longer needed as well”.

15 people like this post.

Using checklists to deal with the unexpected

I mentioned earlier about “The Checklist Manifesto” book. The post was originally written in Portuguese but you can find a Google translation here. In this post I mentioned about the use of checklist in surgeries and other medical procedures and how we could use checklists in the IT environment.

I was reviewing my Kindle highlights for this book and found this highlight:

Surgery has, essentially, four big killers wherever it is done in the world: infection, bleeding, unsafe anesthesia, and what can only be called the unexpected. For the first three, science and experience have given us some straightforward and valuable preventive measures we think we consistently follow but don’t. These misses are simple failures — perfect for a classic checklist. And as a result, all the researchers’ checklists included precisely specified steps to catch them.

But the fourth killer — the unexpected — is an entirely different kind of failure, one that stems from the fundamentally complex risks entailed by opening up a person’s body and trying to tinker with it. Independently, each of the researchers seemed to have realized that no one checklist could anticipate all the pitfalls a team must guard against. So they had determined that the most promising thing to do was just to have people stop and talk through the case together — to be ready as a team to identify and address each patient’s unique, potentially critical dangers.

Dr. Gawande found out that in order to address the unexpected, checklists should not only include task checks but also communication checks. Dr. Gawande got to that conclusion visiting a 700,000-square-foot office and apartment complex construction site with between two to five hundred workers on-site on any give day managed by a man called Finn O’Sullivan. The volume of knowledge and degree of complexity O’Sullivan manages is impressive and it was as monstrous as anything Dr. Gawande had encountered in medicine. Here’s the explanation:

It was also a checklist, but it didn’t specify construction tasks; it specified communication tasks. For the way the project managers dealt with the unexpected and the uncertain was by making sure the experts spoke to one another — on X date regarding Y process. The experts could make their individual judgments, but they had to do so as part of a team that took one another’s concerns into account, discussed unplanned developments, and agreed on the way forward. While no one could anticipate all the problems, they could foresee where and when they might occur. The checklist therefore detailed who had to talk to whom, by which date, and about what aspect of construction — who had to share (or “submit”) particular kinds of information before the next steps could proceed.

The submittal schedule specified, for instance, that by the end of the month the contractors, installers, and elevator engineers had to review the condition of the elevator cars traveling up to the tenth floor. The elevator cars were factory constructed and tested. They were installed by experts. But it was not assumed that they would work perfectly. Quite the opposite. The assumption was that anything could go wrong, anything could get missed. What? Who knows? That’s the nature of complexity. But it was also assumed that, if you got the right people together and had them take a moment to talk things over as a team rather than as individuals, serious problems could be identified and averted.

So next time you design a checklist, remember to include not only task checks but also communication checks.

3 people like this post.

What type of entrepreneur are you?

Some time ago Rafael Rosa (@rafaelrosafu) presented me the concept of lifestyle startup in opposition to the growth startup everybody knows.

Growth startups vs lifestyle startups

Growth startups – or companies- are startups that have one main objective, accelerated growth so it can make founders, investors and shareholders substantially rich when the startup is acquired or make an IPO. When you are focused on accelerated revenue growth, all your actions are driven by this goal, which has top priority on top of all other matters, including products, customers, employees, suppliers, quality, etc. Normal product question you hear in this type of startup is “how do we make this product sell more faster?” or “can we create another product or add-on feature to charge some extra money from existing customers?”. In this type of startup you tend to have people passionate about money.

Lifestyle startups – or companies – are startups where revenue has the objective to sustain the company and it’s founders and employees lifestyle. As soon as this issue (company sustainability as well as founders and employees lifestyle sustainability) is solved, the company can have full focus on product, customer, employees, suppliers, quality, etc. Normal product question in this type of company is “how do we make a great product that solves real customers problems?”. In this type of startup you tend to have people passionate about the product.

Sometimes it can be difficult to identify what type the startup – or company – is, but normally a conversation with the founders or some key employees around the topic of company purpose and people’s passion have good potential to help you identify the type of startup you’re dealing with.

Thinking as a customer and another comparison with the medical world

Moving the point of view from the startup founder to the customer, i.e., use your customer hat and think as a customer. What type of startup do you think would you, as the customer, prefer to solve your problems?

People who read my posts knows I like to make comparisons between business world and medical world:

So here goes another analogy using the medical world. Move again your point of view and suppose you are a patient who received the news that you have a certain issue that requires surgery. What doctor would you choose to do this surgery, one who’s primary purpose is to get rich with medical practice or one who is really passionate about medicine and about making other people’s life better? Again, sometimes is difficult to identify the type of doctor we are talking to, but normally the way she describes your case and how it could be solved will give you hints on what type of doctor she is.


Ok. So back to my original question: what type of entrepreneur are you?

2 people like this post.

Pick your battles

There’s a Seth Godin’s post that I always use as a reference:

Gravity is a constraint. If you’re a designing an airplane, it would be a lot easier without gravity as a concern, but hey, it’s not going away.

A problem is solvable. A constraint must be lived with.

The art is in telling them apart.

Source: Problems and constraints

This post always reminds me of that old saying that tell us pick our battles carefully. Specially if the battle is a constraint.

3 people like this post.

Management 3.0

I mentioned earlier that one of the sources I’ve been reading and enjoying is Jurgen Appelo’s posts about agile management. I’ve been reading his posts for a while, since the time he was the CTO of a dutch company. I really like the way he connects agile methodologies and complex adaptive systems theory.

I’ve mentioned his work in 4 posts:

Now he is 100% focused on his agile management coach career. He recently launched a book entitled “Management 3.0: Leading Agile Developers, Developing Agile Leaders“.

He also provides Agile Management courses.

Last week he was in São Paulo providing his management course at AdaptWorks and I had the opportunity to attend his course.

I’ll make a brief summary of the course below, as a way for me to review what we discussed during this two days. However, I strongly advise any leader, even from non software related areas or companies, to attend. Even though the ideas and insights Jurgen provides during the course are very good and he is an excellent presenter, you can read them in his blog and in his book. What is great in this course is the opportunity to practice and discuss the ideas and insights with Jurgen and the other attendees and the chance to exchange experiences.


After a quick introduction about the ideal size of a group and quick introductions of the attendees, Jurgen explained quickly about agile software development and then introduced Martie, the Management 3.0 representation with the 6 aspects of management that we should take care if we want to be good managers.



Then Jurgen explained briefly about the theory of complex systems and the types of fallacies we may fall into if we don’t use complex systems thinking when managing teams.

The seven fallacies

The seven fallacies

To end the introductory section, we did a group exercise where we analyzed some situations to identify what was the fallacy in play.

Energize people

When discussing about people, Jurgen talked about intrinsic and extrinsic motivation and presented us with the 10 intrinsic desires:

  • Acceptance The need for approval
  • Curiosity The need to think
  • Power The need for influence of will
  • Honor Being loyal to a group
  • Social Contact / Relatedness The need for friends
  • Idealism / Purpose The need for purpose
  • StatusThe need for social standing
  • Independence / Autonomy Being an individual
  • Order Or stable environments
  • Competence / Mastery The need to feel capable

Intrinsic desires

Intrinsic desires

Exercise time: we analyzed individually how we are in our current jobs in terms of each of these 10 intrinsic desires.

Then Jurgen presented some tools to helps us know what is important for the people in our team:

B = f (P, E)

B = f (P, E)

Group exercise: we had to use the practices below to get to know 10 important facts about Ellen, a member of a fictional team managed by us.

Empower teams

Here Jurgen presented the 7 delegation levels I already mentioned in a previous post.

Delegation levels

Delegation levels

Group exercise: delegation poker where we were presented with different situations where we needed to figure out the appropriate delegation level.

Align constraints

A leader must:

  • define the constraints (playing field, players), but let the system create its own rules.
  • protect people against bad team formation
  • protect good teams against non-team players
  • protect shared resources (energy, budget, environment, office space, food, sysadmins)

The 4 I’s to cope with the Tragedy of the Commons:

  • Institutions: create trust to accept common rules
  • Information: increase understanding of situation
  • Identity: increase social belonging across teams
  • Incentives: address behaviors with small rewards

3 kinds of purpose (or goal) for a team:

  • Intrinsic purpose: an easily spottable trend in a team, e.g., produce software.
  • Extrinsic purpose: assigned by caretaker, e.g., make money.
  • Emergent purpose: chosen by the team, e.g., be a winning team.

Qualities of a good goal

Qualities of a good goal

Exercise time: we had to define a purpose for the course.

Develop competence

First Jurgen described how we can improve.

Competency development

Competency development

Then he described how we can measure our improvement.

KPI matrix

KPI matrix

Exercise time: we had to define KPIs according to the matrix above to our organization.

Grow structure

We can have two types of team organization, functional or cross-functional, it depends on how often team members need to communicate. Product managers, user experience designers and software developers need to communicate all the time about the project or product they are working on, so they need to sit together in a cross functional team. HR people on the other hand need to talk constantly to other HR people so they need to sit in a functional HR team.

Jurgen also advised we should hire generalizing specialists, promote informal leadership and widen job titles.

Exercise time: Meddlers.



Improve everything

How can I…

  • Make the rest of the organization more Agile?
  • Motivate my employees to develop themselves?
  • Convince customers they should accept Scrum?
  • Etc…

In order to change things we need to consider:

The system

  • Plan: What Is Your Goal?
  • Plan: Where Is It Going Well?
  • Do: What Are the Crucial Steps?
  • Do: When and Where Do You Start?
  • Check: How Do You Measure Results?
  • Check: How Do You Get Feedback?
  • Act: How Do You Accellerate Results?

The individuals

  • Awareness: How Will You Communicate?
  • Awareness: How Will You Set an Example?
  • Desire: How Do You Make It Urgent?
  • Desire: How Do You Make It Desirable?
  • Knowledge: What Will You Tell Them?
  • Knowledge: Who Will Be Teaching?
  • Ability: What Makes It Easy?
  • Ability: How Can They Practice?
  • Reinforcement: What Are the Short-Term Wins?
  • Reinforcement: What Makes It Sustainable?

The interactions

  • Initiators: Are You Committed?
  • Initiators: Who Is Assisting You?
  • Innovators: Who Will Be the Innovators?
  • Early Adopters: Who Are the Early Adopters?
  • Early Adopters: How Will the Leaders Help?
  • Early Majority: How Do You Reach the Early Majority?
  • Early Majority: How Will You Cross the Chasm?
  • Late Majority: How Will You Deal with Skeptics?
  • Laggards: How Do You Prevent a Relapse?
  • Laggards: How Do You Deal with Resistance?

The environment

  • Information: How Do You Make Things Visible?
  • Information: How Do You Ease Communication?
  • Identity: What Is the Group Identity?
  • Identity: How Can You Apply Peer Pressure?
  • Incentives: Can You Incentivize Good Behavior?
  • Infrastructure: Which Barriers Will You Remove?
  • Infrastructure: Which Guides Will You Place?
  • Institutions: Who Can Make the Rules?

Culture changes only after you have successfully altered people’s actions, after the new behavior produces some group benefit for a period of time.

John P. Kotter, Leading Change

Exercise time: each member of the group tell one story with she needs ideas on how to change, then the group select from the list above and discuss.


This is just a brief summary of the 2-day course, as a way for me to review what we discussed during. However, I strongly advise any leader, even from non software related areas or companies, to attend. Even though the ideas and insights Jurgen provides during the course are very good and he is an excellent presenter, you can read them in his blog and in his book. What is great in this course is the opportunity to practice and discuss the ideas and insights with Jurgen and the other attendees and the chance to exchange experiences.

12 people like this post.

Try AND instead of OR

I recently read the post “And” Leadership written by Jim Highsmith that caught my attention on using AND instead of OR:

One of the traits I think is very important [for an agile leader or manager] is that of “And” rather than “Or” leadership. The most pressing issues to face leaders are usually paradoxical; they appear to have contradictory solutions. Take for example the paradox of needing predictable delivery with that of needing to be flexible and adapt over the life of a project.

It’s easy to be an “or” leader. Pick a side and state your case loudly, over and over until the opposition gives up. It’s much more difficult to be an “and” leader, balancing between seemingly opposite strategies. However, in our ever-changing and turbulent world, slavishly following the “one right answer” is a recipe for disaster.

It’s interesting that in many situations in agile development we face situations where we initially think it’s an OR situation but when we analyze it, we realize it’s actually an AND situation where we need to balance apparently opposing concepts:

  • freedom and responsibility
  • cross-functionality and specialization
  • continuous learning and iteration pressure

It’s interesting that this applies not only to agile development but to many aspects of our life. Should I be more concerned about my family or my job? Should I give more attention to my kids or my companion? Experiment changing or by and. 🙂

Lessons learned

Next time you face a situation with opposing concepts, instead of choosing the easy path of taking sides and being an OR person, try to figure out a way to be an AND person. It will be much more difficult to ben an AND person. Sometimes it won’t even be possible to use AND in certain situations, but just trying to figure out if it is possible will be a good exercise with interesting outcomes.

1 person likes this post.