RSS

Tag Archives: respect

Those Pesky Invisible Agreements

The Story

One of the things I do with my clients early on is work on team agreements; basically an explicit “how we work together” document.  And, not infrequently, I get people rolling their eyes and telling me that this is too heavy and mechanical.  “Are we trying to solve a non-existent problem?” some would ask.  And every once in a while I let up, and think that “we have it together, maybe I’m just overdoing it”, and I am always quickly reminded of why.

This happened to me again this week.  Let me tell you the story of how I caught myself and my team suffering from un-agreed-to agreements, and how we’re working on the solution.

I lead one of two teams – my team is primarily focused on consulting and working with clients, and the other team is primarily focused on making our eLearning application great.  We frequently work together and cross team boundaries and have a great working relationship – most of the time.

On my team we have different skill-sets and passions.  One of the people on my team is very passionate about coding and learning new languages.  We also have an internal tool that a few of us are great at, and many of us (like me) are not.  So, based on our experiences, and our passions, and the fact that we’ll be working with this tool very heavily over the next few months, when this guy said “I’ve got an idea of how to make this better” we (his lead and I) jumped on the opportunity and asked him to make it happen.

In a day he had a working prototype.  In just over three days he had something that is ready for daily use and already significantly better than the current solution.  So you would think this is a raging success – right?  Of course not, if it were, I wouldn’t be writing this blog post.

Our team member was so proud of his work that he shared it with the rest of the teams immediately so they could use his tool and give him feedback on how to make it better.  Unfortunately this wasn’t well-received.  Some members of another team became frustrated.  They felt that we have more important things to work on than something like this and they thought it was not time well spent.  They felt that our team should have involved them early on and that would have led to us putting our time to help them with what they need done – which is much more important and urgent than our project.

Getting that type of feedback hurts – especially when you are really happy with what you’ve produced.  You feel unvalued, and you can easily become angry.  And as one person described it, “this is beginning to look like politics in large organizations”.

As for me, I also got sucked in and felt that my team member was attacked and the conversation should have been with me.  I authorized this and if there is a problem then it should be solved with leaders.  (It does sound like big-office politics, doesn’t it?)  I fired off an email voicing these concerns and my anger.

I should have known better.  After sleeping on it, I saw our situation as a microcosm of what happens at work everyday.  I realized that we were behaving as if our expectations were agreements.  But they weren’t.  I was behaving like the other team had no right to talk to us about what we should and should not do – but there was no such agreement.  And, the behavior of the other team seems to indicate that they had an expectation of us checking with them before we wrote any code, and, of course, there is no such agreement.

Blame and Ownership

I had easily fallen into a trap that I’ve been in before.  I was getting upset because people were not meeting my expectations – invisible agreements.  Which led me to see them as obstacles, instead of people doing their best to make our organization successful – just as I am.  And I began to see things as “us” vs. “them” which is the bane of all large organizations.  I was blaming my peers.

But, from Christopher Avery, I learned how useless blame is – and how it can easily lead into a vicious cycle.  So, I asked myself instead, “how did I contribute to this problem?”  That led to a completely different way of seeing the problem and my colleagues.

Well, it turns out we had a bunch of assumptions about how things should be done that we never really brought to light.  Our actions lead me to believe that these might be those invisible, un-agreed-to, agreements:

  • Team A should ask Team B if they have spare time on their hands before they do something on their own,
  • Team B’s leadership should only talk to Team A’s leadership,
  • Team A doesn’t have enough visibility to know what is the most important thing to work on, they need to ask Team B,
  • Team B has no right to tell Team A what to do.

But the fact is we didn’t agree to any of these.  And this upset was not an unusual thing.  Upsets are to be expected.  How we handle upsets separates the highly effective from mediocre teams.

This wasn’t a totally bad thing, it was actually pretty good.  It told us we are transparent enough to know what other teams are doing.  It told us that we felt safe enough to disagree openly.  And, because we caught ourselves and are looking at our expectations of how we work together, it is a great example of leveraging upsets for improvement (thanks Christopher Avery!).

Personal Agility

If you’ve read any of my blog posts, you’ll know I’m all about the human dynamics of software development and creating a high performance culture.  One of the best individual tools I know for this type of situation is the Personal Agility Pyramid that we created at Gemba Systems.  (I know, it is not the best name, but it really works!)

Image

Here’s how the personal agility pyramid applies:

  1.  When you have a problem or an upset, you need to start with yourself before you send that angry email or tell someone about how they screwed up and you are frustrated.  Before you do anything check your a) safety, b) respect for the other person, c) ownership of both the problem and relationship.  Do not do anything until you are in a good place here.  (I missed that one and the angry email got out.)
  2. If you are like me, when you are upset you are very clear on what you don’t want, but not so clear on what you do want.  So step two is to get clear on what you want.  For me, it was “those who do the work decide how to do it”, “let’s create some very specific expectations and re-org the two teams so that we don’t need to go to each other before we do most things”, and “before you tell me why I made a mistake, ask me why I made the decisions I did.”
  3. Now that you know what you want, that doesn’t mean that is how it is going to work. In step 3 you need to go ask for what you want.  But remember, before you go ask what you want you really need to check step 1 – you’ve got to be safe, respect the other party, and come from ownership.  We are still in this stage.  We’re talking and aware of what we need but still haven’t reached on an agreement(s) to keep this from happening in the future.
  4. Make an agreement.  Now you have a concrete, visible, real agreement.  Congrats.  You are now potentially aligned.  Agreements – especially when you are new to this – aren’t always cut and dry.  People interpret them differently and can still be misaligned.  No worries, you’ll come back here at the next upset 🙂
  5. Confront a missed agreement.  Step 5 is not addressed until the next time you have an upset and you go through the steps and realize there is already an explicit agreement in place.  Unfortunately, this is where we usually start when we are upset.  This happened when I sent an angry email without going through step #1 and taking ownership of the problem and the relationship.

I’ve found this extremely effective for problem-solving and iterative and incremental alignment.  By doing this regularly when you have an upset it really helps your team continue to get better at the mushy stuff.

 
2 Comments

Posted by on August 27, 2013 in Individuals, Interactions, Teams

 

Tags: , , , , ,

On Transparency and Openness

We all want to be transparent and open on our teams – don’t we?  Well, at least we want the benefits that come along with it such as:

  • not being surprised at the end of a long project that we are off-course,
  • ability to recognize change early in order to respond to it,
  • a way to build trust in what we are doing,
  • a mechanism for estimation
  • and many more….

However, achieving transparency and openness are more difficult than they might seem to start off with.  One of the primary reasons, is that if you are transparent and open about the work you do, the agreements you make, and the results (or lack thereof) you achieve, you also open yourself up to publicly failing.  And that public failure is extremely painful for most of us.

If you are a coder, can you remember the first time you ever had to pair-program?  If you are a product owner, do you remember a time when you had the team working on the wrong thing and was questioned about it?  For the rest of us out there, can you remember the last time you had someone review your less-than-perfect work?

For most of us – it is uncomfortable having someone review our work and see our mistakes.  But that is what we are asking of people in the agile world:  to pair-program, to build in iterations, to meet the definition of done, to estimate and openly miss those estimates.  And not only that, we are saying that people should do more of it, fail more often so that those failures are smaller, and confront those failures and learn from them.  That’s a TALL order for anyone.

(Unfortunately?), transparency and openness are absolutely necessary for sustained high-performance.  And being able to fail quickly and learn from our mistakes is a hallmark of great teams.  Every single team that I have witnessed achieved hyper-productivity has achieved this state has found a way to be comfortable with failure and leverage it for learning and success.

So, how do you get past that discomfort, pain, and fear?  Well, in many ways you don’t, it will always be there for many of us, however we can make it more palatable and increase the chances of truly achieving and sustaining the benefits by making things safe.

the state of being safe; freedom from the occurrence or risk of injury, danger, or loss.

In many ways, we feel a risk of injury, danger, or loss when our mistakes are made public.  Are we going to be blamed if our mistakes are visible?  Will it affect our review at the end of the year?  Will someone roll their eyes and say that they can do it much better?  Will we be humiliated or will we lose standing on the team?  These are things that exist in many of our lives at work.  And when they do, we feel unsafe.  And when we feel unsafe, we will shut down and shut down transparency and openness along with it.

So what can we do about this?  Well, we need to make things safe.  How do we make things safe?  As always I don’t have a recipe independent of context, however, here are some effective tactics:

  • Be reflective.  When there is an issue or problem ask yourself how you are part of the problem.  Listen – really listen.  When people feel listened to and acknowledged, they feel valued and they feel more safe – even if they end up being wrong.
  • Respect people.  No matter what you say, or what you do, your opinion of the people you are working with seeps out; sometimes through body language and sometimes through the tone of voice and other means.  You can’t fake respect and everyone can sense it.  So, if you want to create safety, you genuinely have to respect others and see them as equals.  (Anatomy of Peace is a great book on the subject.)
  • One thing my friend Steve Peha does when he is facing a problem with someone else, he addresses himself and his perception of what’s happening and his reactions to the issue at hand instead of (as most of us do) pointing the finger at the other person and telling him/her how they have goofed and upset us.  Christopher Avery’s work on Responsibility Redefined is spot on here.
  • Trust people.  You don’t have to be nieve about it, but start with trust.  You can always re-evaluate if you’ve misplaced your trust.  Trust in another person shows that you see they have value.
  • Focus on the subject – not the people involved – and be ready to be wrong.  It’s ok.  None of us have it all figured out.  So instead of arguing who is right or wrong, focus on the work; the subject – instead of yourself or the other person.

Looking back on this list, it feels woefully inadequate for such an important subject.  But it is what I have today.  Maybe tomorrow I’ll have better answers.

 
4 Comments

Posted by on April 19, 2013 in Individuals, Interactions

 

Tags: , , ,