Avoiding confusion about what iterations means

In agile, we call Iteration a fixed time period. In Scrum (one of the agile methods), an iteration is called a Sprint. By that we mean a fixed cadence of work.

I witnessed several trainings struggling on the same topic, trainers and attenders alike. I heard many people I coached mixing notions right out of a Scrum training.

So let’s see if we can spell out this confusion for the future.

Overusing the Sprint / Iteration words

Many times I hear the word sprint used for “a fragment of the product” or “an amount of work to do”. I guess it’s originally a shortcut from “fragment of product done in the time of a Sprint”, or “amount of work planned for the time of the next Sprint”.

However, for someone not used to agile, it’s confusing. Trainer said it’s a fixed time period. Then trainer seems to say it’s an amount of work. There’s something that magically make an amount of work fit in a fixed time frame. Coz for someone discovering agile it’s painted with mystery.

In a recent training our attenders where from waterfall world (where you plan according to effort), and started ask questions mixing notions of effort and time. The other trainer and I have been paddling for 20 minutes not knowing why our trainees kept mixing notions despite our explanations… until I realized we abused the meaning of iteration. So much for clarity.

The trainees didn’t see that in Agile we are now planning in term of time box, giving a pace of work where the amount of result is variable. In their previous world you start planning from effort that will span in phases of variable durations.

Classic check that you failed to lead to cadence thinking

If you don’t sort this early, later on the project they will be surprised when through the course of a sprint (again, a fixed time cadence) throughput don’t go as planned. They weren’t prepared for that since they weren’t driven away from there previous “effort” frame of reference. Again, they’re confused.

Usually I let it go since after a few sprint they will get it, but in the meantime they struggle and they are unable to explain it to other project partners and stakeholders that are not used to agile projects.

Well, they get it… actually I’ve seen Product Owners and even Scrum Masters still mixing notions after a year. I also saw agile veteran projects, year longed, intoxified by the notion of planned throughput.

A few classic tense to avoid

Guess what ? I saw coach and trainers also not being able to precisely sort the notion. (yes, me angry here)

Here’s a few quotes I heard from trainers that led trainees into mixing the two notions

  • “you did all the Sprint”, “you didn’t do all your Sprint”. Of course they did. How could you fail or succeed 2 weeks?

    Instead, you can say you achieved in the course of the spring less than you predicted, or more.

  • “let’s plan your releases into iterations”. You just can’t decide that.

    Instead, you can say (after the project has acquired its rhythm), “let’s try to predict what will be done at each iteration”.

  • “we will report the sprint on the next sprint”. Again, it may be just that you are shortcutting words, but for those discovering agile, it’s confusing. Instead you can say “During the next sprint we will work on the user stories that aren’t Done”

Avoiding the big trap of the initial project -planning-

After starting to spot the confusion, I realized it came mostly during the first initial roadmap creation, and can be avoided there.

Today I pay great attention to not use the notion of time when doing the first story map and roadmap definition (inventorying the project features scope and setting it into successive interesting releases).

By extension I don’t use the word iteration or sprint either.

I carefully choose my words since it may be that my coachees has been misled during a previous training (more on that later).

So far, it works, I have very little questions that mixes the nations. So the confusion went from me.

Practically :

when I do a roadmap, I ask the product owner to prioritize items typically by one of these two strategies :

  • “Buy a feature” exercise

    “If you could have 3 of these features in short term (or Epic, or macro-story whichever terminology you use), which one would you like to see done and working ? Then which ones would you pick next ? etc”. See ? Sequence thinking, but no notion of time.

  • Dichotomic prioritization

    “here’s a line, this is your mid-project. What would you see first ? What would you see next ?” (you can also use “must have / should have / why not, or any criteria to make prioritization happen)

    Then I draw another line in the middle of the first and second quadrant. (interesting variant : I draw 4 lines and ask for 4 releases directly ; let’s not digress)

    At this time, I never introduced the notion of When things are going to get done. Only what should comes first.

The notion of time will only be introduced on a next estimates workshop. Then I will follow the advice of J.Rothman and only use the words predictions.

Erm, Scrum industry, wtf ?

You mind if I end with a rant ? Gotta unload my heart. It was my first impulsion into writing this.

Scrum industry, you’re a powerful machine, you help popularizing agile and raise new generations of Agile Trainers and coach by the hundreds. But when you fuck up such detail we coach in the field have a hard time cleaning up the mess.

And no, don’t look away, the mistake can’t be made in flow-style Agile (Kanban and such) since we just speak about cadence and don’t even talk about iterations planning. I spotted that constantly will people coming out from various Scrum trainings.

So to my beloved pairs teaching Scrum : can you check that the confusion of iteration = time is not engraved in your training slide ? Thank you very much

Bisous bisous

Continue Reading

Total blog overhaul (in progress)

After a year on a break, the web site is on massive overhaul, reboot-style. It comes out of both a need and an accident

A camp base for the new international me, integral view

While looking for work outside France, I realized I had like zero trail in english on Google. After trying a first batch of English articles last year, I’m now turning the whole blog to English.

Many readers also tells me they read both my blogs since they see connections between both topics, and they expect that from me. They’re right, my thoughts have always integrated Agile and personal topics, and so my life. So I’m merging both blogs, it will be easier for everyone.

Actually, over years I professionally lack a single place where to show pieces and bits of my various commitments and inspirations (blog post, agile material, sessions, professional reference, etc). I’ll try a different writing process on this new version.

So I needed a new name, right ?

My genius friend Emilie Esposito came up with the bold domain name of http://guillaume-unlimited.com. It kicks me in the butt. I want to live up to this statement.

Thank you hackers, now I have a blank slate

Just as I was thinking of changing my blog step by step, my domain has been hacked several times. 10 days down in April, some technical changes to enforce its maintenance. Hello Broken links, missing illustrations, and SEO rank zero.

I took that as a sign : let’s restart from a blank slate. I gave up any attempt of continuity, template is black on white and some illustrations has to be fixed. But now I’m free to move fast.

Continue Reading

How to defeat the Plouf : genesis

In 2008 I talked in french about the Plouf at the early USI conference (title : “Vaincre le Plouf”).The Plouf is a hidden force that prevent us from taking action when we have decided of something.A few month ago I came back at it at the XP Days 2014 conference (then in english, “Howto Defeat The Plouf“). I wanted to share my behind the scene story, how I became inspired to raise attention on the Plouf in the first place, and why i felt an urge to come back at it.

Battez le Plouf !
2008 : Fight the Plouf ! @USI
Continue Reading

Encouraging team’s freedom : how much is enough ?

When talking with directors about how to enable collective intelligence and co-responsability in their teams, they usually find me too strict regarding their own behavior.
« Yes, last week I’ve been keeping someone’s action on hold -it was over a detail, but I didn’t understood her decision, you know. And the next day I stepped in and took direct control of à team’s action plan, telling people what to do.
But what’s the deal, that’s just two times, right ? On average, I let them go on their own if it’s good for the business. They know I expect them to decide and act without waiting for validation on details, right ? »

My point is : no, they probably don’t.

To explain why, I’ll use a reverse example.

Reverse proposition: dictatorship

Imagine a dictator of a 150 people village. How many people does he have to punish to remove any attempt of free-thinking and free initiative ?
My bet : 2 are enough.
It’s not about controlling all of the free-thinking leaders, it’s about making an example, telling a message. Once people got the message, they’ll stay away from displeasing you. The first punishment makes an example, the second one set a pattern. Then the word spread. Self-restraining behavior will soon appear.

Now let’s say the dictator changes his mind.
How many people does he need to reward to remove the former message, to say « good you take that initiative on your own. It helps ! » ? 10, 20 rewards at least, right ? While restraining from any censorship

Back in our management situation.
Control messages are far more powerful because they’re calling our inner surviving sense. « Don’t get into bad situation » comes before « Thrive in your life ». No balance is possible because these are not competing on the same level : safety wins.

You’re the boss, boss

As a CTO/CEO, you have a lot of power and influence on the people that works for you, probably more than you think.
So when you’re a manager, a CTO, a CEO, and you forget yourself 1 or 2 times per week by being over-controlling, censoring someone who takes an initiative you didn’t understood (in other words : you freaked out), you don’t get an « average » message at the end of the week. You drawn a powerful pattern that you’ll have a hard time to remove.
That’s why, even if I’m being tolerant as a coach, I stay relentless about the behavior required to set a proper messages.

Now, if you’re asking yourself « Am I doing enough to get my teams confident about their freedom to think and act by themselves ? », I would use two reverse questions instead :
1) how many censoring actions are needed to kill people’s investment in your project ?
2) how far are you from that number ?

Continue Reading

Meet in circle for circularity

Your coworker, what a jerk, right, interrupting people like that ? You can’t event figure how to raise a word in these damned monthly meeting. So when it’s your turn, you use it as much as you can. And… you keep it a bit too much, maybe. Think about a vicious circle, right ?

There’s a basic trick to prevent people -yourself included- from interrupting each others during meetings : have the chairs set in a close circle, 2 or 3 meters wide.

We’re all bullying from time to time, let’s be honest. But when you can see everyone at once, feel them close, you know who’s talking and who’s about to. There’s also a pressure to take others in count before bullying around. So consider this trick a good way to stop yourself from being harsh. Suggest it to your coworkers for yourself.

I see a few cases when this no-brainer of meeting facilitation is forgotten

Presentation followed by a question / answers session

After a coworker ended her classy powerpoint, ask 30 seconds before the talking to move the chairs as to have everyone in circle, in each other’s sight. Yes, in conferences too, as much as you can, have people move their chairs or themselves before the Q/A.

Tables are set in U shape

or anything too large, dismantle them form each other. Have people sitting closer, 2 or 3m max. If you like, remove the table, best trick ever for honest conversation.

When there’s this big one-piece of un-removable presidential table

I’ve seen that. A large table set up as a triangle, proudly riveted to the ground. It set people apart in 3 factions at every meeting, 5 meters away, with people at the corners feeling unengaged, and people in the middle of the sides feeling exposed.
Well, get rid of that table. It deserves all you can. Talk to the boss. There’s important things running in this meeting room, right ? otherwise nobody would have put such a proud piece of furniture there. Get. Rid. Of. It. Replace it with simple tables on wheels so you can easily rearrange the room whenever you want.

You’ll thank me.

… now, I do know it may take some months. Until then, try to set up a circle of chairs beside the table. You’ll prove how much more efficient and healthy meetings are. Now, go get the chainsaw.

Continue Reading

Work with old kingdoms to establish new republics

Everyday, agile changers face the same challenge : how to create a system with shared responsibility and collective decisions when there’s a hierarchical organization in place ?

In 2005 I travelled to Cape Town, South Africa. I was impressed by one particular event faced by this 400 years old country. The apartheid was ended by white people. Exclusive owners of the voting right, they voted a new constitution to share that right with everyone, no matter their skin color (note : they were more than one step leading to this, refer to wikipedia if interested).
13 years after the events, I was amazed when visiting Cap Town at how much a country with such a heavy burden was able to move forward so fast. They already had gay mariage.

Last month Alexandre Boutin told me another related experience he had when coaching a Korean company. His attempt to promote collective creativity was stuck. He was informed after a few hours that what he promoted was in contradiction with local manners : you don’t challenge in public someone else’s idea. A brainstorm, based on that precise principle, was impossible. After this social trait had been made explicit, they worked a way to circumvent this social convention in brainstorms.
But who did explain this cultural trait to him? The big boss. Who proposed and allowed criticizing ideas inside the group? The big boss.
The power in place allowed another distribution of power. It was peaceful and with immediate effect.

For change makers like me, there’s a lesson here. To change an organisation, the most efficient course of action is to have the current one doing it. So work through the system, not apart from it, not against it.

This led me to a few recipe when spreading agile in a hierarchical organization (with a tendency for command and control) :

Look for the person with a crown

Working from the ground level, doing more agile rituals, more « let’s prove them … », more « let’s have them understand that … », that’s not working. If you want your agile zone to spread, go up the power ladder and start where the power lies.
(How up the ladder ? enough to rule the whole organizational zone you want your new organization to reside in)

Deal with local lords

Unless you have a feature-oriented organization like Spotify, an efficient agile team usually unite skills from different divisions (business, IT, etc.). There’s as many managers to convince. Learn to sell them the change, let them deal with their current restraining forces (local power, budgets as a social status, etc), mobilize them.
Usually, these guys will introduce you the queen is she’s hard to talk to.

but all this requires to

Respect them, learn their etiquette

Understand their constraints, their social codes, their decision ecosystem, what subject triggers their interest. Just ask them, if you respect them some will teach you, even offer their help. They will tell you what is needed for this change to happen.

Is that encouraging the current system ? I don’t think so. Going along with the rules is not giving up. It just means you need to respect the system in place if you ambition to change it.

Continue Reading

Agile explained in 3 paragraphs

I said earlier (in french) that being able to explain agile in any time frame from 1 minute to 2 hours is a key to agile adoption. Sometimes it’s also in a written manner. As years goes by I have stacked some short descriptions of agile I use here and there or rewrite.
Here’s a 3 paragraph explanation I wrote for a client’s HR division, whose people had no knowledge in software development. Feel free to reuse / modify / share.

Iterative implementation
In a classic waterfall development process, the software is exhaustively described, then developed at once, then validated.
Every evolution during the project disrupt the schedule. In agile development, features are added little by little up to the wished goal, refining requirements and validating as implementation goes on. This approach enable innovating during the project, and shortens the time between idea and implementation.
For agile mode to work, the implementation organisation must remain stable : a dedicated team, stable over time ; fixed-duration iterations (one or two weeks) ; and a regular work rhythm.

The agile team
Maximum proximity of all contributors is seeked as to benefit from face-to-face communication and the best emulation possible. Through specific meeting rules and visual management, shared responsibility and self-organisation are encouraged : success is everyone’s business, and the team operates day-to-day the way that seems relevant to it.
3 roles are distinguished in agile :
– the product owner (*) defines thinly the functionalities and their relative priority of implementation
– developers are in charge of end-to-end implementation
– the facilitator run the meetings and watch after the team dynamic. This role is endorsed by either a developer or the technical manager (**).

Handling risks and work pace
Progress indicators and risk indicators are evaluated by the contributors of the project themselves. With ground people driving the project, incident and delays are detected earlier, enabling structural decision to be taken by the top management soon enough, thus reducing further rush hours. (***)

(*) I used in fact « responsable produit », french translation of « product manager », a term more suited to the client’s usual terminology. The intended receivers weren’t about to run projects themselves so I choose not parasite their understanding with our agile-specific metaphor
(**) This organisation used to put apart technical people from business one. Coaching some of the technical managers into becoming agile facilitators of their team, aka Scrum Masters, was a choice we had made in this particular organisation.
(***) … Which was a way to tell the HR that a more efficient project management, i.e. Agile, enabled a healthier way of working

Continue Reading

My meeting attender manifesto : be useful or don’t be

Proclaiming that meetings are evil is common these days. I’m rather part of the people who proclaim that meetings are useful and precious but expensive. Meaningless and inefficient meetings are evil. There are plenty of advice around on how to run efficient meetings, like setting up agendas, protocols and decision report. After trying to bring these practices to various clients, I find this group approach too slow, it does not spread fast enough.

Why not starting by working on our own individual behavior ? More precisely : our will to be useful in meetings. Not having meetings useful for us, no, the other way around. As to support this statement you could for example

  • decline the invitation if you don’t expect to be useful
  • get out if you think you are not useful
  • when in doubt, ask if you will be, otherwise leave
  • leave in the middle of the meeting if need be
  • ask to bring the items you’re useful for on top of the agenda
  • delegate if you are not available

It doesn’t mean you will go to less meetings. You can go there differently, learn to improve your usefulness, even if your involvement to the subject is low. Like

  • ask for a wrap up of the further discussion if you’ve lost the point, offer your wrap up if no one answers
  • ask candid question
  • ask quiet attenders for their opinion when a conversation gets stuck
  • bring out new perspective through suggestion
  • propose various way of deciding
  • start making a drawing or give a pen to someone
  • follow the time and make time announcement
  • ask for the agenda and purpose of the meeting if unclear
  • go write key points and decisions on a paperboard
  • show a good mood and a comforting smile

You can also ask yourself if you are still useful if

  • you will bring no difference in opinion, position, perspective, culture from the other attendees, at least regarding the agenda
  • you just want to be kept informed
  • you need to see someone you know will be there
  • you will hide your disagreement
  • you chit-chat and whisper with your neighbors
  • you will check your emails

A set of tricky questions

  • What if I’m not concerned at all ? Facilitators and role models are useful. Ask if one is needed. Otherwise decline.
  • What if I just care and want to bring my support ? This is a wonderful motivation. Now show your support even more by trying to be useful.
  • Who cares if I’m not useful ? Your silent presence distracts others from feeling committed to the usefulness of the meeting. By the way, don’t you have anything else to do ?

Now the last question will draw the conclusion. What about the others ? What can I do to have the others follow the same path ? I don’t want to be alone driving things forward.

Don’t distract yourself teaching others. Focus on yourself. Your own attention to be useful (or moving out of the way) will inspire others.

Continue Reading

Kanban, because you’re worth it

A manager working for the media industry asked me a few month ago whether his teams should use Scrum or Kanban. He had sponsored agile teams I coached for 2 years. We worked together but didn’t get into the details of methodology, so we knew each other (explains my familiar tone). Here’s my answer.
——
Hi O.

TL;DR : since I’ve been working at France Televisions Editions Numériques I’ve already been coaching your teams to Kanban, so you’re not going to get lost. You’re already doing flow development, like M. Jourdain speaking prose.

WTF are Scrum & Kanban ?

  • two variations of Agile methods = two subset of practices, not necessarily exclusive
  • Kanban (also labelled Lean IT or Lean Software) is a software development flow = you pop functionalities from a backlog and you check the counter every iteration
  • Scrum follows the same principle but with strongly imprinted iterations, more protocol and meetings, in particular iteration planning, detailed task decomposition, estimation and a « commitment to deliver » at the beginning of the iteration. That’s not far from being a mini-waterfall cycle.

These methods are just starting points. While continuously improving teams will perfect them. Over the course of the project new practices will be integrated, modified or removed in regard of the time and context.

Kanban, because you’re worth it

My reasons for recommending you a development flow are

  • it encourages better coding practices : baby step development, systematizing development and quality processes, emerging and minimalistic design
  • Scrum do recommend good coding practices but enforces nothing and it’s a lack. I find that teams doing Scrum usually do not care enough about their coding practices, or too late in their product development.
  • In a flow you’re more reactive, you can introduce minor evolutions on the fly (just in time), let an ambulance pass through the traffic, which is more adapted to your activity [my client was working in the web / news media]. It’s never a 0 cost operation but it’s never a problem of methodology. With Scrum, adding a feature inside an iteration is seen as a disturbance (translation : violating the dogma)
  • Kanban is just more efficient, drier : less chit-chat, less fuzz, simpler to deconstruct and to adapt to each context. Scrum needs half a day of ritual meetings per week of iteration, with Kanban you get down to 2 hour.

This evolution is where, by dint of continuous improvement, long journey team goes (after more than 50 iterations), or projects with high stakes or high risks, or mini-projects (having an implicit risk level due to their size).
It’s been 3-4 years I’m asking myself « what if we start by the best of ? » and it does work : young teams reach in a short time the maturity of long journey teams.

What duration for iteration ?

Apart from questioning the coding practices, the underlying question is the duration of the iterations : Scrum is more 2-week suited, but become too burdensome on a shorter pace (cf half a day of ritual).
Today I always recommend 1 week long iteration when a team starts : twice more learning because twice more retrospectives, short-term adjustment to their functioning, etc. I’ve let the [XXX] team start with 2-weeks iteration and we kicked ourselves (waiting 14 days to see if problems get resolved was unsustainable as the project start).

On the contrary, a seasoned team can be caught in the day-to-day (which is the point at early steps) and lack vigilance on long term planning. Some teams do like 2 week-long iteration to bring tempo within a long journey without specific deadline (like 4 month of development without a planned public release). That’s what the [YYY] team has chosen for example.
I think it can be meaningful to go on 2 weeks pace to a far away release for any team older than 10+ iterations, that already masters its flow with 1 week rhythm.

Like I usually tell the teams I coach,

I could have you do Scrum, but you’re better than that.

Continue Reading

MBTI, Process Com, Moving Motivators, DISC : let’s stand back a little

In management 3.0 Jurgen Appello proposed « Moving Motivators », a personality model focussed on personal drivers. The accompanying exercise have you prioritize motivators like « Curiosity » « Honor » « Acceptance », « Power », etc. You end up with a small set of preferred motivators, a less preferred range, and the dislike range (refer to his original material for accurate description).
This is a cool exercise, and I like this model, humble, neutral, not pretending to be scientific but rather useful (he simplified the motivators from Steven Reiss 16 Basic Desires).

As I see more people using it, and it may be your case, I feel like giving a warning on how to approach this. I’ve seen people use other personality model like MBTI, DISC, Process Communication, you name it. The common mistake I’ve seen was thinking the model was the Truth. Let’s stand back.

The model is just a support for talking with a person about herself. The talking is were you’re going to learn about the person, not the model.

A personality test’s result based on a given model is highly contextual, if not inaccurate… or wrong.

Few examples that can bias the results

This morning you woke up after a bad night… you shouldn’t have drink coffee after 8p.m., and the alcohol was cheap. On the way to the job you felt cold, you ask yourself about this flu everyone had but not you… yet. You’re shivering. Then a dumb driver cut your path, almost crashing in your car. You curse him, blame him, blame yourself on your lack of attention. Then you arrive at the office. Would you pass a personality test right now, arriving at your office, would it be give a proper view of your day-to-day personality ? Then what if they were a cake awaiting with “happy birthday ?” written on it by your colleagues ?

Now let’s say you’re hiring someone. In front of you, the person knows the test. She has a high self-awareness, knows what these test means. Do you think she will answer what she thinks you want her to answer, or what she really thinks ? Then there’s you, making the exercice. You’re part of the discussion, asking questions. Unless you’re a highly experienced interviewer on personality testing, you will be projecting yourself, give insights through body langage, question more this and less that, use judging words. Wouldn’t the results reflect your relation to the person during the interview ?

The model was designed in the US in 1982. You’re french and you learnt the model through a version translated in your langage in 2002. Do you think the people who translated the book was this skilled as to reproduce the subtleties of the original, taking in count the context, the differences in culture ? I’ve spotted some questionable translation in Strenght Finder and Process Com’.

How to know you lost your distance with the model ?

From example’s I witnessed :

  • you can’t stop qualifying people with the model’s words. « She’s a high I » (referring to DISC), « She’s so Inputs » (Strength Finder), « He is an Order-first » (Management 3.0). They were tons of subtle words to qualify people’s personality, qualities and preferences without these models. And suddenly, a few words are enough ?
  • you think you know psychology. You think you understand people since you red the book. Well, think again : would it be so simple ? You red in a book a model giving a description of you that you liked. Good for you. It may not work that well for others.
  • you trust the model more than the person’s self-awareness. When your direct didn’t recognize herself in the description and proposed another wording on herself, you keep referring to the model.

“essentially, all models are wrong, but some are useful” (George Box) and that’s exactly the point : even a meaningless exercice can be a good standpoint for a personality interview. That’s basically what people are doing on dates. You could even get meaningful insights on someone’s motivators by starting a conversation about the weather : “If only this could last” vs “there’s a good day to enjoy”.

Use personality model as a tool for a higher perspective

On every model I’ve seen, good results came in the context of an interview with someone skilled on using it, and following a higher purpose. A coach trying to elevate your self-awareness. An HR consultant helping you reboot your career. A CEO trying to figure out what value a hiring candidate could bring to his company. Not only were they able to not forcefully stick to the model, but they were using it as a simple insight for a higher approach.

To CEO & managers : heretics are okay

I spent a night drinking with a new friend, talking about innovation, future thinking, rebuilding the world. He called me a Rebel. I disagreed with such shortsighted vision of myself. He explained me how he recently discovered Process Communication, and thought I was what was labelled a Rebel, then described the proposed meaning of the word.
I repeated my disagreement and questioned both his interpretation of Process Communication and Process Communication’s choice of words. You guess his answer ? « Typical Rebel answer ».  Would I’ve said yes, he was right, would I’ve said no, he was right.

I understand this tendency. When you discover a new theory or a new tool, you’re learning to use it as much as you can, and you wan’t it to work. But still, you have to look for its limits, otherwise it’s no more science, it’s dogma. With the heretics pattern : the existence of disbelievers still validate your beliefs.

My friend reminded me of a former manager who asked me 10 years ago if I was intentionally trying to not fit in the boxes. His voice was of disapproval. In other words, he suspected me of trying intentionally not being understood by him. Twisted.  The problem was not the boxes, but that you had to fit it them (while you can simply stand on them).  A few years and people quitting later, I suspect I was not alone to feel uncomfortable.

If someone do not feel good with the personality model you’re applying on them, trust them more than your book. That’s respect 101. Do not treat them as heretics. Take a step back and ask them how they would explain their own behavior in a discussed case. You may learn a thing or two.

The final word goes to CEOs and managers who, by their behavior, serve as a reference for all their employees and directs.

If you don’t want to see people treated as heretics,
then don’t behave like there is a dogma.

Continue Reading
1 2 3 7