Interview Transcript (Anonymized & Translated from Italian)
Giuseppe Silletti: What are your main responsibilities at the moment?
Tech Lead: We’re divided into product areas, so each area more or less has a tech lead. The responsibilities are both people management - team management, performance reviews, continuous feedback, people growth, code reviews, etc. And also purely technical - having a vision of how that part is going from a technical point of view and coordination with the rest of the pillars, the other tech leads, so we have a unified vision regarding architecture, technological evolution, etc.
Then there’s also the product side, because as you may have seen, we generally don’t have product managers. Well, we have a couple, but they’re on very specific verticals. My team doesn’t have a product manager, it only has a product designer, and they have a very full-stack role. They handle discovery - so when a business need comes in, like “we want to implement an automated voluntary resignation process” - they start with discovery, interviews with clients, with ops, etc., all the way to defining the UX. Also at the service design level - all the flows, what happens behind the scenes, who takes charge of the various tickets, the operations to do, and then finally arriving at the Figma, where we actually develop.
As tech lead, I also support the designer - maybe not in the interview phases, but when the needs are a bit clearer, I start supporting the designer to understand from a technical point of view what can be done, what can’t be done, the complexities, and from there it becomes more of a co-design phase.
Giuseppe Silletti: So the product designers essentially take on some responsibilities of product managers?
Tech Lead: Yes, essentially yes. So also regarding defining KPIs, then obviously we have business milestones in terms of revenue, turnover generated, etc. - those are defined by the designer but often together with the co-founder, or now on new things maybe with a chief of staff who’s more on the business side and handles launching various initiatives. So the business side is covered by figures who are a bit transversal within the company, but from there onwards it’s work done together - designer and team, tech lead.
Today there isn’t a big distinction between tech lead and team, in the sense that depending on skills and what you like to do… I started doing this thing of following discovery before becoming tech lead.
Giuseppe Silletti: In your experience, not necessarily at this company but maybe at others too, what was the most painful thing in the collaboration between tech and product, business?
Tech Lead: Probably the most painful was at a real estate tech scale-up, because it was a company that was growing very rapidly, but still very based on hype - there wasn’t all this demand for the product externally. I was lead of a part of the product that was basically their version of a real estate portal, which served for internal listings and then was also opened to agencies we collaborated with.
For me it was painful that we kept growing, kept throwing in developers, but not because there was a need from people saying “I want your product, I want a thousand features, etc.” But more to essentially make the venture capitalists happy, show that you have this product and that one, you’re trying this other thing. You could feel it was more to fill Excel sheets, to have all these things, than for actual need from outside for the product.
So this was quite painful for me because as a developer you do things, you see that ten people use them and you say “yeah, cool,” but the satisfaction is low.
Giuseppe Silletti: Do you remember a specific episode from this experience?
Tech Lead: Well, specific episodes, no - it was more a growing list of various things where the product manager kept saying “we’re looking at this other functionality,” but we looked at the KPIs and said, “no one used it,” so we started developing kind of a cathedral in the desert. But from there, there was a lot of pressure from VCs, because it was all based on round after round after round, to put things out. Maybe a lot of accidental complexity that didn’t make sense, but in the end no one used it.
Giuseppe Silletti: Can you recall a feature in particular, how it went from the beginning to the end, how you organized it at the beginning, how it went to development, until the release?
Tech Lead: It’s been quite a while and many experiences, let me think… At the beginning the product was very verticalized on our needs, then it was opened for agencies’ needs, but then the agencies didn’t use it. For example, we had developed the whole phase where you go and insert your listing, you create it with the whole quality level, because it has to be a quality listing, with precise information, the listings also had to be approved, certain types of photos, etc.
But then going forward we realized that agencies didn’t have any desire to create listings with this level of quality. They use their property management systems, where they throw in information in a fairly raw way, often. And then they press a button because they have integrations and they throw all this stuff onto various sites - real estate portals, etc.
So in the end we also had to integrate with these portals. So in the end a good part of the listings, actually most of them, let’s say almost all, came from these flows and not from the whole nice wizard flow we had created.
Again, initially it was created because it was also for the company’s properties that they were reselling, etc., but even there this whole nice flow remained, with all our quality controls. Then when we had to integrate these flows, since the data is often poorly structured, etc., we had to just open everything up - do whatever you want, otherwise we’d have no listings. So the metric was no longer based on quality, not effectiveness of listings, but on having X number of listings on the site every month.
So this metric switch then made part of what we had imagined before fall apart.
Giuseppe Silletti: In your experience, do you remember a time when you identified a problem or opportunity on the product side, but didn’t know how to communicate it to stakeholders?
Tech Lead: Not knowing how to communicate it? No, in the sense that generally I’ve always been fairly… Because fortunately having often worked in product companies, I’ve always been quite accustomed to going directly to product or someone on the business side to push forward an idea. Then there have been cases where maybe at that point I wasn’t listened to.
I remember a home laundry startup which was a micro startup, there wasn’t even really a startup anymore when I arrived, it was me and the CTO developing. The CTO is my friend who I worked with at a travel booking company. They received an investment, I was fed up with the travel company and I said if you pay me X per month I’ll come to you and we’ll push this project forward.
And there the big difficulty was logistics. The startup does home laundry basically, so you need to wash your shirt, jeans, etc. They come, pick them up at your home, their workers wash and iron everything, and bring it back to you.
So there’s the huge complexity of last mile delivery, because that, also for margin reasons, is managed internally with drivers, freelancers who do this service. But managing the capacity of your logistics service is quite complicated, because maybe one evening you have peaks and you say “ok, what are the bottlenecks in our system?”
Normally on the laboratory side, etc., it’s quite predictable, because you know how many people in the laboratory for ironing, bagging, etc., how many items you can do per hour, so with that we made a nice little system.
On logistics it’s more complicated, because you can average how many delivery services you can do, but it depends. If there’s one here, one there, if there’s traffic, etc. And so we had started first by essentially continuously simulating routes, but it was quite complicated.
So in the end the idea that came to me was to divide the city into zones and then count services as if they were a weighted average. So if the service falls in a zone where you already have other services, its weight is smaller. If instead it goes in a zone where you don’t have any around, it weighs more.
But this thing, for example, “ah yes, nice, but we don’t have time to develop it now.” We were so few people that rather than that, in the evening the founders would go out to make deliveries if there weren’t enough drivers. That was the story.
Giuseppe Silletti: How did you propose this idea? How did it go?
Tech Lead: It was a company where in the office we were five people, the office was basically a loft in the Navigli area that we had rented and so it was in front of a coffee while chatting. The night before there had been chaos, this idea came to me, I had drawn it, so it was extremely startup, let’s say garage style.
In other contexts maybe I had to do this type of activity a bit less because you always had maybe a product manager to whom you propose the idea and maybe they cultivate it a bit more.
Now thinking of examples, but certainly at the travel booking company it happened several times. I worked on the pricing part, rules engine for flight prices, and every so often cases emerged that weren’t handled correctly, but let’s say they were on the business side, things that even business hadn’t thought about - rules that had the same weight and they didn’t know how to choose them, so they were a bit less easy to tell.
Giuseppe Silletti: In these experiences where you had to propose an idea or present it, in those discussions, in those moments, what was the biggest challenge for you?
Tech Lead: Let’s say it depends a lot on the contexts. There are contexts where the tech figure is understood - at my current company it’s understood that actually it’s a figure that’s not just a developer, so they also have a business vision, bring ideas. At my current company this thing exists a lot, precisely because we try to blur the boundaries as much as possible.
So we even in the daily stand-up, it happens that a business problem comes up and we solve it with our ideas, as product developers.
In other contexts, I remember for example at a luxury fashion brand, when I joined and we were analyzing a whole flow to basically make a new experimental e-commerce, which had a logistical flow that was very different from what they did on traditional e-commerce.
In the US, you order something, a massive transfer of material is made from Switzerland to the US warehouse, and when you buy, you buy from the US.
Instead, since these were few products, vintage stuff and that kind of thing, we had to do real international shipping, so the products all leave from Milan, let’s say, but they have to go all over the world with all the complexities, etc.
When I joined that company, since we had a manager there who really believed in the product developer figure, let’s say, they worked a lot in the style of ES, the one from Larman, etc. So they really believed in saying, the developer is not just the one who writes code, but is the one who follows product development.
Then the code is sometimes actually product development. So me and other colleagues were thrown into meetings where we actually had to define the logistical and financial flow of certain things. And at the beginning, more traditional managerial figures, outside of the digital division, said “but what are you doing?”
“No, we’re developers.” “Excuse me, don’t you have someone who follows logistics?” “Yes, yes, we’ve already talked to them.” But even there actually, I mean in the end they changed their minds, also because we had our connections, but at the beginning there was a bit of this vision, like “but you’re tech, why are you talking to me about how this stuff is taxed, if we do this route or that one?”
Giuseppe Silletti: Can you describe a success story, where you started and then succeeded?
Tech Lead: In the end we succeeded, with the product team, which was this function, so we had developers, there was also someone who acted as an analyst, then we had figures within digital who followed more the logistics part, etc., to create this new logistical delivery model and actually make it work.
We also did the selection of the partner who did the shipping part, etc., who also followed for us the whole customs clearance part, all these things, and so in the end we succeeded.
But initially, in some meetings, you’d talk with the general manager of the US part, and they’d say “yes, but what are you guys doing?”
So, I mean, how would it turn out? I really like this precisely because it was actually a team success - a cross-functional team that managed to create from scratch basically a new logistical flow that also served the company to understand, since they ultimately wanted to switch to that model in general, where the complexities were. It was a bit of an experimental point.