Like this article? Read more Wednesday Wisdom! No time to read? No worries! This article is also available as a podcast. You can also ask your questions to our specially trained GPT!)
This is the sixth in a series of articles I am calling "Machiavelli for software engineers". In these I cover topics that are related to power and influence in organizations. The full introduction to the series can be found here.
One of my friends told me that he had had a chat with his manager recently about his performance. The manager praised him for his deep insight in the problem space, his valuable contributions to solving hard problems, and his assistance to more junior team members in the form of discussions, design document reviews, and code reviews. Then the manager continued: “But I really need you to write more lines of code yourself and close more tickets, because otherwise I will have a hard time making the case for your performance in the calibration meeting” (or words to that effect).
Here’s another story: Once I was asked to build a core computing platform as the basis for some mission critical infrastructure. When I was asked how I was going to do that, I said: “Well, I am going to think about this really deeply and research our options, then I will write a design document which we will review, and then I am going to execute on that document.” The feedback I got was that this was unacceptable because that would mean that there would be several weeks, maybe a month or two, without any visible progress.
In these two stories, my friend and I received incredibly useful feedback about the rules of the game we were playing. The question is: What to do next?
One possible reaction is to become recalcitrant by reacting with an obstinate and uncooperative attitude toward the managers in question. In both of these stories, there is an argument to be made that the requested changes in behavior potentially do not lead to the most optimal use of everyone’s time and energy and are therefore not in the best long-term interest of the company.
“Lines of Code” and “Tickets Closed” are of course both well-known and terrible metrics for software engineer productivity. However, they are also incredibly stubborn metrics that have thus far defied any attempts to eradicate them, probably because there are so few “objective” quantitative metrics that could replace them. Therefore, I must honestly say that I am not completely without sympathy for managers who use these metrics as well as possible to get some handle on engineering productivity.
In the other story, building a complicated piece of infrastructure without a proper design can obviously lead to incredibly costly mistakes, but, and this is crucial, that does not have to be so. Generally speaking, making a proper design is the accepted way of going about these things, but on the other hand, there is something to say for wanting to keep tabs on progress and having an engineer disappear from sight for two months and then hoping that they are doing a good job might be somewhat nerve wracking for a manager who is trying to keep everyone to a high velocity schedule.
But, and this is important to realize, regardless of whether the rules are good ones or not, these are the rules, and the only question is how you will let that insight guide your actions.
I daresay that being (or becoming) recalcitrant has never worked well for me. It is a natural reaction from a seasoned professional to feedback that is open for debate, but in reality: What are you going to do? It’s not that you are going to change what is going on in the calibration meeting. And even if you potentially could change what is going on there, is that really the best use of time and energy when measured towards reaching your personal goals?
On many occasions, I have suggested to people that they see their professional career as a game. By this I do not mean that they should view it as an enjoyable pastime without any serious consequences, though it would surely be great if one could. Instead, I use the word “game” in the mathematical sense: As a formal structure with a set of players, a set of possible moves, and a set of rules that map these moves to outcomes. I would suggest that your goal is to optimize your personal outcomes.
Note: Optimize, not maximize.
In the two stories above, I labeled the managers’ responses as incredibly useful feedback because they, in essence, explained some of the rules of the game at hand. Want to optimize the outcome? Play by these rules! It does not really matter what I think of it all, the only thing that matters is that I know what to do in order to optimize my outcome. If I know that my performance is partly assessed by how many tickets I close, I will need to make sure that all the work I do is adequately represented in tickets that I can then execute on and close. If my performance is partly assessed by how many lines of code I write, I need to make sure that I structure my work so that I can keep a good amount of coding work for myself. There is nothing to gain for me (or you) by being recalcitrant and not doing that.
Every company, and especially the bigger ones, has tons of operating rules, both formal and informal. I have for instance written about promotion processes a lot and these are excellent examples of a system with rules and a preferred outcome, hence: A game. Many promotion processes are explicitly structured around meeting the requirements of the next level of the job ladder and the easiest way to get promoted is to make sure that you do that. Some of these requirements are inevitably of the nature “mentored at least two interns”, or “has done at least 50 interviews”. You might be of the opinion that you are on a project that is so important and all encompassing that you don’t have the time of day for interns or interviews, but how is that going to help your promotion case? If you meet these (maybe silly) requirements, you bypass a whole debate on whether you qualify for the promotion or not. The stewards of the promotion process were kind enough to lay out at least some of the rules, and my advice is to make sure you follow them!
In the past I have tried to explain to people why some of the rules of the game were dumb and what much better rules would look like. Over time, I pretty much stopped doing that though because, for all my being right about everything most of the time, I have seen very little payoff from these efforts. It’s not that the people that I was talking to didn’t agree with me, they often did. It’s just that it is very hard to change the rules of the game in a large organization.
Whenever we talk about games and rules, we also have to talk about cheating
Let it be clear: I am not calling upon you to cheat and I want you to remember that your company is not a democracy, so creative interpretations of the rules will most likely not work to your advantage. In society as a whole, there is a tendency to give the benefit of the doubt to people who are making optimal use of the grey areas between what is clearly allowed and what is clearly not allowed. Autocracies don’t work that way and for all practical purposes, companies function more like autocracies than like democracies.
Outright cheating, for instance by putting ChatGPT to work and making it generate thousands of unit tests, which would be lines of code, is of course a terrible idea and I hope I don’t have to explain why. Creatively interpreting the rules of the game will also not work well for you. In a company, as soon as you have to defend that you “technically” followed the rules, you have already lost.
As I wrote recently: Technically, no sentence that contains the word “technically” is ever helpful.
Whenever I get feedback, I always check if someone didn’t just explain some of the rules of the game to me. If they did, I take them to heart and change my ways to play by these rules because, bar some aces in the hole, following the rules of the game is your best chance of winning it.
