This week I participated in the “Path to Principal” podcast organized by Gianluca Rosania. Here, I unwinded the interview. Advise: no verbatim et literatim. Why? Because you’ll find many thoughts describing myself and my vision of software engineering.
Recording a podcast was absolutely a new experience for me and it was extremely exciting discussing with Gianluca about topics that I really enjoy. If you have the possibility to have a similar involvement, I really reccomend to take it because is funny and absolutely engaging. Here, my recording:
Gianluca: Today we have a very special person with us, his name is Corrado Calzoni. He is originally from Italy and graduated from Politecnico di Torino where he made a MS in land and environmental engineering & a PhD in geophysics. He has more than 20+ years of experience, an amazing career where in the last years he has been principal SWE in Roche. He is also a big contributor to the Engineering community and today we have the pleasure of having him with us. Corrado, welcome to the Podcast series “Path to Principal”, in this space we want to know more about you and how you got into IT and becoming a Principal Engineer. I would like to start asking to introduce yourself.
Corrado: many thanks for your warm welcome! I’m excited to be here, because I listened to this podcast and I heard a lot of inspiring people and I found a lot of useful information here. I realized from your introduction that It’s been a very long time since I started my career in the IT sector. Sw development has always been the leitmotiv of my career. And, I did a lot of jumps and changes of direction leaving behind geophysics and following my values and passions. For example: I worked as a researcher in the Politecnico di Torino and also at Georgia Tech in Atlanta. I created a startup company with some friends. And as you can guess, it never became the unicorn that I dream. It’s still running but I preferred to move away from geophysics, listen to my heart and start in the renewable energy sector. And finally, already 6 years ago, I decided to switch to the medical sector, where I can now have a direct positive impact on improving the life of other people.
Gianluca: Such an amazing experience Corrado, tell us what made you seek the Software Engineering path?
Corrado: Yeah, I started from a sector apparently far from computer sciences. I know it is not obvious the relation between geophysics and sw engineering. However, I found myself always searching for geophysical challenges where I need to program algorithms and softwares. Finally, I admitted to myself that I was more interested in the techniques and tools needed to solve the problems, than the problems itself. As a result, I found myself hungry to learn about new programming languages, design patterns, architecture tradeoffs, clean code or to catch up on development techniques, such TDD and extreme programming. At the end, more time I was spending in this new world, and more benefits I was discovering. For example, one of the main advantages that I already mentioned is the ability to switch to a new field and sector and work on more interesting challenges. What it really impressed me more about software engineering, and I still strongly believe, it is a relatively young subject. I know, it already has a long history, but people are still fresh in love with it. For example, our community is very active, there is a huge amount of meetup, events, ambassador programs, conferences. People in our sector love to share knowledge with others, much more than in other industries.
Gianluca: We need to start defining what a Principal & Staff Software engineer does? Can you tell us a bit more about this? Tell us about your path to becoming Principal Engineer?
Corrado: From my point of view a Principal Sw Engineer is a multiplier that boosts the development activities both in the team and wider in the organization. And here I would like to stress the importance of the sphere of influence. Because it is a key element to define the difference between a senior and a principal. For example, I can share here my experience. When I was a senior Sw engineer, I was already a technical reference in the team. For example to debug the toughest issues, or to anticipate technical challenges. However, when I was promoted to principal, I found myself struggling a little bit at the beginning. Because it was not enough to be the one that knew more about the product or the one that was able to make legacy code maintainable. Not anymore! In reality, I started realizing that I needed to use this broad understanding of our architecture and products, and start thinking holistically about the whole system. So, It was possible for me to increase my impact cross team, for example helping in planning and delivering complex multi-team features, or facilitating the decision making in the organization convincing other people about technical tradeoffs and decisions.
Gianluca: What are the key responsibilities of a Principal Engineer?
Corrado: This is a tough question and I can reply with the most common answer in sw engineering. It depends! Really! Each company has a different idea of a principal. I always get impressed when I talk with colleagues from other realities. And also inside the same company, there can exist big differences. For example, In Roche there was a big effort to define the engineering roles and standardize the responsibilities of principals in the different departments and sites that we have in the world. And I will say more, these responsibilities can differ according to the specific need of a project. From my point of view, the main responsibility of a principai is to boost the development productivity of an organization. Say that, this goal can be achieved in different ways: from providing oversight, coaching and guiding through code reviews, de-escalating conflicts about technical matters and also having conversation at the eye level with the leadership team of the organization.. Just to mention some examples.
Gianluca: Already as a Principal, what has been the most exciting challenge that you had?
Corrado: I think I had an interesting challenge when my department started the last reorganization adopting a new agile framework. The challenge is not the switch to SAFE itself, but the change in the leadership model that we embraced at the same time. In fact we moved away from the previous hierarchical structure, with top-down decisions. And we adopted a flatten model, with bottom-up decision making. Then, my previous role as development architect in the preparation and definition team did not make sense anymore. I was not anymore the one accountable and responsible for the design decision. Because, now the team itself was taking these decisions. So, I needed to figure out new ways to drive and influence product development. For example, engaging more in productive dialog with other colleagues with different ideas. I needed more collaboration across the project and the organization to build consensus around the technical decisions that previously were just defined in a more unilateral way.
Gianluca: Now for the future engineers that are listening, can you take us through the development of Instrument Management?
Corrado: Instrument management is a big and complex project. We develop common assets that are reusable by other Roche Instrument products. In this way we help our instrument projects to cut their time to market. Instrument Management is mainly developed with .NET technology and it has already a long history. So the legacy part plays an important role, In particular, you need to think that in the medical sector we ensure support of the product for a lot of years. Take in account that it is quite a big project, five teams, roughly fifty people. So, you can understand that development is really a collaborative process. So we try to take advantage of all techniques that help collaboration. For example we use Sample Mapping in order to facilitate the socialization of new features. We adopt Behaviour Driven Development in order to strengthen the collaboration among the development team, product owners and requirement engineers. And here it makes sense to add for example that we don’t have testers. Because testing is really one of our most important activities in our project and the most time demanding. So all the development team is in charge of the different levels and aspects of the testing.
Gianluca: What are some common architecture bottlenecks and some possible ways to mitigate against problems?
Corrado: Maybe the most dangerous architectural bottleneck can be the architecture team itself. I experienced this problem in the past, where different teams were relying on a specific team in order to make architecture decisions. This is absolutely dangerous. Because, from one hand, it can slow down the development of new features: a lot of alignments needed to step forward. On the other hand, it can also reduce the ownership of the solution by the different teams implementing this architecture. Because the teams feel that the solution proposed is just a solution, NOT THEIR solution. Sometimes this can be a structural problem related to an organizational chart. However, also a broken architecture can lead to the same problem. At the end, there is one truth: we always need to take in account Conway’s Law: “organizations produce software systems that are a copy of the organization’s communication structure”. Yes, absolutely: the communication channel of an organization has a direct consequence on the system that the organization develops. Luckily, it seems nowadays our industry learnt the lesson. And we have new architecture styles that mitigate this problem, reducing the amount of architecture bottleneck decisions. For example we have now microservices that can be deployed independently to the other part of the system. Domain Driven Design brings bounded context that helps to isolate a problem. Thanks to these new architectures, we can now shape our teams in a squad that own a complete vertical of a product. So, now the architecture team can just define a high level master plan. But you know: “the devil is in the detail” and here it is up to the team the possibility to solve the equation, with minimum alignment with the architecture team and the rest of the organization.
Gianluca: How do you prefer to interact with team members?
Corrado: I really believe in the lemma: leading by example. I strive for improving everyone’s skills in the team and I try to consider everyone when acting. I love to improve the best practices inside the team and try to evangelize people about important stuff such as: infrastructure automation, testing, clean code. I know that sometimes I’m not an easy going person: for example when pair programming I tend to question everything. But because I like to listen to other people, I try to understand them and consider opinions of others.
Gianluca: Describe your ideal team.
Corrado: Wow. Let’s see, if I would be Aladin and I could ask threew wishes to the genie. I will go for sure with a team aligned with my values. That put in order of importance they will be:
- respect for others
- transparency
- and a culture of constant feedback.
Then my second wish would be to stay in a team that believes in the software craftsmanship principles, that can be summarized in: professionalism, pragmatism and pride. And last but not least, a team where I can have fun with them. Really, I think when people have good time together they can make the impossible possible.
Gianluca: Describe the best team you have worked with.
Corrado: I have the luck to have worked in a kind of dream team. I always remember with good vibes the time I spent here in Roche when I started with Connectivity Platform: this is a project providing connectivity solutions to both medical instruments and laboratory information systems. This is the kind of project that you can love or you can hate: pure backend, a lot of legacy code, a project with more than 20 years. We were close to having developers younger than the code base… no need to add more. So, the project was recently moved to Spain and we were a fresh team with a lot of challenges, mainly for the lack of knowledge about the system. But there was chemistry inside the team, we were able to break the existing barriers among testers and developers, we were all sharing the same values and commitment. Also in the worst moments, we were able to have fun and with this energy we were able to overcome the problems. I’m not saying this team was extremely hard skilled or with the strongest technical knowledge. However, It was a team that you can trust on it. A team that no matter the issue, it will find its way to meet the goal. I really had a good time with these guys and I’m still in contact with them because we share a pile of funny anecdotes.
Gianluca: Describe a time when you had a problem with a coworker and what you did to make the relationship work?
Corrado: Ouch!! This question bite harder. One aspect that I suffered, and probably more than one time, is when I had recurrent technical disagreements with specific people in the team. I’m not saying that it is bad to have constructive disagreement, because this is absolutely healthy. I’m referring more to discussions that can push you in rabbit holes, endless one to one discussions that at the end bring to conflicts. Usually, I like handling this kind of conflict opening the discussion to a broader audience in the team. So creating a debate where I shared my idea and were open to hear other opinions. As a result, sometimes I realize that I was wrong, maybe I was not seeing the full picture. But other times, with my arguments I can get the buy-in from the entire team. So as a result, I can resolve the conflict because the team itself took ownership of the solution and at the same I also increased the knowledge sharing in the team.
Gianluca: What are the pitfalls of overly relying on hard data when making important decision decisions? Give me an example?
Corrado: This is absolutely a good point. And if we define hard data as verifiable data acquired from a reliable source, we can fall into the error that just analysing hard data we can already take weighted conclusions. However, we need to take in account that Sw engineering is a collaborative process, it implies humans and is complex by its nature. So hard data is not enough, we also need soft data. And soft data does not mean that are less precise data or unreliable. Soft data means that they are based on qualitative information. If we use a medical analogy: a medical study can be composed by harda data, like blood tests, temperature or blood pressure. But it can also contain soft data such as asking the patient to rate his symptoms. Hard data in this case is blind without listening to the patient. In sw engineering it is the same. For example, It is fundamental to collect data about static code analysis, test coverage, rate of test flakiness, turn around time to fix a red build. However, I disagree with KPIs with these harda data in the power points and excel of managers. Usually, you need qualitative data to interpret these data correctly So it is better to leave these data in the hands of the sw engineers and let them make informed technical decisions with them.
Gianluca: What team KPIs/OKRs does your team observe or pay attention to?
Corrado: We recently embraced the usage of Objective Key Results. And it really helped us to make sure everyone is moving in the same direction. We have OKRs at different levels: personal OKRs and shared ones. At the end, these OKRs connect people, teams, working groups and departments, upward, downward and sideways. What it really matters for me, is that these OKRs are not defined from up to bottom. In fact, we create working groups to define the OKR. So, people can join according to their personal interest and motivation. I personally have a special interest for quality, automation and more generally to have a SW Engineering culture in the company. So I was particularly active on working groups moving these OKRs. Just an example, this year we are focused on fostering lean and agile behaviors by applying engineering practices. So, we have key results measuring the lead time: the time elapsing from starting a feature and the moment we get feedback from the client. We measure how many recurrent manual tasks we were able to get rid of, the number of documents we have removed or automatized. In fact, you need to think that we are in a heavily regulated environment and documentation and process plays an important role. So, we have a lot of effort to automate them as much as possible in order to increase efficiency and ensure quality.
Gianluca: How do you gain credibility from the engineering teams as a new Principal Engineer?
Corrado: First of all and without any doubts, mastering the technical side. People in a team when facing burning technical issues are looking for a Principal to get a solution. Maybe you don’t have the solution immediately, However you should be able to provide a direction that shows the light at the end of the tunnel. I don’t want to say here that you should be the overprotective mother that solves all the problems. At the end “No pain no gain“. So if more junior engineers do not challenge themselves with the problem, they will never grow. Said that, each one has his own style to gain credibility in the team. Some people rely strongly in their problem solving skills and in their delivery firepower. I sincerely prefer to balance these technical aspects with others as the capacity to inspire and influence my colleagues. From one hand I like leading from the back and acting coherently being an example. On the other hand I also strongly believe in the importance of providing constant feedback. Both positive feedback and for sure also the one more difficult to give: the constructive feedback. Finally, In order to really gain credibility it is key to be able to mentor your teammates. This is a long journey that I embraced and I know I’m still far from the end of this journey.
Gianluca: What’s a key lesson you’ve learned in the Engineering Field that you hold on to and use?
Corrado: A key lesson that I found quite useful also in my life it is the “second system effect”. When I read about this phenomenon in the book “The Mythical man month” it was like: man this is: The Truth! I saw evidence of this effect a lot of times and I will say that I also had a confirmation when he was born my second son and I took care of him. In fact, when you are architecting your first system you are usually quite prudent and you design it carefully. Because: you know that you don’t know. So if you have some fancy improvement, you take apart and think maybe I will add the next time. Then, you finish your first system and you prove that you master this kind of system. So, it comes to your second system: Now you are more confident. And here there is the risk that you start adding all these cool and elegant ideas that you had in the previous experience. Moreover, there is also the tendency to push the refinement of existing functionality to their limit, when maybe are now close to be obsolete. As a result, your second system tends to be over engineered and way more complex than actually needed. How can you avoid the second system effect? First of all, with extra self-discipline to avoid functional ornamentation. For example you can assign to each function a value: capability X cost Y and affect performance Z. Weighting these considerations can be a guide for initial decisions and also a warning during the implementation.
Gianluca: Amazing career Corrado, from George Boole until today what do you think is the greatest challenge in Sw Engineering is the future of technology in the coming 10 years?
Corrado: Yes, I have a strong opinion on this point. And I think by far the most important challenges will be ethicals. It is clear that we are already seeing an exponential growth of software and hardwares. And these solutions developed by software engineers are having unforeseen impacts on the life of billions of people. I’m not sure that our industry is taking seriously the burden of this responsibility. I mean, new data analysis algorithms allowed a company as Cambridge Analytica to change the history, influencing Brexit and the last US election. A cheating embedded software allowed thousands of cars to pollute more than allowed by the laws, how many people are suffering respiratory diseases for that? Biases data set has been used for train machine learning algorithms affecting face recognition of minorities. This is just the starting point, we can not even imagine what will be the impact of our works in a few years. For example: I’m not sure if we as developers in our daily work we are asking basic questions: Who plans to use my software? What are the worst-case scenarios if someone misuse my system? What safety controls can I put in place? Could my software potentially hurt, control or profile other people? If I was born with a different gender or race, might I feel differently about the app I am creating? Is my system potentially affected by bias? I really hope to see more debate on these ethical aspects related to software engineering in the near future.
Gianluca: Thank you for this magnificent class about Principal Engineering :) Now changing the topic, a diverse workforce can capture a greater share of the consumer market and be more inclusive, at Glovo we advocate diversity. What would you do to increase diversity?
Corrado: I’m very happy to hear that you take care of the diversity in Glovo. It’s fundamental to have a sustainable workplace. And I will say that more than a diverse workforce, what we really need is an inclusive workforce. In fact, we should create a place where everyone feels they belong to, no matter if we speak about people of differ gender or different race. An inclusive place, it’s the one where we minimize the unconscious bias in the team, where people actively remove judgements and discriminations that may occur. It is absolutely hard to achieve and we really struggle in the tech industry to find the correct receipt. Just hiring more people from underrepresented groups is not enough. Because the real problem is: these groups face a huge problem in ascending to a more senior position and getting in the leadership teams. What we really need is to have people in management positions that believe in the value of inclusion. So they could mentor and more importantly sponsor valuable persons from these unrepresented groups. These people need example models in the management chain where they can learn from and aspire to be. From my point of view, a good starting point for a company that wants to have an inclusive workforce is to publicly state a cut of the salary gender gap. Not only because it’s the fair thing to do, but also because it is a clear message that the company spread outside. As a consequence, it will attract a different profile of candidate, more sensible to these problems, and this could be the seed of a better work environment.
Gianluca: What would you recommend or say to any person that wants to start in Engineering?
Corrado: Here, I would steal some worlds from Sandro Mancuso, because I really advise a junior sw engineer starting his career to become first of all a software crafter. You are the owner of your career. Do not just sit and wait for your employee to buy a book for you or pay a training fee for you. Do you want to become a better developer? You need to keep up to date. Our industry is moving so fast, More knowledge you have and better company and better projects you can join. The question is how can you achieve it? Start reading many books: not only books of specific technology: they expire very soon. You need to also read the classics and the behavioural books. Also Read blogs. Join the community, learn from it but also give back sharing. And more important practice, practice and practice: with coding dojo, pet project, contributing to open source project. Remember that becoming a better professionals it’s a lifetime commitment.
Gianluca: Thank you Corrado for being with us and sharing this amazing experience. Looking forward to sharing with you! Thank you for attending this Podcast please stay tuned for future guests!
If you want to hear the podcast, you can find it in the following medium:
- Spotify: https://open.spotify.com/show/1vpKZWwWwgbmRuMJtqG22W
- Anchor: https://anchor.fm/gianluca-rosania/episodes/Path-to-Principal—Corrado-Calzoni-Roche-Podcast-5-ehbi69
- Pocket Casts: https://pca.st/xv6gupb8
- RadioPublic: https://radiopublic.com/path-to-principal-6BVYza/s1!1540e
- Breaker: https://www.breaker.audio/path-to-principal/e/70026690