Newsletter #26: Onboarding Engineers, Strategic Thinking for Engineering and Engineering Leads and More
The Effective Software Leads is a monthly newsletter on software engineering and leadership.
Welcome to the 26th edition of Software Leads. As always, I've included my top discoveries from the previous month below.
Strategic Thinking for Software Engineers and Engineering Leads
“The single responsibility of the engineering organization within a company is to ensure the business wins. That’s it. Everything else you do is subservient to those.
In software engineering, we talk about quality. We talk about speed. We talk about using the latest frameworks, having proper architecture and so forth. All of those are great stuff. But unless we get our north star in place, we will be blindsided by shiny new frameworks, marketing gimmicks, trends, and bloggers masquerading as know-it-alls.” A couple of years ago, I realized that high-leverage tasks don’t have to be technical. Sometimes, what will make a business win is a boring, simple mundane task that is not technical at all. When you work on stuff that will make the business win, your impact increases.
Why Is a Senior Engineer… Senior?
Being a senior engineer takes more than just technical abilities. Technically, a senior engineer should be technically skilled, but that is only a drop in the ocean. This article discusses six characteristics that distinguish a senior engineer.
Two-way Writeups: Coda’s Secret to Shipping Fast
One of the first changes I made once my duties grew was to reduce the number of meetings I had. My approach was simple: I doubled down on writing. I use writing to communicate decisions, discoveries, and ideas, and I encourage async contributions from team members. In the age of remote work, I've found that two-way writeups are critical for quickly aligning teams without compromising team members' focus time. I particularly find it interesting to learn about Coda’s approach in this post.
Setting OKRs is an established way to describe what your objectives are and how you measure success. If you're a software lead, you're probably involved in establishing OKRs for your teams. This article will provide you with some pointers on how to make better OKRs.
Motivating Developers to Care About Documentation
“What documentation is can be boiled down to this: documentation is writing down “what we do right now” or “how something works”. The point of documentation is to enable automatic and decentralized decision-making, which is essential for scaling up.” Writing documentation is one of the few things most developers don’t enjoy doing. This post provided some excellent recommendations for engineering leaders on how to get engineers to start taking documentation seriously.
Techniques for Managing Up, Down, Sideways...and Inwards
This post summarizes 9 ways to manage up, down, sideways, and inwards. It’s heavily inspired by Marty Cagan's book titled Inspired. It’s a thought-provoking piece that I hope will help you become better at managing.
“Once an engineering org has more than a few people, making big decisions can be hard. Often there are lots of people who can say no to an idea, but it's hard to find anyone to definitively say yes”. If you have been there, I hope you find inspiration in this post by Tanya Reilly on how her team iterated on a common approach to driving change or software development through RFC and finding a balance that made them happy.
How to Onboard Engineers as a Hiring Manager
In this season of a hiring spree, there is a chance that you’re hiring and onboarding engineers into your teams. Last month, I shared a few thoughts that govern how I approach onboarding engineers into my teams. In a nutshell, it goes like this:
Start onboarding from the hiring manager’s interview. Help candidate connects to your team’s purpose.
Use the notice period to your advantage. Continue to build on the candidate’s excitement about joining your org or team.
Have a comprehensive written down onboarding guide. Nothing scale better than a written-down onboarding guide.
Don’t leave engineers to figure out the tech part no matter how experienced they’re
Set clear onboarding and role expectations
Conduct regular check-ins
Assign an onboarding buddy
Collect feedback and improve
You can check out the original here.