Dear blogging diary, I try to publish one post per week, but do you know this feeling when you just don’t have any good ideas? You browse through your list of potential topics, and all the time, you think “Naaah, this one is not really interesting. No, already kind of written about that one in a previous post. Naaah, there is this great post on that one by someone else, and he has said it all, and I agree with him.” You reach the end of the topics list, and your mind is still blank.

Recently, I was amazed at what I could contribute to a technical meeting without any technical expertise on the subject matter discussed. In this particular meeting, there were two sides participating: On the one side, there was a team - let us call them Blue Team - who was starting to use a certain technology to solve a certain problem. On the other side, there was an engineer from a different team, let’s call him Gunnar, who wanted to talk them out of it. There was I, the manager of the Blue Team. I was in a neutral position. Why neutral? I will come to that in a second.

Like many relatively new managers, I have trouble handing things over. Instead, I do too many things myself, or - worse yet - they are delayed. However, if a manager wants to increase his leverage, then delegation - which means not doing everything yourself - is an indispensable tool which I want to highlight a bit more. Like I said, I am not a delegation expert by experience, so I write this post as much for myself as for readers out there who might find it useful.

When you become a mum or dad, you are definitely in for some funny and surprising moments where your children react in a totally unanticipated way. Example: I sit at my computer and fill out my tax return. My three year old son comes in and asks: “Daddy, may I help you at the a-pluter (computer)?” - “No, sorry, Max, you cannot help me here.” The result: Max throws himself on the nearby couch in desperation, shouting out: “But why not? I am your friend after all.” It was so cute (and heart-breaking) that even as I type these words, it makes me smile.

I set up a couple of workshops recently, some with external trainers, and some internally. I have to admit, it is not the most fun part of my job. You make appointments, you write emails, you book rooms. Not very exciting. However, it is also really important, because it benefits a lot of people, and investing in your skill set is crucial for every software developer.

“I left a comment in the ticket, what else am I supposed to do?” Jacob does not see his part in the delay of a new feature. After all, it was Rebecca, the designer, who did not react, and blocked him for two days. He wrote a comment, saying that he needed her to provide a different version of the image. But she did not get back to him.

Giving critical feedback is an unpleasant situation for many new team leads. Let’s consider Robert. Not too long ago, Robert was “one of us”, a developer in the trenches who was producing high-quality code, and still found the time to help other developers solve hard problems. Now, he is supposed to do this thing called “managing”, but he does not see himself as a manager or as a boss. He sees himself more like what some people adequately call “programmer plus plus”: Still “one of the guys”, just with some extra 20%-or-so responsibility on top.

Effective one-on-one conversations should produce some insight. Either your employee should learn something he did not know before, or you, as his manager, should learn something you did not know before. Ideally, of course, both would learn something. This learning can be almost anything. Maybe the employee needs to find a new flat until the end of the month and is a bit stressed because of that. Maybe she plays with the thought of moving into a different technological field. Maybe you learn about your employee’s job satisfaction or future plans. Maybe your employee learns something new about the organization. The learning can be about things that happened at work, or, occasionally, about something entirely different.

Robert is a newly promoted engineering manager. Not too long ago, he was “one of us”, a developer in the trenches who was producing high-quality code, and still found the time to help other developers solve hard problems. Now, he is supposed to do this thing called “managing”, but thinking about himself as a manager or boss makes him feel rather uncomfortable. He sees himself more like what some people adequately call “programmer plus plus”: Still “one of the guys”, just with some extra 20%-or-so responsibility on top.

Becoming an engineering manager is a paradigm shift that many struggle with at first. I think that one of the psychological difficulties for new engineering managers, and certainly one that I was having, is that of perceived productivity. To a developer, managing people can feel mind-numbingly unproductive because you seemingly “cannot get anything done”.