At the beginning of my career, I invested a lot in my technical skills. Very quickly, I knew that I wanted to move towards expertise. I was drawn to application puzzles, problem solving, architecture, or just technologies itself. I had the chance to work on various projects, in telecoms, banking, insurance. I practiced various technologies, C, C++, Tcl/Tk, PHP, Java and so on… I learned from very good mentors during 4 years when I worked in a service company. IT firms are very formative to start because you go from one project to another and you can develop your individual skills without being deeply interested in the business areas in which you work. Our impact is limited but we can learn faster.
La maitrise technique, une force et une faiblesse
Following my years in IT Firms, I spent 4 years with a software editor, in the finance’s sector. This is where I really discovered that I liked working on a product on the long term. Indeed, when you are a consultant, you are not the one who support the result of your decisions 2 or 3 years later. When working on a product, you are. During these years, I have many achievements of which I am proud. But retrospectively, I also think that I had reached a critical phase in my career where my expertise made me make many bad decisions. I sometimes made technical solutions too complex and I didn’t always think in terms of the impact for my users, or even in terms of financial impact for my company. Simplicity is however a strong mark of seniority.
You spend part of your career developing your personal toolbox. But very often over the years, we realize that simplicity prevails. And that’s honestly true at all levels of a business.
Processes can kill a business. Technical complexity can kill a product.
Growth creates complexity, and complexity is the silent killer of growth.
Chris Zook & James Allen
It sounds silly said like that. And yet, how many of us give in to complexity? It’s probably frustrating not to show your know-how. Or is it perhaps a form of intellectual laziness? It is indeed simpler to apply a theoretical solution, even complex, or a process, even absurd, without going further.
by concentrating less on technique, I increased my impact
Then I became a freelancer and became a contractor again, but on my own. I had acquired enough technical fluency to realize that my real added value was my ability to solve problems. I used my skills, but with a lot more interest in the users, in the business for which I was working. It is paradoxically by concentrating less on technique that I have increased my impact.
And it was from there that I was more often invited to enter this famous room where decisions are made.
Astonished reader: “What are you talking about? So expertise is useless for a senior perhaps?! It’s nonsense!!”
Let me be clear.
Do you see the picture above? This is the cirque du soleil.
You don’t know this circus? They have reinvented the codes of modern circus. You will not find any show with animals. You will appreciate a rich staging that tells a story throughout the show. I say no more, but if you have the opportunity to see them, do not hesitate.
Taken individually, each artist is eminently gifted. They are among the best artists in the world. But the success of Cirque du Soleil is linked to its reinterpretation of circus codes for a new, more up-to-date audience.
Of course the technique is necessary. It’s my toolbox. This is what I grew in my early years and would continue to hone throughout my career. But it is only a tool. And this tool should be used to solve the right problems.
Doing the right thing versus doing the thing right
Impact is created when effectiveness and efficiency meet.
Effectiveness is getting to the destination and efficiency is finding the best way to get there
You can be efficient, but not effective.
Does that seem counter-intuitive to you?
The photo above depicts many of the cars I searched on Google images with the prompt: “worst car designs”
I am convinced that each person involved in the creation of these cars is very competent in their field. They probably did things well.
But, for example on this car, what is the use of these two doors? I don’t think I can even open that in my garage.
Doing things right is obviously already very good, but it still has to be what your users really expected.
In fact, I’m going to give you a big secret:
Your users don’t care that you have met your deadlines, that you have 100% code coverage, that your architecture is theoretically perfect, that your project is a success, etc…
The success of your projects does not automatically lead to the success of your business..
But how can you be sure that you are working on the right subjects?
Become an explorer
Before even entering the room where solutions are discussed, you have to be in the room where problems are discussed.
To create impact, you have to work on the right subjects, and the main quality of seniors is precisely to determine the right problems to solve.
What is expected of any senior in a company, whatever the job, can be summed up as:
“Take this goal and find the problems we need to solve to get there”
For that, you have to be involved in the product exploration phases. It takes time to talk to users. If your product is used by street workers, go to the street with them, if used by customer support, watch them use it. Never rely on a proxy of your users , sales people and other internal stakeholders in your business, otherwise you will be creating a tool for these people, not a product for your customers !
If you’re familiar with Marty Cagan’s book Empowered,this phase is called discovery. The Software Engineer’s responsibility in this phase is feasibility (I will come back to your role in delivery in a future post).
Be careful, when I talk about feasibility, your role is not just to say whether or not a solution is feasible. Important fact, you don’t get paid to say something can’t be done, but to make it happen. You are there to bring alternatives to the table. And for that you have to be active, understand precisely the problem to be solved, hence the participation in user interviews, quantitative analysis, etc. To provide alternatives, you have to take a step back and ask questions. “Why” should be one of your most frequently asked questions at this stage.
This is called becoming a “Product Engineer” and it is very well illustrated in this Pragmatic engineer's article..
The qualities at this stage (listed in the article above):
- understand the business and user personas
- have an analytical mind and rely on numbers
- know how to listen and ask questions
- know how to popularize
- know how to expose compromises and propose alternatives
- propose solutions to particular cases, without falling into the gas factory (a manual solution is sometimes acceptable)
- know how to prototype to iterate quickly
Please note that your role is not that of Product Manager, however. He or she must answer other questions:
- the value (are you responding to a concern of your users)
- viability (would your company’s business benefit if you solved this problem, taking into account the constraints, legal, financial etc.)
On a small scale, in the early stages of a startup, you can have one person doing everything. I myself was dev/PM (and even a little UX) at the very beginning of Malt. But to do it right, you need a good UX/PM/Dev trio. I will probably come back to this trio in a future post.
Concrete example: setting up a datawarehouse at Malt
I invite you to discover how we set up the first data warehouse at Malt. The story takes place around 2015. Malt is about 15 people, including 4 in the technical team.
Our COO, Quentin, needed regular data from the app to produce analytics. For this he used Tableau software on his workstation. Tableau Software does not allow you to connect to a Mongodb database and that is what we were using.
He therefore came regularly to ask for CSV exports of our data. These exports were often different, sometimes he needed to extract different collection, or to aggregate with different data. It was time consuming for the tech team, which was very small at the time. It was inefficient for him, he didn’t have fresh data and it took him a lot of time too. In short, it was far from being optimal…
At some point, we decided to better understand his problem, and we came up with a technological solution. I’ll skip the details, but we ended up creating a mechanism for real-time replication of our data to a postgresql database.
And we could have stopped there.
But here is where I like to take up this quote attributed to Ford:
If i had listened to my customers, i would have created faster horses
And at this point, we had just created a faster horse.
By asking many questions, we finally understood that it was not just Quentin who needed data. It would be very useful for us to be able to analyze Product data and it would be useful for other people to collaborate on this data, which was not possible with Tableau Software.
We continued to dig and we brought an alternative to the table in order to use a dataviz tool in SAAS (Chartio, now defunct). This tool has enabled Malt to build a culture of self-service and collaborative data from 2016. This had a huge impact on the business for years.
It is by combining efficiency and effectiveness that we manage to be invited into the room where we talk about the problems. But above all, to stay there;) As you will have understood, it is not just a question of technique.
Questions for you
In conclusion to this blog post, I would like you to take a short moment to reflect on these few questions.
Can you explain your business in 30 seconds? And the contribution of the application or the team in which you work ?
Have you recently offered technology alternatives that have unblocked/accelerated your business and made it money?
Could you quantify it? Could you simply describe a recent quantified impact of your contributions to the company?
On the opposite, have you already implemented solutions which afterwards you tell yourself that they were perhaps a bit complex? Besides, are you the only one who can maintain it effectively?
Or did you sometimes feel like you “just” created faster horses when there were better solutions for your users?
Do you discover the topics to be developed during a kick-off session or sprint estimates?
I hope that these questions will help you on a daily basis to better identify the subjects on which to put your energy.
TIP
This blog post is part of the book Impactful Software Engineering. Feel free to read the other chapters.
