Discover more from Refactoring
Monday 3-2-1 – quality is systemic, CTO's work, non-technical managers 💡
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 the regular long-form one on Thursday, like the last one:
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.
1) 🔄 Quality is systemic
I have found that good software quality is more the result of good systems and processes rather than individual performance.
A team of average developers working in a system designed to produce quality will eventually produce better results than a group of amazing developers working with processes that are not designed for that.
As Jacob Kaplan-Moss writes, good systems form virtuous cycles:
Great tests catch errors before they become problems.
Tests require a structure that affords the time and space to write them.
That structure exists because engineers are comfortable speaking up when they need extra time to get the tests right.
Engineers are comfortable speaking up because they work in an environment with high psychological safety.
That environment exists in part because failures are seen as systemic, and individuals won’t be punished, blamed, or shamed.
More lessons learned about creating high quality software 👇
2) 👑 CTOs work on tech and process
Since I founded my startup, in 2012, I have often been involved in mentoring other early-stage founders and CTOs. I still do it today.
The most recurring question I get from CTOs is: “what should I work on?”. Or, if you prefer, “how should I spend my time?”.
Providing a direct answer is impossible, because the CTO role depends on many factors. Nevertheless, I have found some common traits in the work of the best CTOs I have known.
In early stage startups, there are three main responsibilities you need to cover: Tech, Product, and Marketing.
Such areas are not clear-cut and have often big overlaps. For example:
SEO is a marketing / distribution topic that also requires a strong technical work.
Refer-a-friend strategies are both non-trivial product features and distribution channels.
A good technical strategy often informs the product of what can be built. Famously, Steve Jobs decided to build the iPhone after he saw a prototype of a multi-touch screen in the lab.
The biggest overlap of all, though, lies at the center, and is about process — that is, how people work together.
Out of the various leadership roles, CTOs are the ones who most likely take care of this. That’s both because of their engineering mindset — they often see the company as a system, and act accordingly — and because in tech startups the engineering dept ends up being the largest (or one of the largest), so there is more need for structure.
I wrote an article about how you can work on tech and processes, as a CTO, at various startup stages 👇
3) 👔 Non-technical managers’ careers
I know many successful engineering managers who don’t have a technical background.
That is despite the popular narrative that engineers only respect managers who are very technical. In my experience, in fact, engineers respect managers who are straight-talkers, give them ownership and keep them accountable — technical or not.
However, it is true that as a non-technical EM you will likely face more scrutiny, both in interviews and at the beginning of your tenure in a team.
So, what should you do to win such resistance and have a successful career? Here is my best advice, based on success stories I know:
📋 Build a track record
This is the most important thing. Companies you interview with will always ask about your achievements and past experiences. The more you progress in your career, the less your original background matters, and the more you are defined by your work experience.
🔧 Study CS fundamentals and system design
This is way better than coding. For managers, it is more important to be comfortable with high level concepts and the relationships between them. Try to learn the basics of databases, caching, backend vs frontend, and distributed systems.
🔍 Study your company system
At my previous startup, my CEO was non-technical, but at a high level he knew everything about our system. In conversations he could easily pass as an engineer, often giving pointed advice about what could have caused an outage, or how systems could better exchange information.
Knowing your system well can easily trump your absolute technical proficiency. You can pair with engineers in your team and let them explain to you the various moving parts of the system and how they relate to each other.
More ideas about managers and tech skills 👇
📣 Join the Refactoring Talent Club
If you’re looking for a new gig, join to get personalized opportunities from hand-selected companies. You can join publicly or anonymously, and leave anytime.
If you’re hiring, join the Refactoring Talent Club to start getting bi-monthly drops of world-class hand-curated Engineering people who are open to new opportunities.
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! ☀️