Skip to content

Author: Emmanuel Goossaert

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.

Part 4: Beyond The Code and What I’ve Learned – Ethereum Payment

In this series of articles, I’m doing a walkthrough of a hobby project I’ve worked on, a payment system for the Ethereum blockchain. You can read the intro article for more context about the project.

I have covered the majority of the technical details in parts one through three. In this fourth and final part, I will to cover the following:

  • How to extend the code to support more features or data providers
  • Important things to consider when dealing with blockchain data
  • Insights on what blockchain and web3 can enable in terms of product experience design

The content of this article will feel like a collection of somewhat disconnected ideas, and the goal is to do a brain dump of the biggest takeaways and learnings I had while I was developing a system for the Ethereum blockchain.

Part 3: Processing Payments – Ethereum Payment

In this series of articles, I’m doing a walkthrough of a hobby project I’ve worked on, a payment system for the Ethereum blockchain. You can read the intro article for more context about the project.

For this article, I will assume that you have read part 1 about authentication and wallet management, and part 2 about the data models used in the system. Therefore, I will start from the assumption that you’re aware of the basic foundation on how to let users connect their crypto wallets to as website, how to display a list of available digital products that they can buy from, and that you are also somewhat familiar with the data models presented in part 2.

In this part, I will cover how payments are processed and validated. This includes the following steps, in order:

  • Server-side prevalidation: validating, before even processing anything, that the wallet is authorized to buy a particular digital product, and that this product is available.
  • Purchase: sending a payment transaction to the Ethereum blockchain for the required price, and getting a transaction identifier in return (also called a “transaction hash”)
  • Polling the blockchain: using the transaction hash to check if the transaction has succeeded or failed.
  • Triggering post-payments actions: dealing with the aftermath of the transaction status, which means showing an error message in case the transaction failed, or starting further steps by allowing access to resources in case the transaction succeeded.

The Ethereum blockchain makes it very easy to process payments, because every transaction is given a unique transaction hash, which means that once you have submitted a transaction to the Ethereum network for validation, all you need is this transaction hash, and you’ll be able to track the status of the transaction by polling the Ethereum blockchain.

In reality, for a small application such as the hobby project I’m presenting here, there is no need to poll the Ethereum blockchain directly. Instead, my program uses a third-party provider that makes polling the blockchain easier via an API. Many medium to large applications nowadays are running their own Ethereum nodes so that they can poll the blockchain directly. It costs them extra teams and complexity to maintain that infrastructure, but it comes with the benefits of higher trust and control of their data, and also processing speed. For them, the tradeoff is worth it.

Processing Payments

Below is a systems diagram showing how I have implemented the payment processing part. It assumes that the user has connected his wallet and already obtained a JWT that identifies him uniquely.

The diagram contains a description of each step, and the rest of this section gives further details as to what happens in each step.

Systems diagram showing how a purchase gets processed, from the user clicking the payment button and the transaction that it triggers on the user’s wallet, to validating that transaction and creating a new JWT to give the user access. (click on the image to enlarge)

Part 2: Product Data Models – Ethereum Payment

In this series of articles, I’m doing a walkthrough of a hobby project I’ve worked on, a payment system for the Ethereum blockchain. Go read the intro article for more context about this project.

In this part, I will cover the following topics:

  • Product details, whitelistings, coupon codes
  • Displaying purchases and subscriptions, products available, and past purchases
  • Data models for products and whitelistings

None of what is described in this article is about web3, it’s all really web2 development. However, I do have to describe it to lay the foundation for parts 3 and 4 that will be focused on interacting with the blockchain, and with a recap of what I’ve learned about what crypto wallets and blockchain for developing mass-consumer product experiences.

Below are the data models used for products, purchases, and whitelistings and coupons (click to enlarge).

The data schemas used to represent products, purchases, and whitelists/coupons (click to zoom)

The follow diagram shows three user flows: the first flow shows products for non-signed in users, the second flow for signed in users, and a third flow just to display the current status of the access rights.

System diagram showing three user flows to display available products, past purchases, and current access rights.

Part 1: Authentication and Crypto Wallet Management – Ethereum Payment

In this series of articles, I’m doing a walkthrough of a hobby project I’ve worked on, a payment system for the Ethereum blockchain. Go read the intro article for more context about this project.

In this part, I will cover the following topics:

  • Connecting a crypto wallet via a frontend, and detecting states in MetaMask
  • Backend endpoints needed to manage wallet connections, wallet signature, and JSON Web Tokens.
  • Data models for users.

You will find that there isn’t much complexity in this article. Authenticating a crypto wallet is most about calling methods from the wallet API from the frontend, and then passing data around between the frontend and the backend for verification.

Connecting a Crypto Wallet

Whatever software you build that will have to interact with the Ethereum blockchain, either reading data or transacting, you’ll need to connect to an Ethereum node to access the Ethereum blockchain.

For most use cases, you won’t be running your own Ethereum node, and you won’t be calling directly any Ethereum node either. Instead you’ll use a third party that offers a centralized point of access to the blockchain: you connect to their backend servers, which are connected to the blockchain. It’s kind of counter-intuitive that we have to use centralized third party providers when you think about it given that one of the core tenets of the blockchain is that it’s fully decentralized, but that’s what we have to deal with these days.

As a human user of the blockchain, you need a crypto wallet to initiate various actions and execute smart contracts. Every Ethereum client implements the same JSON-RPC specifications, which is the standard that applications can rely on to interact with the blockchain.

Building a Payment System for the Ethereum Blockchain

Over the past few years, I’ve oriented the content of this blog towards engineering management and tech leadership, and consequently, I haven’t written anything purely technical for a while. Some of my most technical article series ended up finding a large audience, namely Implementing a Key-Value Store, and Coding for SSDs, and it now feels like it’s been an eternity since I wrote them.

Crypto protocols have made a serious dent in the tech space, and even more so over the past couple of years, often referred to as a whole as crypto or web3 technologies. With my personal commitment to keep upskilling myself, I have decided to make it a top priority for me to understand how blockchain technology was built and operated, and what kinds of businesses and product experiences this technology could enable in the long term.

I decided to build something basic yet complex enough that it would force me to interact with blockchain data in interesting ways. Because token transactions and crypto payments are simplest interactions on the blockchain, I settled on building a payment system.

Therefore in this series of articles, I will be sharing how I implemented a fully-functional payment system on top of the Ethereum blockchain, with the following features:

  1. Managing a list of products and time-bound subscriptions. Allowing for coupons and whitelistings.
  2. Displaying the current and past purchased products for a user.
  3. Guiding users through payment transactions on the Ethereum blockchain, by connecting their Ethereum wallets.
  4. Handling complex situations of network and service disruptions, to prevent double payments, avoid hanged transactions, and cover all other edge cases. This is mostly done by making all operations idempotent and idempotency keys.
  5. Monitoring the Ethereum blockchain to verify that payments for a particular product has been received.
  6. Once payment has been received, allowing paid users to access the private parts of a website by signing on with their Ethereum wallet to authenticate.

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.

Six Patterns to Optimize Your Monolithic Codebase

Migrating to microservices isn’t always needed: first, you must fix your monolith.

The tech industry, and software engineers, are wired for the new and the flashy. That’s also why we see dozens of new javascript frameworks getting created every year, the majority of which end up burning into oblivion as they re-enter the Earth’s atmosphere—well, except for jQuery, which somehow keeps surviving.

The same can be said of architecture: almost every time I hear or read someone mention monolithic architecture, there’s almost always a negative connotation associated with it, because it has this feeling of old and outdated.

But simply because monolithic architectures are older doesn’t mean they’re bad, or that they’re less, compared to service-oriented architecture or to serverless.

This reputation comes from the fact that most monolithic architectures end up turning into giant spaghetti monsters of code, difficult to build, deploy, and evolve. I agree with that, that has also been my experience.

What I disagree with is the speed with which many engineers are ready to discard monolithic architectures entirely and switch to something else, say microservices, which they understand even less, instead of trying to fix what’s already there. There’s a lot of hype involved with such pushes, because it entails using new cool frameworks, new programming languages, and so on.

In addition to that, there’s often a lack of understanding from engineers that the decision of choosing an architecture must never depend only on technical considerations. In fact, it should be the other way around: picking an architecture should always be done by putting most weight on what will best serve the business needs and growth of the company over time, and take technical considerations only as a second-order concern.

And before discarding an entire architecture or codebase, one should always strive to fix it with what’s already there.

In this article, I want to share techniques I’ve seen deployed in production and which have helped make monolithic codebases easier to work with. I’ve seen first-hand that they were successful in improving build times and consequently deployment times.

The six patterns for optimizing your monolithic architecture are:

  1. Remove build bottlenecks
  2. Extract frequently updated code areas into their own modules
  3. Clean up unneeded dependencies
  4. Clean up unused code
  5. Enable server-side caching in your CI/CD
  6. Use subviews to mock dependencies

In the rest of this article, I will share more details about those techniques, and how to go about using them

I’ll be using the term “microservices,” as if I’m taking the perspective of a backend system. But this article also applies to frontend applications and to microfrontend architectures. Also, I’m going to stay very generic in my statements, and that’s intentional: I want to focus on the big picture ideas without being specific to a particular language or toolchain.