I started my career with a first internship in a web startup in 2001. I believe I built a solid experience as a developer. But throughout my career I had several experiences that made me realize that there was a problem in the way many companies approach product development.

Have you ever experienced those famous product & tech decisions that were clearly not to be made and could have been avoided easily by having a tech person in the room?

It was too expensive, technically unrealistic, totally opposite to current market practices, not in adequacy with the users' expectations, not taking advantage of a recent innovation. In short, we could have done better and saved the company time and money.

Software engineer not in the room where important decisions are made

Software is eating the world

You probably know the expression "Software is eating the world". Software is everywhere today in our daily lives. It follows you on your mobile, at work, in the transport.

If some companies still talk about cost centers when they talk about product teams, how many of them would be totally inoperative without these teams?

Regularly, we hear about a new sector being radically transformed by a new Pure player. Our lives have been changing continuously under this strong technological pressure for the last few decades. And I think we are not yet ready for the future evolutions linked to AI.
On this topic, I invite you to read Kai-Fu Lee's book, AI superpowers.

But why, despite this, we continue to see product teams working without involving the engineers who will implement these solutions?

In some environments, the tech executes and that's it. It's a shame, because far beyond knowing how to write code or set up software factories, the first skill of a "software engineer" is to solve problems and design solutions.

Tomorrow's products cannot be designed without the engineers who make them, and this, from the very first steps. You can't live in a technological world and not understand it. Teams that don't grasp it are at a serious disadvantage. I'm not talking about state of the art or software quality, I'm talking about gaining a competitive advantage in a fast moving market full of uncertainty. The last few years have shown us how radically the world can change in a very short time.

But for that to happen, you need to have engineering teams in that famous room where decisions are made. And I've been in several situations where this was not the case, for many reasons.

Seniors not aware of their role

If we consider only technical skills, I have known very good engineers, but who did not understand their role. These people did not see the business as a whole and could not see how to create impact. Their time management was problematic, whether it was how to organize it or how to prioritize it. They sometimes ended up burning out, while never working on the important issues.
Sometimes, these people had the right insights, saw what needed to be done, but didn't know how to communicate, or even considered that it wasn't their job to bring these ideas to fruition.

Patchwork engineering teams

Sometimes the action of the engineering teams is too vague. It seems to have no clear direction beyond the RUN. Teams don't scale, because management is too present and has turned into a Single point of failure, sometimes it's the opposite, teams are autonomous, but don't follow any common vision. Leadership is unable to create effective teams, and here again it fails to impose itself as a reliable actor who must participate in the construction of the product.

Sick product organizations

In some cases, it is the entire organization of the company that is the problem. They talk about agility, but continue to make a disguised waterfall where Engineering is relocated, in another building, another city, another country, and never consulted. These are also companies that have sometimes given in too much to complexity to cope with their growth, pushed into this by armies of certified consultants, experts in Scrum, or worse, SaFe, CMMI and other horrors.

Building engineering teams that create impact

All of this formed the groundwork for my personal beliefs about how to run a product organization.

When I participated in the creation of Malt, I had two main motivations. The first was to shake up the codes of the Consulting/Freelancing market, to change the practices to make them more transparent, to dismantle the intermediaries, to simplify the life of freelancers.
But the second reason was to build a company, in which I would have liked to work myself as an employee. And one of the factors for me was to create a strong, efficient Engineering and Product culture, which is the main vector of our growth.

This is what I want to share in the future chapters of Impactful Software Engineering of which this blog post is the introduction. I want to share what I have learned over the years and allow other technical leaders to benefit from it.

I want to address in particular the "Tech Leads", whoever they are (CTO, Staff Engineer, Senior Engineer). By ricochet, it can be useful to Engineering Managers (VP, Eng Manager, Directors of eng...) whose help is needed.
But of course it can also be useful for other people interested in building an efficient product/tech company.

In the following chapters I will talk about the qualities expected from Software Engineers to make an individual impact.
I want to discuss the notions of leadership to multiply one's impact within a team.
I will describe what I consider to be an effective engineering organization and the pitfalls not to fall into.
I will also describe what I consider the most effective way to make product, and the role of Engineering in these two key phases, Discovery and Delivery.

On the other hand, I will not talk much about management. This book will of course deal with the notions of career path, of engineering manager, but it will be done for individual contributors.
Similarly, I will talk about products, but I will go into less detail than Marty Cagan or Teresa Torres whose books I recommend.

Finally, this is not intended to become the future support of a coaching method. If one day I were to seek a new adventure, it would not be as a coach or counselor. I know to be wary of these types of predictions which often turn out to be wrong. But I know from having done it that I get way too frustrated in these situations and need to get my hands dirty.
Anyway, this book will not give you a turnkey method to apply, but rather talks about finding impact and attitude.

Disclaimer

I have been the CTO and co-founder of Malt for 11 years as I write this. We started with 3 people and are now over 600, in 6 countries with half a million registered freelancers. I've helped build a product team of about 130 people and have learned a lot over the years.

I'd like to start with a disclaimer. We all have biases. And it's important to understand my biases in order to understand what I'm going to write about in this book. Also, I am aware that I have more to learn. At Malt, I made mistakes and I still make them.

I have worked for several years as a Consultant or Freelance. In this context, I worked for very large companies, in telecoms (Bougues Telecom), banking (Société Générale), insurance (Axa), travel (Expedia Group), security (Airbus Group), energy (Enedis).
I also worked for a software editor in finance (Sungard).
Finally, I have been working for more than 10 years at Malt, which has become a major European scale-up.

I am quite proud of my career path. But I know that I only know a small part of the industry.

So my biases are the following:

• I consider myself mostly as an individual contributor (as opposed to manager)
• I have a strong background as a Backend Developer, and today more as a Web Developer
• I think I have an entrepreneurial spirit, not very averse to risks and changes
• I have worked in very large companies, but never in a Big Tech
• Even if I work in English on a daily basis in an international context, I have only worked in France.

Finally, second warning, there is a difference between the opinions I can express here, the direction I want to take, and the reality of my daily life which can be more contrasted. Malt has dysfunctions, like everywhere else. My opinions are sometimes addressed to myself and give me a direction to go.