Skip to content

Category: Leadership and Management

How Many Reports For Engineering Managers & Other Bedtime Stories

The number of direct reports for an engineering manager is a recurring debate among tech managers. I’ve heard many different versions of it, and I’ve witnessed many implementations, which led me to have strong battle-tested opinions on the topic.

So, how many reports should an engineering manager have?

I’m a fervent fan of High Output Management by Andy Grove, and in that book, he shares that “A manager whose work is largely supervisory should have six to eight subordinates; three or four are too few and ten are too many […] this ensures half a day per week for each subordinate.”

And the keyword here is “supervisory” which means the manager has a medium amount of individual responsibility, however, that level of responsibility will depend on how your organization and yourself want to define the role of engineering manager.

A lot has also been written about managerial archetype, but it all feels either subjective or generic to me, and the rationale is often not clear. Things are actually more complex than just following a rule of thumb, and I hope to shed some light as to how I think of it with this article.

Performative Leadership: From Cargo Cults to OKRs

After working in leadership roles for a decade, I’m still baffled at how cultish large organizations can be.

No matter where I look and what former colleagues tell me of the places they now work at, I hear the same stories of tools and structures: dysfunctional performance appraisals, OKRs of dubious quality, broken managerial hierarchies, and always some flavor of agile methodologies when in fact nothing is agile.

Every single of those tools and practices can usually be tracked to a single company that developed it to solve a problem they had locally, and then some consulting firms heard of it and productized it into training material that they could charge money for.

And so we end up with processes, each from its own distinct cultural context in which it was working and effective, being passed to consultants who don’t fully understand that culture. And then those consultants go on to train employees at other companies who find themselves two degrees removed from the source, and who naturally are struggling to make sense of it. And I’m being generous here, because often you have a chain of consultants who have taught one another to the point that everything has been watered down to oblivion, and all that’s left is language.

Without going into too much detail, I will start by covering three examples of decontextualized practices and how they fail to fulfill their original purposes.

Solution-Oriented Coaching, or the Lost Art of Effective Conversations

After spending more than a decade in different managerial roles and learning various aspects of the job, I came to the conclusion that as a manager, conversations are the ultimate tools of the trade. They enable you to direct, motivate, and engage people, and to pull information from the environment.

I realized at some point that many managers, myself included, were too reliant on gut feelings during decision making, or were biased in searching for problems to solve in teams or in people—and therefore self-prophesying problems—which was not always constructive. I was able to track down this behavior to a simple lack of rigor and effectiveness when conducting conversations.

It’s amazing how many companies do not train their managers, or when they do, train them poorly on how to conduct a conversation effectively so that it will lead to results. So I started looking for better solutions to making my direct reports accountable for their work, giving direction and motivation, and supporting them along the way, specifically via conversations.

On that journey, I stumbled upon a therapy framework called Solution-Focused Brief Therapy, or SFBT for short, and it has changed the way I interact with people at work so much that I decided to write this article so I could share my experience.

This article is the culmination of my personal journey with SFBT over the past three years. It covers the basics of SFBT, how I’ve used it in the workplace, and the some limitations I’ve encountered. The article concludes with a long list of resources, many of which are free, to help you dive further into SFBT.

For the rest of this article, I will refer to SFBT applied to coaching and management as Solution-Focused Coaching, to make it clear that I do not want to go into the realm of therapy, given that I am neither trained or medically licensed for it, and that providing therapy is not my role as a peer or manager in a workplace environment.

Finally before jumping into the topic, I want to clarify that almost the entirety of the ideas presented in this article are not mine. They come from various therapists and clinicians who practiced and honed those techniques and shared about their findings in books and articles. I do not claim to take credit for any of those ideas, my main contribution here is that I am trying to bridge the usage of those techniques from a therapeutic setup into a workplace setup, and I am also sharing my personal experiences and findings in doing so.

The field of SFBT is gigantic, and in this article I will only be able to cover the surface. My goal is not that by the end you would be fully trained, but rather, that you would see the benefits for yourself to use those techniques, and that it would motivate you to spend more time on learning SFBT. So in short, this article is my attempt at selling you to the benefits of SFBT.

Learn Street Epistemology To Deal With Difficult People at Work

Dealing with a stubborn coworker is something most of us dread. “Oh man, I have to talk to that guy again, ugh…” you tell yourself, especially in cases where you don’t have much leverage on the situation or the person.

And sometimes, the person you deal with seems somewhat reasonable, but the two of you see things so differently that you can’t seem to reach any agreement or even start to understand why your respective conclusions are so far apart.

Imagine you’re at work and you’re facing some of the following conversations:

  • An engineer tells you he strongly believes that project X doesn’t make any sense, because technology W is not good enough for it.
  • A product manager tells you he is absolutely convinced that using a certain approach to roll out a new feature is doomed to failure.
  • An engineering manager who reports to you is saying that without any doubts, person P on her team is really not good enough and is underperforming.

Ever been in a situation like that? I bet you have.

And what do these situations have in common? They’re all opinions and beliefs that people are dumping on you without context or facts.

When faced by such a situation, it’s tempting to shove it into someone’s face that they’re wrong, and press it to the point that it’s painful for them. There’s a certain satisfaction that we all get from “being right.” I know it, because I’ve done this myself in the past, and I’m not proud of it.

That’s also what most people do: they just reply with whatever opinions they have in their own minds at that moment. And the hope is that after some time of throwing opinions at each other’s face, the argument is going to sort itself out and help the two parties come to an agreement, or at least, to an understanding.

But reality is often very different from that, and without a more structured and pragmatic approach to such conversations, you’ll end up making decisions based on social status, feelings, beliefs, and personal preferences, which is the total opposite of what you want to do if you wish to make rational decisions.

My intent with this article is to introduce you to a conversation technique called street epistemology.

Many introductions to street epistemology have been written, and my key contribution here is to localize the technique so you can learn to use it specifically in a work environment. In particular, it will do wonders with colleagues with whom you have little leverage, generally because they are above you in the org chart—like your manager or your manager’s manager—or because they sit in a sister organization in which you have little political weight.

In this article, I will first briefly cover some examples of epistemologies to give you more context, then I’ll give you a step-by-step guide on how to use street epistemology in a workplace environment. Finally, I have added plenty of links and materials at the end of this article if you want to dive further into the topic.

How to Get Your Silent 1-on-1s Back on Track

During 1-on-1 meetings, I’ve often had a direct report who says “I have nothing to share” or “nothing from my side this week.”

When I was still an inexperienced manager, I would reply “okay great, let’s end the meeting and go back to work then!” However, after more years of running 1-on-1’s with dozens of different personalities, I’ve learned that ending the meeting is always the wrong thing to do.

Over time, I’ve developed a list of questions that I keep readily available in a corner of my mind in case those situations arise, as a way to unblock them and generate more insightful discussions. In this article, I’m sharing my approach.

The Most Important Step Of Every Great Conversation

If you’re like me, chances are you walked into many high-stakes conversations without even realizing what was at stake, and without having either a goal or a game plan on how to achieve that goal.

And then, you walked out without understanding what the heck just happened and why everything turned out so wrong.

Having good conversations is a skill. You need to keep track of all of your interlocutors’ signals including values, beliefs, arguments, body language, logical fallacies, and so on, while keeping track of your own presence and communication.

So if on top of that you realize mid-flight that you didn’t plan exactly what preferred outcome you wanted from the interaction, then it’s game over.

Entering a conversation with a goal can be the deal-breaker that will make the conversation a success for both parties, or a drag and the beginning of a conflict.

Most shortcomings can be avoided by preparing and practicing the art of conversation, and by taking care of the most important step of all.

Making Teams Effective At Remote Work

On my quest to make my teams effective at remote work, I went through a boatload of content. Articles, podcasts, courses, videos, everything that was relevant, I consumed and annotated.

I reviewed 40+ resources about effective remote teams so you don’t have to. Here’s my takeaway.

Unsurprisingly, all the content offered by GitLab is brilliant. They really know what they’re doing, and the quality of what they put out there has been top-notch so far. I also didn’t want to use only them as an example, so I went out of my way to find other companies, and other examples of success to form an opinion that would be as objective and as realistic as possible.

After reviewing 40+ resources, spending hours absorbing and summarizing them, and boring my friends and colleagues about it, I thought I’d put everything into a nice little package to share what I’ve learned with others. This is what his article is.

The article is geared towards managers on how to adapt teams and organizations to become effective at remote work, and not so much on how to be a more productive individual within a remote setup.

If you’re an individual contributor, you will find interesting ideas in this article nonetheless, and also ideas on how to convince your manager to help your team and organization be effective at remote work, so read on!

To create the right environment for organizations and teams to be effective and successful, the topics you must cover are the following:

  1. Be explicit about which ‘remote’ you pick
  2. Set a culture of remote work from the top
  3. Embrace an async-first mentality
  4. Adopt management by objectives
  5. Don’t let individuals choose their WFH days
  6. Recognize the need for meaning and bonding
  7. Organize for physical and mental health recovery
  8. Adapt all the supporting organizational processes

The rest of this article dives into the details for each of those topics, and at the very end, I am sharing all the useful resources which I’ve come across.

Finally, note that this article explores all the main ideas and concepts for effective remote teams and organizations. However, it doesn’t cover how you would plan a transition and then execute this transition. I will cover this aspect in a future article. Join my email list to be notified when it comes out.

The Skills Map of Senior Tech Career Progression

Peter Drucker—the founder of modern management—said in his 1999 article “Managing Oneself” that knowledge workers should plan their second career well ahead of time.

That’s admirable advice.

Except that for the rest of us, planning our first career is already a major life struggle. 

And I can talk at length from my own experience. A little more than ten years ago, back when I was still a naive junior engineer, career progression was a very nebulous concept.

Now that I’m at a point where I’m managing other tech managers, I’ve gained enough perspective on the topic that I can share valuable insights that my younger self would have loved to hear and learn.

In a previous article, I covered why soft skills matter and how they can make your career stagnate if you don’t address them. I also shared what the next job roles are from the senior developer role.

I wanted to create a simple representation to enable anyone with a career in tech to grasp how career progression looks like and what it requires.

In the rest of this article, I’m presenting a skills map of career progression, starting all the way from the senior developer role. This map covers both the individual contributor and managerial career paths.

Unlock Your Soft Skills To Win The Career Game

Have you ever received feedback from your manager that you should improve your communication skills? Or that you should create more visibility for your work? And another one, that you should work on your influencing skills? These are all related to soft skills, and it can be confusing what they mean and how to improve on them.

As a tech manager, I find myself giving that feedback regularly to engineers. About 50% of them get it, however, the other 50% roll their eyes and reply “Soft skills? Pffft, I’m an engineer, I don’t need that. All I gotta do is code harder and learn technologies A and B and I’ll keep on going.”

And that’s where they’re wrong, as sadly, I’ve seen such neglecting of soft skills ending up costing many of them years of stagnation for their tech career. The same could happen to you, or might already be happening to you without you realizing.

I wanted to follow up on my article about career progression for senior developers, by addressing the topic of how to map and learn the skills needed for tech jobs.

Soft skills and teamwork
skills are what’s gluing
hard skills together.

So in this series of three articles, I’ll first be covering what is the difference between hard skills and soft skills, and why soft skills matter even if a great part of your job is purely technical.

Another difficult problem is how to prioritize those skills so you can improve predictably. To address that, in the second article I’ll share a map that I’ve created and which shows how different types of skills relate to different career paths.

Finally, in the third and last article, I’ll cover the top skills you should focus on as a senior engineer or as an engineering manager if you want to see fast progress in your personal growth.

Let’s get started with defining the types of skills and why they matter.