Self: All Solutions Begin with You

Written by Amr Elssamadisy

Previously...

In the previous article I made the argument that human dynamics are fundamental to the success of any software development team because they directly affect our individual and group abilities to learn from upsets.

I also shared a story illustrating how a seemingly technical issue could be undermined by the human dynamics context in which it resides. Finally, I shared a set of skills that directly affect our ability to leverage a problem for learning:

1. 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.
2. 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.
3. 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.
4. 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 did with the example above.
5. Calling.  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.

In this article I will dig into the details of the first of these human dynamics categories - self - and how it can be applied to our everyday software development situations.

Introduction

Have you ever been annoyed at one or more of your team members because of a mistake they made that affected you? People outside your team - management, testing, sales, etc.. - hampered your ability to do your work well - haven’t they? Are you trying to figure out how to affect others to improve the current situation and keep it from happening again? This is weighing you down and affecting your enthusiasm - right? If you could just fix these other people you would finally be free to excel - or will you?

In today’s software development world we are looking for the right tools and perhaps the right processes to solve our problems. Our belief, as evidenced by our actions as a community, seems to be that if we just get the right tools in place and perhaps have the right methodology we will find our rhythm. That is true, to a point. The rest of that truth is that to build better software, we need to build better people. And the point of greatest leverage is ourselves. In fact, if we don’t start with ourselves, chances are we will not have any meaningful affect on others and may exacerbate the problem.

In this article we will focus on dealing with upsets by first focusing on ourselves before turning to others.

The Human Response to Upsets

Christopher Avery and Bill McCarley created the Responsibility Process Model to describe how we typically respond to events during an upset. They describe a series of steps that we all go through, even if momentarily. Here are a couple of illustrative stories:

With the stories above, if I acknowledge that correct placement of my keys is my responsibility then I can solve the problem. With respect to travel, if I had owned the situation, I could have talked to my manger and discussed my burnout and probably would have gotten a better travel schedule. Even if I had not, I could have calmly decided to continue traveling (and not be upset), or leave the company for a different environment.

We only truly do great work when we take ownership and responsibility for our upsets - even when there are others involved. Until I ask and answer the question “how did I help create this problem?”, I cannot start to fully resolve it from a passionate and energetic place.

Common Objections to the Responsibility Process Model

As I learned this model and started to practice it, I had a series of questions - things that didn’t seem realistic:

What if the problem really IS someone else’s fault?

Challenge yourself by asking the question and digging deeply “what have I done to contribute to the problem?” The answer is rarely nothing. I accepted a travel schedule without a conversation with my manager.

People make obvious mistakes that are just common sense, but that is our perception, assumption, and world view. Do we have any agreement with them not to do what is obviously wrong to us? If not, that is one way that I have become upset without seeing that I participated in the problem with unclear expectations.

Even if someone else caused the problem, since our ability to affect others is much weaker than our ability to affect ourselves, taking ownership for a problem gives us the best chance to do something productive.

Even if I do take ownership, there is only so much I can realistically do.

That may be true. But having a mindset of ownership changes your perspectives and the way you see events and opportunities. With a different mindset, you may find opportunities you never noticed.

In the worst case, if there is nothing you can do, then you always have the choice to accept the problem or leave. You always have a choice. By taking ownership of the problem you are more able to be effective.

My environment won’t allow me to take ownership.

You will be surprised at what you can do individually once you take ownership. More often than not, there will be things you can do that you have not seen before because you were not in a mindset of Responsibility.

In the worst case, you can ask yourself, “what state am I in when I say this?” Chances are you are not coming from Responsibility.

There are few business scenarios that can take away your ability to own the problem. You can make a conscious decision to leave that environment if you accept the consequences of leaving. At the same time, if you do not pay the consequences, then you can choose to live within the environment and by its rules because it is a trade-off that you made consciously. You no longer “have to” do anything, you choose to.

How do I get others to take ownership?

This is one of my favorites, and was probably the first question that came into my mind when I first learned the model. The simple answer is that you don’t. This is an individual skill and you practice it for yourself.

But the simple answer isn’t completely accurate. One of the best ways to spread this is to practice it and be transparent when you do so. I know of one person who printed out the Responsibility Process poster and would take it out every meeting where everyone can see. I know of another who put it up in his work area and invited people to ask about the poster and how it applies to their work. However, when it comes right down to it, the individual has to choose to take ownership instead of someone else trying to force it upon them (which usually results in obligation).

What does this have to do with software development?

How does our place on the Responsibility chart affect our ability to learn individually? Do I have a better chance to learn effectively in blame, justification, shame, obligation, or responsibility? For me, the only chance I had of solving either of my problems and learning effectively was to take ownership, ask myself “how did I help cause this problem?” and act upon it. For me, I oscillated between blame, shame and obligation with respects to my travel problem and ended up quitting a really good job because I did not take ownership of the problem.

Way of Being

The Responsibility Process model is a wonderful way to set the stage for effectiveness and productivity in our environments. The Way of Being model, described in detail in The Anatomy of Peace, is an equally effective and complementary perspective on understanding and dealing with upsets. Our way of being towards another person boils down to the answer to these questions:

• Do we see the other person as a true human being, an equal, that is doing their best? If we see another person as an equal, a person who has hopes and dreams and is trying to do their best, then our heart is “at peace” with respect to them.
• Or do we see that other person as an obstacle or an object? Do we see them as (the cause of) a problem to be removed? Do we see them in terms of our hopes, dreams, and fears? If we see them as obstacles, as causes of problems, of things to be fixed, then our heart is “at war”.

Why is this important? Simply put, communication happens at a level deeper than words and actions. We communicate what is in our hearts, not our words, and not even our actions.

Let me say this again, our way of being - how we perceive others within - is much more important than what we say and even more important than what we do. We communicate our respect or lack thereof when talking to others. People can tell whether I am thinking of them in what I am doing or if I am thinking of my own convenience and reputation and act accordingly.

Answering these questions for yourself will help you better understand the way of being concept:

Have you ever worked with someone who was really smooth? They said exactly the right thing. They did (on the surface) exactly the right actions. Yet you knew they were insincere. You knew that you were only a means to an end. You had a gut reaction of not liking them and being turned off. And if you had to work with them, you did it out of obligation at best.

Conversely, have you ever worked with someone who was really rough around the edges? But somehow, you and others respected them, listened to them, and in many times were inspired by them. These are people that get things done and work wonderfully with others - even if they have a rough exterior.

The two examples above show that our way of beings are communicated and are always communicated to others.

For me, specifically, here are two scenarios where this really came out:

Us vs. Them

Now, let us tie our way of being into today’s software development organization. One of the most common problems in todays business world is the problem when teams blame each other. “Our managers don’t get it”, “the testers take forever to get back to us”, “the developers write buggy code”, “ the stakeholders set ridiculous timelines”, “ the other component team doesn’t really get it”, and so on.

This is probably the single most common problem in today’s organization and exists between individuals, teams, and departments. This is also the one problem that will never be solved without addressing our individual way of being towards others.

If I am communicating my way of being, no matter what I say or do to convince others to do something differently (such as test driven development), nothing will get done if my heart is at war and I see them as obstacles. The “lazy developers” know that I think they are lazy. No matter what I say or do, until I see them otherwise, I am sabotaging any efforts I put in to help them learn to do something differently.

When our heart is at war with others, that is communicated, and all our words and actions are dismissed, worked-around, and fought tooth-and-nail. And, believe it or not, when our heart is at peace, things happen differently and people respond to that. They still may not do what we want, but they will soften towards us and progress becomes a possibility.

Common Objections to the Way of Being Model

There are several questions that I get when I finish telling someone about this model, the most common of which is an awkward silence where they don’t want to be rude :) After a little digging, here are some of the questions that people commonly have:

Really?! Our words and ACTIONS are not important?

Only you can answer this for yourself. I’ve found that most people can convince themselves of the truth of this statement in retrospect.

Think back to your own problems and issues. Can this model possibly make sense when examining past events? What about your Us vs. Them problem, can you see how your way of being is communicated? Could this be the reason this problem has been intractable for so long?

How do I know if my heart is at war or at peace?

You cannot be angry and have a heart at peace. If someone hurt you or is causing a problem, you can have two reactions. If your heart is at war, you will probably be angry at them and not in Responsibility.

However, if your heart is at peace, you will react to the exact same facts with patience and compassion with no anger, and still work to solve the problem.

What about the way of being of the others?

This, like the responsibility process model, is an individual model. So you shouldn’t go talking to people who are unfamiliar with this model about their way of being towards you.

However, what is really beneficial, is that YOUR way of being is communicated. As soon as you have a heart at peace, the other person will instinctually feel it and it almost always paves the road to further collaboration and communication. But this comes first.

What does this have to do with software?

Virtually all of software is built by teams of individuals. This paves the way for highly effective and productive teamwork. Without a heart at peace toward others you are handicapping your chances for a successful solution.

In my example above with the A-Team, we finally fixed the issues, but it was much more painful, time consuming, and unpleasant than it had to be. We could have done a much better job and enjoyed it if our hearts were at peace.

Is this related to the Responsibility Process model?

The models were created independently, but they have significant overlap. A heart at war is one that is predisposed to blame, justification, and obligation. Having a heart of war is incompatible with taking ownership and being in Responsibility.

How Can I Implement These Ideas NOW?

There are challenges in every business situation. These challenges may or may not cause us upset. If they do not, then they are not obstacles to solving the issues at hand. We enthusiastically look for solutions and make progress.

However, for many of us, these challenges are stressful. We are upset with our current situation. When we are upset, our hearts are at war and we are not coming from Responsibility. These aspects of our internal nature directly affect our ability to solve the problems at hand and to work with others effectively.

Whenever something is not working as you would like or expect it to, your first step to solving the problem starts with you. If there are any others involved in the problem, check your way of being. Know that if your heart is at war, that is what will get communicated and not your words and actions.

Check your location on Responsibility chart. Are you blaming? Are you at obligation? Are you elsewhere? Work your way up the ladder until you take ownership of the situation.

Finally, remember the first article: learning is the bottleneck of software development. By coming from a heart at peace and Responsibility, you are paving the way for your learning and collaboration with others. That is be your first step towards the solution.