We are very fortunate to have Luca Rossi of Refactoring as our guest! He shares his perspective on balancing technical and soft skills, his information diet and seemingly simple but effective advice on collaboration. 

We discovered Luca and his writing through the Substack network and found his pragmatic and experience based advice refreshing and too good not to share with our readers from Engineering , Product Design and Product Management Luca has experience working at and founding start ups as well as working in larger organisations.

Source: Luca Rossi of Refactoring

So Luca, tell us about yourself and your journey.

Hey, thank you for having me! I am an engineer — and my first job after my M.Sc in Computer Science (CS) was as Chief Technology Officer (CTO) and co-founder of a startup in the travel space, named Wanderio, about 10 years ago. Wanderio was founded  after dropping out of my PhD in CS. It was a venture-backed startup in Italy, and I started guiding engineering teams when I couldn’t arguably guide myself.

We raised about $4M from Venture Capital (VCs) in Italy, grew the team to ~20 people, and served 25M customers. We eventually sold the company to a larger player in the same space, and I later joined Translated.com as Head of Engineering.

I have overseen scaling from zero to 20+ million customers, enjoyed big wins, catastrophic failures, and everything in between.

I started writing Refactoring in late 2020, and I quit my Translated job in 2021 to do it full time. So I am a writer now! Which raises more than a few eyebrows when I say it in public.

I am a voracious reader, but I have always struggled to find high quality, reliable content that really spoke to my work. Something that would make me grow as an engineer, a manager, and a human being.

Refactoring is my attempt to write the content I have always wanted to read. How to build processes, meet deadlines, manage an engineering team, and grow personally in the process.

What separates a good software engineer from a great one? Apart from programming language skills.

There are so many ways to answer this question! Because there are many different kinds of great engineers.

Engineers who have the most fulfilling careers, in my experience, tend to be those who deeply understand the tradeoffs that come from the nature of their product/business, and are able to communicate well with others.

Technical prowess is important, of course, but in the vast majority of cases, today, the biggest challenges come from working with other people, not from code.

If you judge based on what is most likely to get you promoted, I would say having a strong impact and working well with others.

What are some skills or areas that you invested in that helped you when you were a head of engineering or CTO?

What practices, routines, resources, and education has helped you today?

The truth is, back in my early days, I struggled to find good content for my education, especially about managing a tech team. That is a big reason why I started Refactoring. I wanted to fix that.

The activity with the highest ROI (Return on Interest) for me has always been talking with peers and mentors. And you really need both: mentors have past experience, but do not necessarily grasp the nuances of your reality. Peers do, but they lack the experience.

Shameless plug: these days I am investing a lot in the Refactoring community to create exactly that kind of dynamics. I would like people to be able to access other developers, managers and founders from various levels of experience, to cover all the spectrum.

For non-engineers, what advice do you have for designers and product managers working with Engineers?

What’s an example of a successful collaboration?

My best advice is to actually work together. The best kind of workflow is a back and forth, rather than a sequential pipeline. The best teams I met never went like: “first we do requirements, then UI design, then code, then ship”. It doesn’t work this way, or it might work, but you end up shipping a suboptimal product.

Engineering, product and design all have insights about what can be built and how. If they do not all contribute to the creation process, you waste creative energy, and you likely frustrate your best people.

One of the best metaphors I heard about creating a product is that the ideal process is that of a hot potato — you pass the potato around continuously to get everyone’s contribution.

What advice have you given out most frequently?

Probably to have more and better 1:1s! 90% of companies’ problems are communication problems, and 1:1s are the most powerful weapon you have to counter them.

A close second is to buy more and build less. As engineers, we have a bias towards building. We just like to build – but it turns out today you can buy almost anything, in the form of libraries, SaaS, no-code tools, and more. And strategically it is most often the right call.

Share

What do you think engineers don’t do enough of and should do more?

This one is easy: asking for help. Be it something about code, organization, or teammates, engineers are problem solvers, so whenever they have an issue their first instinct is often to fix it themselves.

But managers (and peers) are there to help — it is literally their job. Counterintuitively, being open about issues signals trustworthiness. 

We are back to communication issues, of course!

In this article, you speak about how to read online. How about giving us a glimpse into your information diet - what do you read, follow?  

Even before I started Refactoring I was a lot into newsletters. These days are the same — I read almost everything via email.

I tend to read those at the intersection of engineering and management, like Perspectives and The Pragmatic Engineer, but also others to keep a pulse on general trends, like Work3 and Exponential View. I also get daily digests about a few aggregators I care about, like Hacker News and Product Hunt.

Finally, I read some books, mostly fiction.

They say non-fiction raises your floor, and fiction raises your ceiling.

I agree with that.

What questions do you wish you got asked more often? 

How I create the drawings! Joking — they ask me that all the time (GoodNotes on my iPad btw).

Source: An image by Luca from Refactoring.

I don’t get asked often what life is like as a “creator”, or full-time writer. Many people just assume that it’s an idyllic thing where I just read and write all the time. There is a lot of it, of course, but it is also stressful in its own way, as you only work by yourself and you are not surrounded by a team anymore. But it’s incredibly rewarding, and I am grateful to be able to do this for a living

Here are the articles we recommend from Luca’s Substack. Make sure you subscribe to Refactoring.

• Taste vs Skills 🚣‍♂️

• Company Docs 📖

• How to Run Effective 1:1s 🧑‍🤝‍🧑

• How to Manage Your Time ⏱

• Changing Roles: from Engineer to Manager 👔

• How to Onboard Engineers 🎒

Thank you for reading the article! You can help us:

✉️ Subscribe using this button

⏩ Share this directly with your peers and others who will find this helpful. Apply what you have learned and teach it to someone else, it will make it easier to recall later.

Share

💬 Share this article on your Social Media (Twitter (we’re @readaskwhy), LinkedIn)

❓ Suggest topics or ask us a question

📥 Email us your questions, comments, and ideas. Simply reply to this email to contact us.