Tag Archives: ownership

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!)


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.


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


Tags: , , , , ,

Fooling Yourself About Ownership

Last week I was the agile conference in Nashville.  I had one session to present.  Unfortunately (and very fortunately) it was the very last session on the very last day.  That meant I had all week to worry about the presentation AND that the people attending would be exhausted.  Oh yes, and finally, I was up against Arlo Belshee and Esther Derby in two other sessions.  (I’m a very good complainer.)

Oh, the good part, I was co-presenting this with Steve Peha.  And Steve is a perfectionist.  To put it mildly, I’m not.  So Steve and I spent all week preparing for this session – one that I had taught in multiple forms over the years.  And I thought that there wasn’t much more to add or any new insights.  Boy, was I wrong!  So wrong, in fact, that I’ve got multiple blog posts that I’m sure are going to result from the week of preparing together.  This is the first of these blogposts.


Ok, enough rambling (for now).  Let’s dig in.  Ownership.  Yes, we all know it is important.  In the software world, we’ve all learned from Christopher Avery about the responsibility process model and how we go through several stages: blame, justification, shame, obligation, and finally ownership.  And we know about this in all disciplines – business, education, government, etc….   Ownership is a well known (although not so well practiced) behavior for success.

So what’s new?  Well, it first came out in a discussion late Sunday night over coffee.  We were using some of our own life examples about what safety, respect, and ownership meant to us and testing my theory that if you have these three things, you are in a much better position to get great results – especially in a team.

And so as we were working through Steve’s example:

I was having a rough relationship with a more senior product owner in the company.  We couldn’t seem to work together.  He’d give me some requirements to take to my team and I thought I’d understood them.  At the end of the iteration, he’d say that we’d failed to meet his goals and I felt dejected.

And it kept happening.  No matter what I did, I couldn’t find a way to get aligned on what he wanted.  It was pretty bad.  I felt unable to do my job well.

It was so bad, that I basically said “ok, I’m just going to take notes without discussion and then do my best to work on this myself offline.   I’m going to make the best out of a terrible situation.”

So I’ve known Steve for several years, and he is really smart – I mean the type of smart that you wouldn’t believe.  Plus, he is humble.  He is a domain expert in the field – in fact he blew anyone away at the company in that regards.  He knew the domain significantly more than the senior product owner.  And so, for me, I could see that he probably intimidated the hell out of the other product owner and the other guy was just acting out; trying to feel less incompetent by pointing the finger at Steve in this way.

But Steve couldn’t see that, I could see he was still frustrated by the situation.  In fact, he felt he had taken ownership of the situation and made the best out of a very bad situation.  And, in a way, he had.  He had taken ownership of the requirements to be written.  But that obviously did not lead to success.

What Steve had done was the easy part.  It is also the part that doesn’t really matter as much.  As we talked about it Steve came up with a new insight:

I blew it!  I fooled myself into thinking I had taken ownership of the situation, but all I did was create more work for myself.  I dropped the relationship because it was too painful.

Steve had not taken ownership of his relationship to the senior product owner.  He just let it go.  And, in a team, that is exactly the wrong thing to do.  If you are in a team setting, you will be much less likely to succeed if you only focus on the problem – or your part of the problem.  Even if you focus on the entire problem – your part and everyone else’s part – you are still in a bad spot.  You’ve created more work for you and ignored your relationship to other team members.  You need them to succeed.

So, to maximize your chance of success, you must own the relationship also.  No, you can’t control anyone else’s actions, and I’m not suggesting that you do.  What I am suggesting, is that for successful teamwork you must own the relationship as well.

Once you’re there mentally – owning the problem and relationship – you are ready.  That means not blaming others for the failed relationship; not justifying why it deserves to be a bad one because the other person is an asshole; not making any excuses.  You roll up your sleeves and work on possibly the single most challenging and rewarding work there is on teams; working on relationships with your colleagues.

The ‘how’ of fixing relationships is covered in many books, and I’ve got much to say on the subject.  But that will come out in later posts.  What I want you to remember is this: true ownership is ownership of the problem and your relationships to your team members.  All too often we fool ourselves into thinking we are coming from ownership by only owning the problem.

1 Comment

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


Tags: ,

How To Be Mediocre Without Even Trying


Have you ever been on a team of aces – the best of the best – and failed? Have you ever been on a team that consisted of average people, found your rhythm and exceeded expectations? Have you ever been on a highly successful agile team and then later used the exact same practices with another group of people, but failed to get the desired results? Why do the same practices work really well with one team and not another? What is behind this?

There is a frequently self-fulfilled stereotype among technical professionals that we are not good at interpersonal skills, that such are traits of one’s personality, and consequently un-learnable. Many of us feel uncomfortable with the topic so we tend to underplay its importance, which is evidenced by our characterizing such skills as touchy-feely. We focus on our work – the real work – of writing code, coming up with and maintaining designs, and architecture. The touchy-feely things are unimportant and frequently get in the way. The technical practices are the important thing.

Hereʼs the [hidden] truth: we are wrong. Agile methods constantly bring up problems and upsets. Agile methods do not ensure success alone. Our ability to respond to problems effectively as individuals, teams, and organizations is the real key to success. The answer to success is therefore not in the technical practices but in the human dynamics beneath our methods. Human dynamics are the difference between a failed team, a team that gets by, and a hyper-productive team. Unfortunately, many are unaware of these practices, and therefore using different agile methods alone becomes a hit-or-miss gamble.

The good news is that these human dynamics are learnable. In this article I will explain why this skill set is so important to highly productive software development and give you a simple model to better understand what these skills are, and when they should be used. But before we dig into the skills, letʼs take a look at software development in general.


Here is a hypothetical situation that I have presented to many of my students:

Suppose I was your client and I asked you and your team to build a software system for me.Your team proceeds to build the software system. It takes you a full year – 12 months – to deliver working, tested software.

I then thank you and your team and take the software and throw it out. I then ask you to rebuild the system. You have the same team. The same requirements. The same tools and software. Basically – nothing has changed – it is exactly the same environment.

How long will it take you and your team to rebuild the system again?

When I present this hypothetical situation to my students – many of them with 20+ years experience in building software – they typically respond with estimates that are anywhere between 20% to 70% of the time. That is, rebuilding a system that originally takes one year to build would take only 2.5 to 8.5 months to build the second time around. This is a huge difference! Do you know any one factor that can affect software development that much?

So, what was the problem? What was different? The difference was that the team had learned. They learned about each other as a team and have gelled over the year. They learned about the true requirements – not just those written down. They also learned to use the toolset, the idiosyncrasies that come up during all software development. Basically they worked through all the unknowns until they built and delivered a successful software system. Learning is THE most costly part of software development.

Thatʼs the main reason that agile practices (sometimes) work so well – they are all about recognizing and responding to change. Agile practices from test-driven development and continuous integration, to iterations and retrospectives are all accelerating feedback to enable the team to learn faster. By cycling at every possible instance, agile teams have the opportunity to accelerate learning and address the most costly portion of software development.

But learning is not automatic and it does not come for free. Anything that impedes our ability to learn will take us down the road to mediocrity. That is where human dynamics come in. If we donʼt know how to leverage problems individually and as a team and organization, then we cannot benefit fully from agile practices – no matter what those practices are.


Software development is a team sport; we either all win together by producing great software, or we all lose together by not achieving our goals no matter how well we execute individually. For software teams, there is no such thing as “it is not my problem”. Believing that a problem belongs to only one member of a software team is as invalid as for people on a plane to say “it is not my wing on fire”.

These skills are important for everyone, even purely technical roles such as developers and architects. Consider the following scenario as an illustration:

I am a developer on a team who gets the architecture and/ or design handed down from above. I just got out of a meeting with our architect where he explained the reasons behind why things were set the way they were. He was very polite and said all the right words; but I did not feel listened to.

I brought up what seemed like important issues of things that are infeasible given the current libraries we use. I was unsatisfied with the architect’s answer. He just explained the issues away as though brushing them aside. On the surface I can’t really argue, but I feel frustrated because his ‘words’ are right but I still have a sinking suspicion that things are not right. I am also a little annoyed that my architect didn’t take me seriously and I have started thinking of him as disconnected and an ivory tower architect.

This has several effects on our productivity:

• I may not do my best at solving the problem his way and will be glad if it fails and say ‘I told you so’.

• I may ignore the architect, because of my new perception of him, and that will cause an inconsistency in the code. If I am right, people coming to work on the code after me will have a harder time understanding it in a larger perspective. If I am wrong, then I’m wasting my time on a solution that will not work and impact the architect’s perception of me.This, in turn, will make me more resentful.

• I work much more effectively when I’m bought in and excited. When I’m doing things out of obligation I do what’s necessary to get by. It is also more difficult and stressful on me, which directly affects my productivity.

• The architect will not trust me no matter what choice I make. If I do what he says slowly (because I’m coming from obligation) he’ll think I’m slow. If I don’t do what he says he won’t trust me at best and will consider me an obstacle at worst.

This scenario shows how sincerity (the architectʼs and later mine) affects ownership. I abdicated ownership in the scenario when I did work out of obligation. My perception of the architectʼs insincerity reduced my trust in him, and my actions will reduce his trust in me. All of this happened because I perceived a problem but did nothing to confront the issue or correct it. All of this happened in an environment where ʻarchitectsʼ hand down the law to ʻdevelopersʼ – an environment that leaders in the organization have created and maintained.

My part in it, even if I am a lowly developer, is that I have chosen to join such an organization, and I let my upset affect my work and did nothing to resolve it.

In all of these scenarios I have impeded my ability to learn and the ability of others to learn by not confronting the upset and working it out. The odds are good that if my architect reacts negatively and does not address my upset that the problem will fester and grow and continue to affect our ability to learn and thus our productivity.


Now, as I said before, agile practices are especially good at bringing problems to the forefront because of the numerous inspect and adapt cycles. How we react to those problems, both individually and as a team, makes the difference between hyper-productivity and mediocrity. To that end, when we encounter a problem there are several fundamental, learnable skills that deeply affect our effectiveness as technical professionals in a team environment because they equally affect our ability to learn.

If the scenario above was on an agile project, my code would be quickly used by others and the problem would be brought up again and again no matter which route I took. This would have been likely to increase the animosity between the architect and myself. We might very well have ended up in a difficult confrontation that would have entrenched us in our positions because we saw each other as obstacles.

Or it may have been solved – if either of us were skilled in the human dynamics of regularly solving these types of problems. The teams that are successful with agile methods are the ones that have members who are adept at leveraging such problems for their benefit and that of their peers.


Iʼve shown a typical scenario in which an upset impedes learning. However it does not have to be that way. Every upset is an opportunity to grow and learn, both individually and as a team. If I could solve the upset and take ownership of the problem I would keep from impeding my learning and that of the team. And if I could find a way of doing this myself – without having to rely on anyone else to change then it becomes feasible. Those are two pretty big IFs, but those are the skills that we must master to succeed. Those are the skills that will turn our losses into wins and make every problem an opportunity for success. Those are the skills that are more important than the technical agile practices.

Furthermore, it is not only the skills that matter, but when we use those skills. For example, I put the blame on my architect before asking how I had a hand in creating this upset. I put the solution to my upset squarely on the architectʼs shoulders since he is at fault for my problem. Now the only way to solve the upset is to change the architect and since I see him as incompetent anyway then Iʼll have an extremely hard time of doing so. So the first category of skills that we must address, before anything else, is working on ourselves. Can we take ownership of our own problems? Below are five categories of human dynamics skills that we must address in the proper order to reliably and repeatedly leverage our upsets for improvement:

  • SELF. By far, the easiest person to change is ourself. This is our greatest point of leverage in solving a problem. Instead of blaming the architect and starting down the road of either working out of obligation or doing my own thing, I should look at myself first. If I take ownership of the problem and see the architect as a team member and not stereotype him as an ivory tower architect I can prevent a vicious cycle.
  • CLARITY. When facing a problem we are often very aware of what we donʼt like about it. We are aware of the problem. But are we aware of what we want? I was very aware of what I did not want – I did not want the architect dismissing my ideas or looking down at me. But what did I want? It was clearly more than just presenting my solution. Feeling disrespected and undervalued had a large part in my upset and my actions moving forward.
  • ASKING. Once we are clear on what we want, chances are we havenʼt asked for it. The next step is to ask for what we want from others explicitly. I did not ask the architect for respect I just assumed he did not respect or value me and subsequently I lost respect for him.
  • AGREEMENT. Asking for something does not mean you will get it. Have we reached explicit agreement? If we let problems be, the best we can expect is that they will linger and many times they will fester and grow as they may with the example above.
  • CONFRONTING. Once we have asked and agreed upon something then it is appropriate to call someone on a missed agreement. Many of us are extremely uncomfortable with confrontation and are not skilled in doing so in a constructive manner.
    This means that many of us either shy away from confronting others or are so uncomfortable with confrontation that when we finally get the courage to do something we do so under great pressure.

The above categorization is an umbrella for a large set of human dynamics skills that are learnable and applicable to our day-to-day work. There are many models and discrete practices that fit under each of these categories that help us implement these actions. I would like you to remember that order matters. Before you call someone on something you believe they did wrong, go through steps 1 through 4 before executing step 5. How did you help create the problem? Are you clear on what you want? Have you asked for it? Did you get explicit agreement? Only then is it fair and proper to call someone on a missed agreement.


Beware that small upsets that go unaddressed build up. Agile methods can be painful and counter-productive if we donʼt address the upsets that come up frequently because of the cyclic nature of many of the agile practices. That in turn, impedes our learning little by little, which can slowly bring our progress down to a halt and put us in a situation worse than before we started adopting our agile method of choice. Since learning is the largest part of software development, we need to figure out how to learn from every upset instead of allowing upsets to slowly bring our productivity to a near halt.

1 Comment

Posted by on April 16, 2013 in Individuals, Interactions


Tags: , , ,

Instilling Ownership

So, back in 2005, I was introduced to the importance of ownership in software development teams by Ashley Johnson who had just met and attended a presentation by Christopher Avery on The Responsibility Process.  Over the next few years, I met Christopher, attended what I could of his presentations, and eventually started my own journey to learn about they human dynamics of high performance teams.

So, these days when I tell people I work with about Avery’s model and ownership, the number one question is “how do I get others to take ownership?”

In general, I don’t have one answer that is independent of context, but here is a list of techniques that I’ve found useful:

1) Always start with yourself.  You need to take ownership for your actions, and the results you and your team are responsible for.  (Yes, you read it correctly, responsibility for the results of your team, not just yourself.)

2) Respect the people you work with.  We have bulls**t sensors, and we know when someone asks us to do something because they are looking down at us or see us as obstacles.  In other words, we must see other people as people and equals, before we start talking about difficult issues like taking ownership.   (See Anatomy of Peace and Mike Sahota’s write up.)

3) Explain ownership then ask for agreements to come from ownership.  I shamelessly steal Avery’s model and relate it to software development and how a lack of ownership can bring a team’s productivity down significantly.  At Gemba Systems, we thought it was important enough to put it as our first value in our code of conduct.

4) Make it safe.  It is really difficult to take ownership when everything is going wrong.  It is difficult for us to confront and admit our failures.

Hope this helps – amr

Leave a comment

Posted by on April 11, 2013 in Individuals, Interactions


Tags: ,

Avoiding Invisible Impediments to High Performance (QCon NY)

I’ve been invited to present at QCon NY this year in the tutorials track by Peter Bell (organizer of the culture track).  Jim McCarthy and Dan Mezick will be there – and they should be great presentations!  But I digress…

So “Avoiding Invisible Impediments” is a full-day tutorial on avoiding….  well… invisible impediments.  All those issues around human dynamics and culture that aren’t necessarily obvious and get in the way of true high-performance.  

No matter how good our technical ‘chops are, if we don’t have the human dynamics and culture for high performance, we’ll experience mediocre results.

Some of the topics that we’ll cover are:

  • Ownership and responsibility,
  • Way of being,
  • Safety,
  • Making and keeping agreements,
  • Ability to fail,
  • Paradox, and it’s place in teamwork,
  • “Seeing” culture,
  • Culture design,
  • ….

We’ll spend all day exploring these topics, making them real and concrete by looking back at the work we’ve done in the past and how these issues can easily block our effectiveness.  

Finally, we’ll discuss practical ways of making these “touchy-feely” topics a reality in our teams and organizations.

Leave a comment

Posted by on April 9, 2013 in Individuals, Interactions, Teams


Tags: , , , , , , , ,