Dunning-Kruger effect, good onboarding, and the Conway's law of microservices 💡

Monday 3-2-1 — Edition #46

Hey, Luca here! welcome to the Monday 3-2-1 ✨

Every Monday I will send you an email like this with 3 short ideas about engineering management, technical strategy, and good hiring.

You will also receive a new long-form article every Thursday, like the last one:

• How to Plan for Maintenance 🛠️

To receive all the full articles and support Refactoring, consider subscribing if you haven’t already!

p.s. you can learn more about the benefits of the paid plan here.

---

---

🐺 QA Wolf

Before we dive into this week’s ideas, I want to spend a few words to promote QA Wolf, whose team I got in touch with just recently.

In-house QA takes years to scale. QA Wolf takes weeks.

QA Wolf will build, run, and maintain your automated end-to-end test suite — and get you to 80% automated end-to-end test coverage in 4 months.

Your automated test suite runs entirely in parallel on QA Wolf's infrastructure so you get results in 5 minutes or less for fast, confident shipping.

From their website you can schedule a demo, get a 90-day pilot, and browse plenty of case studies from real-world companies 👇

Now back to this week’s ideas!

---

1) 🥷 The Dunning-Kruger Effect

The Dunning-Kruger effect is a well-known phenomenon in which experts in some domain are somewhat less confident that amateurs.

It isn’t always so, but it seems that, by drawing your skill progression on a time scale, there is a valley in which, although you have acquired decent expertise already, you can be more insecure than when you started.

Put it in another words, there is a significant period of time in which the more expert you become, the less confident you are.

The three main stages of the Dunning-Kruger effect

How can this happen?

If your knowledge increases but your confidence decreases, it means that your expectations about what you should know are increasing faster than your knowledge itself.

This is possible, and even likely, because of how our learning works.

In fact, for any given subject, we can bucket knowable things into three categories:

1. 🟢 Known knowns — our actual knowledge.

2. 🟡 Known unknowns — things we don’t know and we are aware of it.

3. 🔴 Unknown unknowns — things we don’t know that we don’t know.

We can only expect from ourselves things whose existence we are aware of, that is, (1) and (2). But when we are learning some domain, for a good while we may discover new unknowns faster than how we are able to turn them into knowns.

As long as this happens, our confidence goes backwards, while we see what we need to learn growing faster than our knowledge.

I wrote a full article about growing your confidence and dealing with impostor syndrome 👇

How to Deal with Impostor Syndrome 🥷

---

2) 🎒 The Three Levels of Onboarding

Onboarding is one of those overlooked processes that sometimes are expected to just happen.

I suspect this is because of a couple of reasons:

• 🧱 It feels like a commodity. Once you get past a baseline of quality — that is, here are some docs, here is your team, here is what you have to do — it doesn't seem there is much room for improvement.

• 📈 Performance is hard to measure — making it tough to assess how the process is actually doing. Which in turn makes it hard to improve.

To make onboarding better, I have two major pieces of advice:

• 🔨 Treat it as a project — projects have a goal, a beginning and an end. Onboarding should make no exception. Create a series of activities that, once completed, have covered the basics to allow new people make a positive contribution. Pretty much like the introductory chapter in a videogame.

• 3️⃣ Consider the three levels — technical, managerial, and cultural. Make sure you don't just cover the basic needs for the everyday job (technical), but clarify people's role within the company (managerial) and help them feel part of the team (cultural).

Onboarding effort decreases over time as the contribution value of the new employee increases. In my experience, cultural onboarding is the one taking the most time.

When you combine the two advices, you get that for each level you should create a series of activities to cross off, to consider onboarding complete.

You can find more advice about onboarding employees in this previous Refactoring article.

The Three Levels of Onboarding 🎒

---

3) 🗿 Organizational benefits of microservices

I have come to believe that the benefits of microservices vs a monolith are mostly organizational, rather than technical.

This doesn’t make them less important, though.

As by Conway’s Law, your software design structure gets eventually shaped around your team’s communication structure.

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

— Melvin E. Conway

Conway’s law applied to the monolith vs microservices debate

So, if your team is large and you want to organize it around small independent teams, you may need to gravitate towards a service-based architecture.

The opposite is also true: you won’t probably get the full benefits of microservices as long as your team stays a single large unit. The overhead will not be worth it if it is not matched by the communication benefits brought by autonomous teams.

It seems to me that a solid recipe for any team might be to focus on modularity, and spin off independent services whenever you want to enable independent workflows, rather than (supposed) stronger technical qualities.

You can find more ideas about monoliths vs microservices in this recent Refactoring article:

Monoliths vs Microservices 🗿

---

💻 Typo

Last week we talked about Typo, which is a smart tool to help engineering teams code better, deploy faster, and stay aligned with their goals.

If you missed it, as a Refactoring reader, you can still get 30% off any Typo plan 👇

---

And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:

1) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. You can learn more about the benefits of the paid plan here.

2) ❤️ Share it — Refactoring lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!

I wish you a great week! ☀️

Luca