Beth Kjos

Earth-shattering project ideas. Resumes. Things in between.

Monsters, Magic, and Politics: Reshaping a Dev Team

This is a story about a little software development team that got bigger in an unusual way. There were grave dangers. Pits of despair. Monsters, magic, and maybe even a bit of true love. Oh, and plenty of interpersonal politics. I hope you like it.

Names have been changed.

Once upon a time…

Once upon a time in the City Beyond the Space Port, there lived a happy development team who all got along swimmingly, both with each other and with their customer who went by the name of Mr. Desk. The team had some prominent success delivering some new features, and this made Mr. Desk quite a lot of money. It also made many of Mr. Desk’s colleagues envious: they wanted to share in the bounty made possible through the dev team’s efforts. Thus did negotiations begin, first in secret and then openly announced.

Org charts began to change. Departments got new names, or merged, or split apart. But none of that mattered to the happy little team of five developers who all got along fine. Until one day, it began to matter.

The team lead and line-management soon learned there was more work to be done, and not enough hours in the day to do it all. Surprising nobody, they decided to hire people.

It so happened that one among the team (let’s call him John) was responsible for the dark craft of corporate paperwork. It was he who kept the rent paid on the servers; it was he who coordinated disaster recovery drills; and it was he whose name appeared in the asset tracking database. But he was not happy with this role. It maddened him so that he found no time to code or even to review code, such were the demands.

Knowing well the depth of John’s despair at his plight, the management decided to hire someone specifically as a product manager: Someone to shoulder the burden of corporate paperwork and free John to do what he does best. And so in time a product manager came to join the team.

At First, Things Did Not Go Well.

The new product-manager (let’s call her Sheila) had just come back from a five-year hiatus in the hilly forests of Absurdistan. Her prior employment had been with the devotees of another sect prone to high pressure and long hours. That was not the way of our happy development team. There were clashes almost from day one. The new-graduate wasn’t performing like a veteran. Experienced developers weren’t including Sheila in their conversations with Mr. Desk. And often when they tried, Sheila seemed unaware or uninterested. But yet she was wildly busy, working until the late hours of the night with no clear purpose.

Sheila felt angry, unappreciated, and overworked. Meanwhile, the rest of the team didn’t know what to do with Sheila.

Interlude

There is a well-known model of group behavior. It goes something like this:

The story until now is: Sheila’s arrival meant the team entered the stage of forming, where it stayed for about three hours until everyone had put a face to the new name. But everyone (old and new) had all manner of expectations about how to behave and how to expect the others to behave. Sheila’s arrival changed the context in which the rest of the team would do its work, but none of the rest of the team quite yet understood how they would have to adapt. What’s worse, most people were too wrapped up in their usual activities to even recognize the need to adapt: They kept up their usual habits despite the changes going on around them. This created conflict. So the group was now in storming mode.

Then, Things Got Weird.

Eventually, Sheila called upon me for help. I thought this was quite strange, for neither was I her manager nor did I hold any formal authority. Nevertheless, I took it in stride. “What harm could it do,” I wondered, “to hear her out?” So hear her out I did, and it lasted many hours. I heard about Sheila’s previous jobs, and about her hiatus, and many other things. “Perhaps,” I thought, “Sheila needs to feel more of a personal relationship.” So I continued to listen, and nod, and listen some more. I heard of long hours, unclear expectations, and more, but so far I had no solutions.

Eventually, Sheila confided in me that she’d been fighting with John, and even in the presence of another new-hire. What these fights were over did not concern me, so I make no record of it here. At this, I knew immediately that something was very wrong. The stories I was hearing alleged unprofessional behavior, but I was clearly not the proper channel to report this. “Why oh why,” I wondered, “would Sheila tell me of all people about these particular conflicts?” I had my own ideas about what a well-adjusted person would do in her situation, and none of those ideas involved telling a peer!

Now was not a good time to jump to conclusions. So I asked Sheila what she hoped would come out of telling me these things about sharp dealings with John. She apparently wanted me to confront John on her behalf.

That was not going to happen.

I told her I’d see what I could do, bid her good night (for it was well past evening in her time zone), and then promptly sought counsel from my own manager about how weird this had gotten.

Interlude

In Games People Play, you can read about a misdeed called “Let’s You and Him Fight”, in which the miscreant pits two people against each other in conversation and then stands back to watch the fireworks. A classic scenario might be to bring up conflicting political views at a gathering. But that didn’t seem to be quite the manipulation here.

Elsewhere, you might hear of a misdeed called “triangulation”, in which the miscreant tries to gain dark power by telling different people different lies at different times to set them against each other more permanently. I’ve seen this and the resulting chaos before, so I’m naturally wary whenever someone speaks ill of one not present.

Now in fact I don’t know what went on between Sheila and John, and I don’t want to know. John hasn’t said anything about it to me, and as far as I’m concerned that’s the way it should stay. People should work their issues out directly with each other, and if that can’t work then there’s this thing called chain-of-command. I was not a part of that chain, so I should not be in that loop.

The Meaning of Life (at Work)

It happens to be that my manager (let’s call him Gabriel) was also Sheila’s manager, and those two worked in the same building with John. So it more than made sense to get him involved: He was the natural next step. I had come to the conclusion that I would make no further progress dealing with Sheila directly.

Gabriel has a hands-off style. This makes sense, for he has a great many other responsibilities including several other product teams. But every so often, even a hands-off manager needs to lay on hands. This, I think, was one of those times. Specifically, I tried to sell him on the merits of broadcasting some better definition to Sheila’s intended role. I hoped this would open the team’s mind to the need for a bit of adaptation.

Interlude

For some reason, the team was stuck in the storming phase. It was necessary to kick-start norming: The dev team needed to work out and agree to a new set of shared expectations that would function smoothly in the new context of having a proper product manager.

Before Sheila arrived, product-management got done haphazardly in bits and pieces: Whoever was in the hot-seat took a best-guess at what needed to be done and did it – generally unilaterally. So everyone was in the habit of doing all these things not-excellently rather than letting a dedicated person develop the expertise and social connections to do them excellently. That was going to have to stop.

Vacation Came to the Rescue.

It happened that I was also scheduled for a week’s vacation starting right after I finished up with Gabriel, so I had to hand off my work-in-progress to another developer or two. This was a perfect opportunity to slide in some helpful hints. I sent electronic mail to all and sundry (including Mr. Desk) explaining who would be taking over which aspects of my usual duties in my absence. In that mail, I made a point of pointing out that Sheila would be the hub for communication about the schedule, scope, and estimate for the project I was deeply embroiled in at the time.

Before I left, I also shared my diagnosis and prescription one-on-one with a few of the team’s most senior people: We needed to consciously think about how to change our habits and expectations so that we get the most benefit from having someone specifically in the role of product manager.

Finally, I cannot overstate the value of stepping out and away for the occasional week.

When I came back, I discovered a better-functioning team. It wasn’t perfect, but it was a lot less weird. Mr. Desk and his ilk still talk with developers for their technical knowledge, but Sheila is always part of the conversation bringing her specialist knowledge and global perspective. Developers now rely on Sheila to coordinate scope, estimate, and schedule. This yields more achievable commitments and fewer hard conversations with disappointed customer-types.

Loose Ends Made Fast

By and by, one of Mr. Desk’s colleagues tried to corner a developer and get an unreasonable commitment to an ill-defined feature. Thanks in part to the availability of a product manager, we got the customer-type to (a) explain in better detail what he wanted, and (b) wait for a proper estimate. The estimate came in at three developer-weeks plus an unpredictable amount of red tape, so that was the last we heard of the feature that he wanted someone to dash off in an afternoon. That might sound bad, but it’s a much easier conversation than if someone had agreed to build the feature in an afternoon and failed. Meanwhile, development efforts go towards things that are actually achievable on a reasonable budget. That’s a win.

The team continues to grow and change, but this particular episode has finally come to a positive conclusion.

Interlude

Evidently the norming phase picked up some steam while I was out. Once that critical activity percolated through everyone’s minds, the dev team could finally get to the stage of performing in a new situation.

Not everyone is in love with the newly-forged product manager, but that’s not important. You can’t please everyone all the time. She’s not perfect, but that’s not important either. You generally can’t get perfect. Sheilas’s who we’ve got, and we’ll make the most of having her.

Finally, the narrative is a bit short on monsters and magic. However, you did read until the end, which is pretty magical if I do say so myself.

Note to Self for Next Time

This particular team spent a disproportionate amount of time on storming. I think most of that could have been averted with the right early guidance. If there is no firm answer in the first few days, then my move is to gather influence to press the need for norming until it’s done.