Managers, threat modeling, and hiring last 💡
Monday Ideas — Edition #153
1) 🛑 Guardrails for AI-generated code
This idea is brought to you by today’s sponsor, Codacy!
Last week I joined an awesome panel hosted by Kendrick, VP of Technology at Codacy, about writing secure code. We discussed shifting security left, and how for many teams this fails because of a combination of 1) excessive cognitive load, 2) unclear ROI, and 3) lack of expertise.
Kendrick also demoed an incredible new tool from Codacy called Guardrails, which runs inside your IDE, makes itself available to AI through an MCP server, and secures AI-written code before it gets touched by the developer.
I love this approach. Live services exposed through MCP inside your IDE looks like the future of dev tools to me. You can try the free developer package below 👇
2) 🔒 Threat modeling
Speaking of security, one of my favorite practices around it is threat modeling.
A threat model is the description of an application and its environment through security glasses.
Likewise, threat modeling is a family of activities you pursue to identify threats, vulnerabilities, and design countermeasures to prevent or mitigate such threats.
Historically, designing for security has often followed the security sandwich approach: you address security during design, and you test things at the end. This waterfall-ish approach, though, clashes with reality: specs often change during development, so you end up testing for things that are 1) incomplete, or 2) not relevant anymore.
Good threat modeling should be applied continuously throughout the whole development lifecycle.
You can check the dedicated OWASP page for more details about how to perform it, complete with practical examples.
3) 🏆 What does your manager care about?
Different roles see the world—and the organization—through different lenses.
This is obvious for roles that are very different from our own—e.g. a CFO who sees everything through unit economics and cash flow—but it is also true for closer ones, like engineering managers vs tech leads, or EMs vs software engineers.
In these cases, the shift in perspective is more sneaky. As an engineer, you may care about your own developer experience, while your manager cares about team productivity. You may think in terms of architecture improvements, while your PM thinks in terms of product enablement. Are these related? Very closely. Are they the same thing? Absolutely not.
Quoting our coach-in-residence Joel:
The better we understand the goals that our managers have, the less surprising their actions will be. […] Some of the situations where managers act in ways that most dismay or surprise us are when they are acting on their fears and worries.
Understanding your manager’s context and priorities allows you to map your goals and concerns into their own. This boils down to asking two questions:
➡️ What makes you successful? — What are your goals and concerns?
⬅️ What makes me successful? — How can I help you reach your goals?
The only way for you to be successful is by making your manager successful. For many this isn’t obvious, so let that sink in!
I wrote a full article on managing up a few months ago 👇
4) 🏁 Hire as last resort
When is it the right time to expand your team? What are the signs? If you search online (or talk to people), you often find conflicting advice:
⬅️ You should hire early — before problems get too big.
➡️ You should hire late — to avoid premature scaling and burning money.
This dilemma is high-stakes, for two reasons:
Hiring is extremely expensive — both in terms of compensation money, and the time your team needs to spend on the process.
Reverting is hard — firing sucks for everybody, so you want to optimize for doing that as little as possible.
Because of this, I believe in using hiring as a last resort. Last resort with respect to what? Well, it depends on why you are hiring in the first place.
In engineering teams you hire people for one of two reasons (or both): throughput or quality.
Hiring for quality 🔍
You hire for quality when you have a skill gap on something, and it clearly limits growth. Whatever such skill is, before you hire you should ask yourself:
Can you learn it? — can your engineers acquire that skill? Smart people learn faster than we usually account for, and hiring takes a long time anyway.
Can you build a first version? — it is rare that you can only bring value with top-quality execution, and prototypes are useful to educate your taste and to better understand what you need.
Often times, a combination of (1) and (2) is enough to satisfy (or delay) your need.
Hiring for throughput 📈
You hire for throughput when growth is slowed down by pure bandwidth.
In my experience this is trickier to judge than quality, because most factors that slow down your team do not get better with size — quite the opposite.
Bad dx, unclear priorities, confusing org structure, are all systemic diseases that you will not solve by throwing more people at them — you will arguably make them worse.
So, counterintuitively, the best time to hire is when your team is in great shape and firing on all cylinders. If that’s not the case right now, you should probably focus on fixing what doesn’t work first.
Finally, increasing headcount has diminishing returns: adding one engineer adds less than one FTE to your dev resources — and the larger your org, the larger this gap. That’s because the cost of coordination grows more than linearly with respect to your headcount.
I wrote more principles about hiring engineers in this recent piece 👇
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) 🔒 Subscribe to the full version — if you aren’t already, consider becoming a paid subscriber. 1700+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 📣 Advertise with us — we are always looking for great products that we can recommend to our readers. If you are interested in reaching an audience of tech executives, decision-makers, and engineers, you may want to advertise with us 👇
If you have any comments or feedback, just respond to this email!
I wish you a great week! ☀️
Luca