“Learning to distinguish between when you’re brilliant and lucky is the key to rapid improvement”

Interesting, short, helpful: sometimes a good decision process produces a bad result. Sometimes a bad process produces a good result. Being aware of the quality of the process independent of the result allows for growth.

Super-practical set of suggestions for running meetings with engineers and engineering teams. Biased towards efficiency and zero time-wasting. If you’re a first time eng manager, or managing first-time eng managers, this should be a foundational text!

Great article. We will always work with people who are difficult for us. So, learning how to respond carefully and wisely to a “difficult person” is a skill we should learn! Difficult people can be our teachers if we let them.

“by seeking to understand the opponent, we take the initiative. At worst, we learn something. At best, we may turn them into an ally and improve the quality of the work environment”

A lovely piece from Marcus about the potential unintended consequences of powerful actions. Simple, direct and memorable.

A good, short reminder to take a better perspective when you find yourself thinking “I’m herding cats”. You’re organizing, managing, guiding a group of talented people - it’ll go better if you think of it that way!

A good checklist to run through to see how you might be able to manage with less specific direction and provide more autonomy for your team.

Some programmers (perhaps most) want to plan and architect first. Some want to jump right in. A nice piece using the analogy of writers to consider that both may be appropriate in different circumstances.

For an extended riff on the same analogy, see my piece: You’re Not Managing a Team of Software Engineers, You’re Managing a Team of Writers.

\Without consciously making strong decisions to take on deep, concentrated work, it will always get pushed aside by reactive work (email, slack, text, drive-by meetings).

This is a long and very complete post on how to go about prioritizing deep work. If you can’t find the ten minutes to read it, you need to find the ten minutes to read it!

The question of how to measure software productivity seems to be bubbling up as a significant area of concern (it’s come up spontaneously with several of my clients in different ways recently).

As it should! Because: a) we don’t know how to do it and b) the amount of money the economy in general spends on software development is gigantic and c) we all know intuitively that software development productivity varies very widely.

I will be posting fairly regularly on this topic as interesting perspectives show up. This is a useful start. (hat tip, the always awesome software lead weekly)

The classic model of team development - useful to have it summarized clearly and concisely. It’s particularly useful for startup exec teams, who tend to come together quickly, have varied experience levels, and are working in a high stakes environment. If you haven’t checked it before, give it a read.

Neat short post: we fear being shunned by our peer group at a very deep level. Which can make us anxious about sharing ideas. But groups work best when they include all the ideas, experiences and perspectives of their members. When leading a group, how do you make this work?

A simple article, but if you are avoiding conflict or tricky conversations (you know who you are) please read it! Conflict is inevitable. People have different ideas, experiences and perspectives. Resolving those differences is a critical skill for leading anything and anybody.

I know. It’s hard. If management was easy, everybody would do it.

Not sure I agree with the entirety of this post - it all feels a bit tentative - but it’s well worth reading as way of considering what your take would be (there’s not much written about this topic, which is, you know, weird).

“I’ve come to realize that there isn’t a job where you can fix all the things” Yes. Probably the most critical realization required to grow into a leadership position (and it gets more critical the bigger the job). So what do you do when you realize you can’t fix everything? Read on…

Great post from Ed. How to really resolve a conflict in the presence of a power/authority differential. Nuanced and complete. Take the time and read it.

“And yet a challenge is that we habitually fail to "empathize up”–we find it very difficult to empathize with someone we perceive as higher status, particularly when we find ourselves in conflict with them" “And yet the higher-status person may well feel resistance to expressing vulnerability”

A neat mapping of common unconscious biases to the review process: is your review biased because of great/not great work recently? your (now out of date) initial impressions? And eight others. Take a look.

Nice, short piece about the importance of being seen. When you stand up and become visible as a success, it opens whole futures for people who look like you.

The why’s, how-to’s, do’s and don'ts of skip-level 1-1s. Running a multi-level org? This should be on your reading list.

“When you get to a team size of 60, 70, or 80, people start to look more like pieces on a board rather than humans. You find yourself wanting to spend more time alone, away from people. And, while that might make your job feel easier, I think we have an obligation to never lose touch with the human cost of our decisions”

Profane people are more honest. Really? I’m not convinced. But - science!

Michael Lopp on the mysteries and necessities of meetings. Essential.

“[management is] a unique set of responsibilities granted on a particular human. Someone somewhere decided that you, yes you, are now a manager that means additional responsibilities including, but not limited to, going to meetings”