Using Meditation to Overcome Anger

I’m a pretty passionate guy at work. Most of the time this manifests as being productive and taking initiative on things. However, it can sometimes manifest as anger when I’m not getting my way. I’ve definitely blown up and yelled at coworkers before, and I always regret it afterwards. Other times I will write a very terse email that causes more harm than good. Once I even created a ‘special’ folder for a coworker I had a problem with and accidentally showed it to him during a screen sharing session. How embarrassing!

I’ve tried a number of things to prevent negative outbursts and focus my passion only into productive pursuits. And somewhat recently I’ve found that daily meditation is like a miracle cure. I use a bare-bones app called Oak every day during my lunch time. At first I did the guided meditation sessions, and later I went through the mantra course. Now I just do twenty minutes of unguided meditation every day, with a sound every two minutes to bring my mind back if it has wandered.

I find that when I do the meditation well, I get put in a state of deep relaxation, and feel much more emotionally detached from my work. The state of frustration and anger seem to be closely related to confusion, and with my mind cleared of confusion I’m able to be even more productive than before and also feel quite content doing my work.

I still get frustrated and angry at times, and when I do I try to catch myself and hear my personal mantra, ‘ma-nah’. This is like a guiding light to bring me away from my bad state of mind and generally prevents my mood from getting any worse. Then when I have my daily session I get a complete reset again and am good for another day.

How Asking ‘Why Not?’ Can Overcome Digital Transformation Implementation Resistance

I want to share with you a technique I used to overcome some serious implementation resistance we had on a digital transformation project.

We had built a new system for transactional processing and had run several pilot transactions involving real customers and real employees using the system. These transactions went through without the sky falling, though there were some rough edges to address here and there.

We wanted to keep running more transactions through the system, so that we could learn from the real-world usage, but many of the people involved, even some on our own transformation team, were against it. We were having weekly calls at that point, but it seemed like every call we looked at the status for an hour and then promised to something about it the next week. And then the next week we would rinse and repeat, getting nowhere.

So I decided to call a much shorter, daily meeting (I called it a ‘daily scrum’ even though it was mainly business people), and started a new list, called the ‘Why Nots’. Instead of asking everyone their progress, I would ask them why they objected to putting another transaction in the system, repeatedly asking ‘why not’ until we arrived at something actionable.

The conversations would go something like this:

Me: “So John, I want to put the next transaction on the new system, why not?”

John: “Well James, Joe from accounting hasn’t signed off.”

Me: “Ok, so why hasn’t he signed off?”

John: “Because we haven’t given him a demo of the accounting features yet.”

Me: “Why haven’t we given him a demo of the accounting features?”

John: “Well, I haven’t had the time to schedule it yet.”

Me: “Ok, so the ‘why not’ on the list is that we haven’t scheduled a demo with Joe from accounting. Who do you think should take care of this?”

John: “I should do it, because he works in my office.”

Me: “Great, thanks.”

It turned out that well over 50% of the ‘why nots’ raised were actually action items for the people who raised them. It turns out that people raise objections about things they understand, and the things they understand are in their domain, and their domains tend to be their responsibility. They were complaining about action items not getting done, when they were the ones who needed to do them!

The next largest category of ‘why nots’ were imaginary problems. For instance, we would get an objection that we hadn’t built a certain integration yet. I would ask why they can’t process the transaction without the integration, and I would be told that actually they can. And so we would end up marking it as resolved, because it wasn’t a real blocker to implementation.

So we ended up with a list of over 100 ‘why nots’ in a couple of days, with over half of them completely resolved in the same time span. It quickly became clear which ‘why nots’ were really serious and those got immediate attention. Anything that required additional development got scheduled in the subsequent sprint, and once that finished we had restarted processing transactions again!

Does Agile have too many meetings?

Like every headline phrased as a question, the answer is ‘no’! But more important than the answer is the reason for it.

When a large team convert to Agile, they typically are implementing some version of Scrum, which has a set of events (read: meetings) to observe: sprint planning, daily scrum, sprint retrospective, sprint review, and backlog grooming.

On top of that, there are typically cross-team meetings and updates for management that take up additional time from the development teams. This can really add up!

We suffered from too many meetings at one point in our Agile journey, soon after we split our single Scrum team into multiple teams. It took us quite a while to get a handle on the root cause, but ultimately it ended up being a lack of ownership and accountability for the teams, which was a sign that we weren’t doing Scrum correctly. Instead, we had many stakeholders who wanted to tell the teams what to do and how to do it, without taking accountability for the solutions they were pushing.

Once we recognized the issue, we made sure to address it in our next team restructure, and pushed more responsibility and decision making into the teams. And we continuously reinforced that the stakeholders first and foremost need to clearly describe problems, not jump ahead to solutions. This made the meetings that remained much more productive and structured than the ones we had in the past, and also reduced the total amount of time spent in meetings.

If your Agile teams are also suffering from too many meetings, it’s worth considering whether they are being micro-managed or if they are as empowered as they should be.

Pull-Push Agile Training

The first time I worked with Agile I was a new programmer at a mobile analytics startup that was using “Scrum”. Every couple of weeks I would be pulled into a meeting for sprint planning in which I was told to build APIs for our analytics product. After a few weeks we would meet up again and share progress and I get tasked to build a few more APIs.

For sure, we weren’t following Scrum by the book, but I didn’t know any better, having never read the Scrum Guide, much less having done any training. What I did know is that my APIs never actually got used, so I didn’t add much value to the company while I was there.

Later, when I joined a larger enterprise project that wanted to implement Scrum, I was the only person on the project with any prior experience and I was treated as the expert. I remembered how we did “Scrum” at the startup and that it didn’t create much value, so I took it upon myself to get a certification. I certainly didn’t want to embarrass myself giving presentations about something I knew nothing about!

So I went with and got the three base certifications PSM I, PSPO I and PSD I. I then gave trainings to each new scrum team, explaining the process and how they should think about their roles.

However, this training didn’t seem to sink in, probably because it was one-off and fairly dense. So I paired up with someone in senior management to start a Scrum certification program, which was entirely voluntary, but in which the company would pay your test dues, assuming you had studied well enough to ace a practice test.

The go-getters in the project immediately jumped on the opportunity and we had between twenty and thirty people certified after about three months. But on a project with about 150 team members, this wasn’t nearly enough.

So I regularly reported the certification numbers to management, and after a while they saw this as an improvement opportunity and made the certifications mandatory. Suddenly my online Zoom training were filled with 50+ participants, and the recordings I uploaded got hundreds of views.

We ended up certifying about 120 people by the end of the year, and it dramatically changed the interactions between team members for the better.

There were three key benefits that were realized as a result of all the certifications:

  1. We had a common vocabulary
  2. We had a sense of pride in following the rules
  3. There was a desire to learn more

Although I really like the approach of the certifications (they are extremely particular about words such as “must” or “should”), I think that the benefits would come from just about any certification that we gave our team. If you look at the benefits above, none of them are particularly unique to or Scrum or even Agile.

But I think that switching to Agile inevitably means changing mindsets and adopting new vocabulary. And so if I joined a similar project at some point in the future I would adopt a similar model:

  1. Identify an “expert” who is well-suited to run a training program
  2. Create a free certification program initially, to build up some momentum and peer pressure
  3. Eventually make the program mandatory for the entire team

The risk of not doing this is having a large team that never seem to understand what anyone else is saying and who all seem to be pulling in different directions. And a model of training that is top-down from the start probably isn’t going to gain organic momentum, but rather breed resentment among the team. It’s much more effective to “pull” before “pushing” in change management.

Shoot for Jerk

Like all managers of technical teams, I’m primarily concerned with improving my team’s effectiveness. When I think about the possible ways I can do this, I try to classify them according to the nature of their impact.

For instance, I could make the team more effective by starting to code myself. Since we have an additional set of hands on the work it should (hopefully) get done faster.

There is a clear problem with this method that should be clear to most managers: it has a one-off effect and makes no lasting impact on the output of the team once I stop doing it. I increase output, but since it is a one off, it does not increase the rate of output over time.

In Scrum we typically refer to the rate of output over time as ‘velocity’, and this is our primary metric for each team. One way you might improve velocity is to address technical debt that is slowing down development. In this case you temporarily reduce output to address the debt, with the understanding that output over time (velocity) will improve.

And if you are a manager and you are making this decision for the team, then I would say there is a problem with this method as well — the boost in velocity is a one off and it will no continue to increase velocity once it is finished.

An increase in velocity over time, as opposed to output over time, to continue the physics metaphor, is what I call ‘acceleration’. And example might be allocating a fixed percentage of effort every sprint to paying down technical debt, because each time you do it, it should improve velocity.

In physics there is another term for change in acceleration over time: jerk. In fact there are some funny terms for even higher orders of magnitude of the same concept: snap, crackle and pop!

When I think about how to help a team, I ‘shoot for jerk.’ I consider the ideas I have and how they will impact the team. If at all possible, I look for something with jerk — something that will improve the team’s acceleration over time.

What this generally aligns with is the concept of empowering the team, but empowering is not necessarily a goal in itself due to potential misalignment with business value. There are certainly limits to the type of empowerment a team should receive for this very reason. For instance, you may not want the team to decide on their own salaries, as they have a conflict of interest.

Jerk, on the other hand, is aligned with business value, so I find it to be a better litmus test than empowerment when it comes to management decision-making.

So what is a good example of jerk? A good example is our system in which we rethink our team structures once every three months and make changes based on feedback gathered from all stakeholders: developers, designers, product owners and senior management. Typically the goal of these changes are to streamline communication lines and remove inter-team dependencies. Sometimes we also need to clean up ‘organizational debt’, because the needs of the company have changed or we have had people join or leave the team since the last change. Each change we make improves acceleration by empowering the team, and by implementing a continuous process of team renewal, we added acceleration over time: jerk.

This is not to say that I never contribute code to our project. I actually do this a little bit every week, for the same reason that I try to use our own products regularly: I need to understand the 10 foot view of things, as it helps inform decisions at the 100 and 1,000 foot views. Not everything you do can directly improve jerk, which is natural, since a lot of management work is staying properly informed so that your decisions can have the most positive impact.

Self Introduction

I’m the CTO of a corporate startup in Dubai and have worked on multiple digital transformation projects. My background is well-rounded, as I have a degree in mathematics, worked as an actuary, project manager, financial analyst, web developer and Agile coach. I’ve lived in seven different countries and speak five languages.

I’ve got trainer-level certifications in Scrum and have coached hundreds of my colleagues to their own certifications. I’ve taken a 10 person development team with no processes or standards and grew it to a 25 person development team employing Scrum, DevOps, CI/CD and more. Most engineers who have worked on my team said it was the best experience of their careers.

Despite the successes listed above, I’m extremely critical of my own work and perpetually dissatisfied with whatever my team’s situation happens to be at the time. I always want things to be better and better. Lately I’ve used the concept of ‘jerk’ to describe how I try to approach these problems, which I’ll explain in a future post.

I’ve learned a lot from my past successes and failures, and I hope that from this blog I can share some of this learning with the world.