Patterns for managing up

Dear new developer,

Design patterns are common ways to implement solutions that can be repurposed across different systems and domains. This post proposes patterns for handling organizational situations.

Some really good excerpts:

No matter how amazing you are at your job, you will sometimes get feedback about things you could be doing better. It can be difficult to hear, especially if you are someone who works really hard all the time. When it comes to negative feedback, it is important to reframe the conversation. Feedback isn’t a bad thing. It is a gift, and you should always adopt a growth mindset and see it as a chance to improve.

I have received negative feedback about how I managed (I was managing how I would want to be managed, not how the employee wanted to be managed). It was really good to hear because it let me improve, but I definitely had to hold down a “wait a minute, you don’t understand” thought. If I hadn’t, I would have both lost that opportunity to learn, and possibly many more. If you react negatively to feedback often enough, people will decide that it isn’t worth giving to you.

And this is a good one too, about how to handle a problem you created:

When problems occur, there is a natural instinct to hide or deny that the problem is a problem, or that it is even happening at all. We want to minimize the problems that are our responsibility because, after all, a big part of our job is to make sure problems don’t happen. When you are proactive about sharing and fixing a problem, however, it is actually an opportunity to show you are an asset to the bosses.

Going to a boss and saying “I screwed up” is terrifying, especially the first time you do it. But going to the boss and saying “I screwed up and this is how I am going to both fix it now and make sure it doesn’t happen in the future” is terrifying but empowering too. The other alternative is to just hope that you are never found out, which is a miserable way to work (who wants to hide things? what happens if the problem gets bigger?). If you screw up, take a deep breath, come up with a plan, and solve the issue.

The whole article is worth a read.

Sincerely,

Dan

Strong convictions, loosely held

Dear new developer,

When building a system, you’re going to be confronted with lots of decisions. Unless you are operating in a total vacuum, you’ll have to reach agreement with other people. This will lead to discussions and arguments, as all the people involved will bring their viewpoints and experience.

You should definitely participate, and bring your own experience and viewpoints.

However, everyone should pay attention to two things:

  • the usefulness of listening to everyone’s experience
  • the overarching goal to be achieved

The first is important because different experiences build a stronger solution, the same way a forest is more resilient than a field of wheat. But it’s also important because even if someone’s experience has no bearing to the problem at hand, if it is dismissed the person will have a harder time both contributing to the current problem’s solution (they won’t be bought in) and to issues in the future (when their experience might be more relevant).

The second is the right way to guide the conversation and to steer it towards success. No project or problem ever exists in isolation. It’s worthwhile to examine all the big decisions, and many of the smaller ones, in the context of the overarching goal. (Heck, there are some times when it is worthwhile to make sure you are working toward the correct overarching goal.)

When you listen to everyone and focus on the higher goal, good things happen. One especially good thing is that you may change your mind. The right way to do that is to argue as passionately as you can for your point of view (have a strong conviction), but not lose sight of the fact that you may be incorrect (loosely held). And if you are, then everyone benefits when you acknowledge the better solution and move forward with it.

Sincerely,

Dan