Onboarding, leading skilled engineers, and observability💡

Monday Ideas — Edition 114

💬 Unblocked – Get the right answer, now

Developers know how to write code. Most often, what is slowing them down is having to search for the context to know what code to write.

That’s because codebases are a compilation of thousands of past decisions and discussions that live across multiple tools, like GitHub, Slack, Jira, Confluence, and more.

For this reason, I am happy this week to promote Unblocked, which surfaces hidden knowledge and gives engineering teams the answers they need to get their jobs done – without having to wait on or interrupt their teammates.

You can try Unblocked for free at the link below.

Back to this week’s ideas! 👇

---

1) 👯 Onboard engineers by pairing

Companies often focus on speeding up the hiring process, but forget that onboarding is a key part of bringing new talent on board.

You may celebrate quick hires, only to find out that new employees aren't fully productive until a year after joining.

I feel that many teams underestimate the importance of effective onboarding, and they do so because onboarding is generally viewed as a documentation-heavy, hard-to-maintain process.

However, it doesn't have to be this way.

One powerful yet overlooked method to onboard people efficiently is pairing.

Pair programming, and pairing on tasks in general, is a great way to share knowledge without the need to have thorough docs ready in advance. You may pair new hires with an onboarding buddy, or with various people from their future team, based on the task at hand.

In the context of onboarding, pairing is helpful for many reasons:

• 🍻 It builds rapport — it is a great way to kickstart relationships between co-workers, especially on a remote team.

• 📑 It highlights missing docs — you realize what information is available in written form, and what can only be transferred in person instead.

• 🪴 It is a growth opportunity — pairing emphasizes communication, giving and receiving constructive feedback, and working together towards a goal. These skills are useful in many situations: from managing people, to mentoring, to negotiating with stakeholders.

I wrote a full article about onboarding engineers, which you can find below 👇

How to Onboard Engineers 🎒

---

2) 👑 Leading engineers more skilled than you

In a recent Mastermind session on the community, a CTO of a growing startup asked how he should lead his frontend team, being more of a backend guy himself.

The answer depends, primarily, on what kind of contribution you believe you should provide:

• How hands-on do you believe you need to be? Why?

• Why are you pulled into technical conversations in the first place?

• How do you envision your ideal role in the dev process?

You won’t find these answers in books or articles (including this one!), but rather by figuring out what your team truly needs from you.

At my startup, after we raised our Series A, we went to hire a few senior engineers to level up some strategic parts of our stack. Among them, we hired a lead frontend engineer who was 5-6 years older than me, and had been in the industry for even longer.

At the beginning, I didn’t know how to handle that relationship. I felt that I had to prove myself, and that being the CTO meant I had to lead my tech team on pretty much everything.

So the first months were a bit rocky because — guess what — I had no idea what I was doing.

It took a long time to embrace what now looks obvious to me: you can’t be a super set of all of your team’s technical skills.

That doesn’t mean though, that you go hands off and take a back seat. Even if you are not doing the bulk of the coding, as a CTO, you have unique strengths to lean into:

• Provide the right context for your team to make decisions

• Provide guidance about the business and the wider strategy

• Ask the right questions, challenge the tradeoffs, and make people bounce ideas off of you.

Of course, your mileage may vary.

In small teams you may want to be more hands-on, so you may upgrade your skills to stay so. And, in any part of the stack, you should probably be proficient enough to being able to know what’s good.

But it’s important to understand that strong technical leadership is only one of the ways you can contribute as a CTO, and not necessarily the one your team needs the most.

So, to figure out your role, always start with your team’s needs, and go backwards from there.

You can find more lessons from the masterminds in this recent newsletter edition 👇

Lessons from our Mastermind sessions 🧠

---

3) 🔍 Good observability leads to continuous delivery

In our recent interview with Charity Majors we talked about continuous delivery and how this is enabled by good observability. In fact:

1. Good observability == being able to get closer conversations with code, plus drawing correlation with business value.

2. Closer conversations with code allow to tell at a glance when something is not working.

3. Spotting problems quickly grows the confidence to ship many times a day.

This virtuous cycle, however, can only happen when you get the code out in real environments in a small enough amount of time that engineers still have all that context in their head, so they go and check production against the instrumentation.

Charity goes even further and says that, as an engineer, your job isn’t over until you have looked at production to see that everything works.

This is the natural evolution of integrated teams, which went through various stages:

1. Testing — it used to be that QA ran all the tests → until we figured out it’s better if engineers do so.

2. DevOps — it used to be that ops people were separate from devs → until we figured out they should not.

3. Observability — it used to be that engineers’ job was over when they pushed their code → until we figured out it’s better if they look at how it works in prod.

Death Spiral 💀

Conversely, when you don’t get code out fast, and you don’t get it out automatically, you enter the software engineering death spiral, where everything starts taking a longer time.

Code reviews take longer. Disks get larger. So people back up more. So they end up switching projects more. So they are waiting on each other more. Then you need a release engineering team and SRE team. Then you start batching releases, which further increases risk.

You can find the full interview below 👇

Observability & Testing in Production — with Charity Majors 🎙️

---

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

1) 🔒 Subscribe to the paid version — if you aren’t already, consider becoming a paid subscriber. 1500+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.

2) 🍻 Read with your friends — Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.

I wish you a great week! ☀️

Luca