Home Home Posts Rants about IT DevOps Stuff I'm working on

Working with the people you manage

Arseni Mourzenko
Founder and lead developer, specializing in developer productivity and code quality
115
articles
April 18, 2017

An embarrassing performance review

A few years ago, I worked in a company in Poitiers. Things went well until our boss left, and a new one arrived. The new one appeared to be, well, a bit proud of his new status, and, naturally, decided that he has plenty of important things to do and no time to communicate with the developers.

One day when he just got his new position, we had to do the same one and a half hours trip to Paris. We bought our tickets separately, and when I learned that his train is one hour later than mine, I asked him if he wants me to change my ticket so we travel together—this was an excellent opportunity for me, as I explained to him, to present myself and explain what I'm doing in the company and what are my goals. He was much less enthusiastic, and decided to travel alone.

Six months later, we found ourselves in a small meeting room. This was my performance review that the big boss was doing himself in person. As the guy had still no idea who I am and wasn't even aware of that, the meeting was somewhere between boring and hilarious. I found a few opportunities to clearly make fun of his ignorance, but he either didn't understand or haven't reacted.

The end of the meeting was, however, largely embarrassing. Performance reviews in this company made it mandatory to specify at least one target for every employee for the next year. When it came to suggesting me my target, my boss was suddenly lost. Since he knew nothing about my profile, he was afraid to suggest something completely irrelevant.

In a situation like that, a wise manager would let the employee make a choice of a target. However, letting me do the choice would shift the power from him. So my boss decided to take the risk:

“You could create a baseline for testing projects,” said my boss. He looked so happy to have found something that I was really annoyed to break it. After all, it could still be interesting. So I barely asked for clarification. He wasn't expecting that, and attempted to add details, but ended up losing the track.

“Well, you're expert when it comes to tests, so you'll find how to do it,” he claimed after a long and painful pause.

“Actually, I'm not an expert in testing by any means; I mean, I know how to test an app, just as any professional developer would know that, but that's pretty it.”

“But you do a lot of tests, don't you? And you know all that stuff about integration and system testing, you could easily do the baseline project thing...”

“Since I work here as a project manager and an architect, testing is rather outside of the scope of my job. Besides, I still don't understand what I'm supposed to do. Maybe I should give you some time to think about it, and in a few days, when you do get a clearer picture, you can write me an e-mail.”

One month later, I wrote my resignation letter. I never received the e-mail I was waiting for so much.

Iterations of delays

In another company, the hierarchical gap was much larger. In fact, one would feel the hierarchy by just entering the building: there were system administrators and administrative staff at the first floor; developers had the second floor, with a separate office occupied by the CTO; finally, the third was reserved to the CEO, the general director and the corporate lawyer.

One day, the third floor decided that the one beneath it should start a new and very important project. So a team was formed, and I was part of this team. Since both the company culture and the proper skills were crucially lacking, it was obvious from the start that the project will not be released any close to the initially projected release date. It was clear to every member of the team, including our manager. The CTO came once per week to assist to our daily half-an-hour meeting, and so he seemed to be aware of the numerous difficulties the project was experiencing. Things were, on the other hand, radically different for the CEO and the general director who, one day, decided to publicly announce the release date with accordance to one of the plans which was outdated months ago. Then, the project wasn't delivered, and the general director had a few embarrassing moments with some of the customers.

The fact that the general director decided to communicate a date without bothering to consider the opinion of anyone who was working on the project wasn't the scary part. What astounded me much more was the fact that everybody on the team knew that the project will be delayed. I mean, if CEO entered the room and asked: “Hi, do you think you'll be able to deliver in three weeks?” he would receive two reactions: silence—from the guys who learned that in order to keep their jobs, they should keep a low profile, and exclamations like “Are you freakin' out of your mind?!” from the guys like me who were leaving the company anyway. Or the CEO or the general director could have asked a few questions about the project informally to any developer and receive enough information about how wrong things are going there. Or simply assist to a few meetings and see by themselves.

Instead, they decided to stay in the ivory tower, where projects are always following the original plans. And they decided to broadcast the release date, with no concrete data about the project, aside the formal reports from the CTO, which were obviously totally useless, since they were unable to reflect the actual state of the project. They did many other decisions the same way as well, but this would go to a different article.

Those who do the right thing

Later, I found myself working for a French petroleum company. There are many, many good things I remember from this job, and one of them was the way those people managed hierarchy.

About twelve developers and business analysts, a group of external experts in specific fields helping the group, one product owner, one manager, one boss, and one big boss were working all together. And when I say together, I mean all those people were actually in the same open space.

At the very beginning of the project, two bosses had their offices, and so did the product owner. They were still reachable, and they were always here during the daily meeting, no exceptions. Later, they decided to abandon their offices and relocated to the open space, so the boss had exactly the same table space as a developer or a business analyst. And that was absolutely great: they were not just showing that they are part of the team, they actually were part of the team. They were aware of everything happening to the project on daily basis; they were talking with us, and going to lunch with us. And so, when they needed to take decisions, they knew exactly what they were doing.

Communicating with teams

I'm a strong believer that every developer should at any moment have a choice between working remotely, or in a separate office, or in an open space. My sloppy, rough estimate is that only twenty percent of the time will be spent in an open space, while the remaining eighty percent of the time will consist of working without ensuring a permanent visual contact with the coworkers.

This doesn't mean, however, that developers who work remotely or in their own office shouldn't communicate. In fact, frequent communication is key both for the well-being of the project, but also for the well-being of the team itself. This applies to developers themselves who will need to share information about their work and the issues they encounter, but is not any less crucial for all the people who gravitate around the team of developers—external consultants such as security experts, customers' representative (product owner, or whatever is the next buzzword in Agile), system administrators and database administrators, and, last but not least, the boss.

When you're calling yourself chief something officer, or even a manager, it is tempting to get yourself a private office, and put a distance between you, the big boss, and all those people who work for you. But then, you're losing much more than you win. With no regular communication, you can't take smart decisions. By not knowing your people and not knowing your projects, you are not making yourself a service.

I've observed many companies with strict hierarchy, and noticed that those where people from different corporate castes weren't talking to the outsiders found themselves taking really spooky decisions. So, please, go talk to people you manage; you'll learn much more than by remaining in your private office.