The end of agile (XI)

(to listen to the soundtrack of this post click on this link)

“Mission First
People Always”
— US Air Force Mantra

CBGB OMFUG was a club located at 315 Bowery, between 1st and 2nd Street on Manhattan’s Lower East Side, in New York, that became the epicenter of punk and new wave in the early eighties. Talking Heads, The Ramones and Blondie all made their debut at CBGB.

In his book “How Music Works” David Byrne, musician and founder of Talking Heads, says he saw CBGB as a self-organizing system. “An emergent entity governed by a few rules that Hilly Kristal established at the beginning, rules that allowed a whole scene to emerge in New York in the late 70s”.

My unit developed the same way the punk scene did at CBGB: organically, emerging from very few rules. Not because it was especially planned that way. Partly because I’m far too lazy to go around setting up a lot of rules. And then, we didn’t have much time to organize ourselves, since there were very few of us and we had a ton of things to do.

The job that ate my brain

Five o'clock rolls around I feel so glad I kiss the ground
There isn't enough hours in the day, there's got to be a better way
— The Ramones

One day I was leaving work very late and saw that Rosita, who works in operations, was still busy at her desk. I went over and asked what she was working on. She explained that it was a process she had to run once a week, and that with everything else she had to do during the day she never got to it in time. So she preferred to work on it once nobody was bothering her anymore. I dug a little deeper and found that a large part of Rosita’s problems came from a lack of systems, or from flaws in the ones she used.

I talked to Miguel and the rest of the development guys: their mission was to get Rosita home early, as she should be. I didn’t tell them specifically what to do; they would have to figure out how to make it happen, and for that they would have to talk to her and to other colleagues in operations and carry out improvements.

A very simple example of what was going on: Rosita used an application for uploading files to be processed. The problem was that the files had to be uploaded one by one. Miguel spotted this in the first conversation and it took him no time at all to modify the application to upload several files at once. It seems super obvious, but the application’s original programmer never bothered to find out what the users really needed.

That’s how the guys started making small improvements. I remember we had more than 400 tickets in Jira that got resolved in 4 months of work. One day I ran into Rosita in the elevator at 5 in the afternoon. “Leaving this early today?”, I asked her. “Yes”, she said; not only had she finished her work, her boss had also given her the next day off. She said something like: “I don’t stay late anymore, thanks to the improvements your guys made”. That made me proud of my team, and I thanked them for it.

Around that time they built another tool they called “Ejecutor de Procesos” (Process Runner), which we still use today. A system that has solved many problems and made our users’ lives easier. An application whose design, I must confess, didn’t convince me much at first. We had a team with a lot of potential, but all of it was on the verge of being lost because of my own mishandling. But let’s keep moving through this story.

Often we do a poor job of selecting the people we bring onto our teams.

Sometimes we select people who don’t fit this team spirit, and that’s when you have to make a hard decision: letting them go.

The Road To Nowhere

Well, we know where we're goin'
But we don't know where we've been
And we know what we're knowin'
But we can't say what we've seen
— Talking Heads

Letting someone go is one of the hardest things you have to do as a leader or boss. Nobody really prepares you for it. After all, you invest time recruiting people and you don’t want to end up in that situation.

I remember one occasion when we had on the team a person, a development engineer, who didn’t fit our way of working and didn’t collaborate much with the team either. He was smart and technically skilled, but he did things the way he saw fit, with no regard at all for the few directives and practices we had defined at the time.

When we realized he was a problem, I started a coaching process with him. You can’t let someone go overnight; you have to give them the chance to improve. You have to guide them, tell them what’s wrong. Explain why you’re not satisfied with their work, and what you expect of them.

I went through this with that developer, but without success. That was when my boss, Claudio, took the lead and talked to him; we followed up and got nowhere. By then we had already decided that Carolina would take charge of the development team. Regardless of that decision, she told us she would take on the case: she would talk to this kid, follow up with him and succeed where we had failed. She felt confident about it. She asked us for a couple of months and we gave them to her.

But she didn’t succeed. Despite her confidence in herself and in her efforts, she did as badly as we had. There was no way to get that person aligned. So one day she told us we were right, that there really was no other way than to part with that engineer.

Fine, we told her, then now it’s your turn to fire him. But don’t worry, we added, we’ll support you through the process. One day we went out to lunch and gave her some tips and advice for facing that moment.

In my experience, most of the time when you fire someone there are no big problems. Often it’s no surprise to them, if you’ve been giving them the right signals. The problem is when they don’t see it coming, or worse, when they’re incapable of understanding what’s wrong with them, when they have no sense of self-criticism whatsoever. That last kind of person is usually the most difficult to deal with.

So there we were, on the day of the dismissal, the three of us sitting in an office, with Carolina telling him we would no longer be working with him and handing him his severance papers. I was there as an observer, and a witness to the process. This developer’s reaction was unexpected: he got very upset and started an argument, which I had to cut short. The decision had already been made; there was no need to continue the conversation. You should never get drawn into further arguments at that moment. Dragging out a firing is good for neither side.

But it was definitely not a pleasant experience. That’s why you should avoid getting into those cases. So we had to learn and make a couple of changes:

• Improve our selection process
• Give early and constant feedback to team members.

The latter is what I’ll talk about in this article; the former I’ll expand on some other time.

Heart of Glass

Lost inside adorable illusion
And I cannot hide
I'm the one you're using
Please don't push me aside
— Blondie

In her book “Radical Candor: How to Get What You Want By Saying What You Mean”, Kim Scott illustrates it with the following chart:

There are two dimensions we move along when we relate to others. On the vertical axis is caring personally, genuine concern for others. On the horizontal axis is challenging directly. At work, the challenge has to do with demanding results from your team.

If you remember what we saw in chapter 9 of this series, there I showed you a diagram with four quadrants similar to this one. In that case the dimensions are psychological safety versus motivation.

This is analogous, but from the perspective of how you relate to the members of the team you’re in charge of.

It’s important to care about people, but if you never challenge them, if you never mention what you disagree with, what bothers you, if deep down you dodge conflict, you fall into a zone of false harmony. This is what Kim Scott calls Ruinous Empathy. You don’t want to do harm, you don’t want to tell that person what’s wrong, because you want to be nice to them. This of course requires that you really do care about not hurting that person, because when you don’t actually care about their feelings, what you’re really doing is Manipulative Insincerity.

The worst is when you don’t care about people’s feelings and are only interested in challenging them. That’s where you fall into the quadrant of Obnoxious Aggression.

It was between 2014 and 2015 that I fell into precisely that quadrant, and I hurt my team a lot with that attitude.

Life During Wartime

This ain't no party, this ain't no disco,
This ain't no fooling around
This ain't no Mudd Club, or C. B. G. B.,
I ain't got time for that now
— The Talking Heads

At the end of 2014 we started developing an important project with a tight deadline. On top of that I wanted us to implement microservices and deploy directly to the cloud. I had asked for authorization to experiment with these technologies on this project; the promise was lower costs.

I made several mistakes. The first was bringing in a developer to whom I gave too much freedom and authority, over Miguel, my most experienced developer. My idea was for them to challenge each other. I wanted to stretch Miguel, because I felt he always solved everything with the same tools, and I wanted more innovation. But the person I brought in wasn’t the right one, and neither was the strategy. I was manipulating Miguel, and I wasn’t listening to him. In the end I had to fire that developer; not only did he create conflict, his solutions turned out to be technically inadequate.

Another mistake was not securing internal support. I ran into resistance from the systems team, who felt, rightly, that I was stepping onto their turf. The project’s security was questioned. I had many arguments in those days. With my team, with my peers, and with my bosses. Every year we run a workplace climate survey, and in 2015 my unit got the worst result in the entire company. It couldn’t have been worse.

[Around that time, too, we lost two valuable people who supported us on Elizabeth’s team, Contardo and Gustavo, who had arrived when we reorganized the operations team and turned it into the Quality Control and Support team. With them we tried to introduce continuous integration, without much success, because of a phenomenon I call “dark matter”, which I’ll tell you about later in this series. We couldn’t keep them; they got a job offer we couldn’t match.

Everything Kim Scott recommends in her book, I was doing backwards. I was a terrible leader. I wasn’t stretching people, I was squeezing them. I didn’t really care about people, only about the objective. Of course I collapsed too.

That was when I had to back up a little. Stop and swallow my pride. I had to give ground on some points, negotiate with my peers, ask for help and, above all, talk to my team and apologize to them.

In 2015 a whole era came to an end for my team at Previred. We didn’t know it at the time, but that was the year that marked a positive turning point in our management and our way of doing things, a moment of crisis that would make us reflect.

Without coordinating it, Carolina, Elizabeth and I each decided to go back to studying. We knew we had to make big changes, because we were about to ruin something that had a lot of potential. We had to change and we did, and that is what I’ll tell you about in the final chapters of this series.

Notes:

Chapter 10 of this series is here.

Chapter 12 of this series is here.

The first chapter of this series is here.