Partial Interview Transcript (Anonymised)
Giuseppe Silletti: Yeah, so in your experience as a head of engineering director, what are the common ways that you found in which organizations make product decisions and how they are communicated to engineers?
Director: The way that I see it, I think it depends on the organization and a lot of level of maturity and certain choices. The most common way is you have all decisions being made on leadership level by the product team and the product team hands a list of tickets to do for the engineering. This is the most common way, but as we know, there’s a lot of reasons why this is ineffective and leads to back and forth. Now, in terms of when you get to a more mature organization or if you have a more mature organization, the problems to be solved come very much from bottom-up as in from the team, but then this requires that the team has contact with users and it requires that the team has an understanding of the business, quite good understanding of the business to be able to provide ideas to solve. And in a scenario like this, the leadership of the team and the leadership of the company provide the strategic direction while the team basically provides what problems we solve to get there. I think in reality, a lot of companies are a little bit somewhere along the line between these two, between what I described. And getting to the second one is hard because it requires investment, like I said, in people with specific mindset. And this mindset is… Usually curiosity beyond just technical tools, because technical tools are just a way to solving business problems and they’re not the goal per se. And it also requires maturity from the organization to understand that there’s benefits in doing this, but also it requires that the company is available to spend money. It’s working for us, because getting people that want to think about the product and know how to think about the product costs money. It’s not cheap. You will not get someone for 50,000 a year to do this, or you would need to be very, very lucky. So you need to get a different kind of salary budget for people. In my own experience, what I’ve done is kept, let’s say, instead of trying to get a larger budget, what I said and what I’ve agreed is we have this budget. And instead of having 20 people, we have, say, 15 people, but we have 15 people with a considerable, the higher number of, say, more experienced people and higher number of people that can do this. And with this, let’s say, we are basically spending the same money in people, we just have less, but naturally things, the speed or pace at which you can do things, once you have a team working in an effective way, it’s obvious for anyone from the outside, and then they see that the effort pays off or the money pays off. Now, there is one thing, which is the, I think the mindset… It’s very much about curiosity, but the knowledge of the product itself is very specific to the industry and very specific to the company. And that is something that you cannot train from the outside. I think the only thing you can train is this curiosity and the need to speak with users and actually a lot of product related stuff that’s in working in small iterations and stuff like that. This you can train. Specific product knowledge you won’t be able to train.
Giuseppe Silletti: It makes sense. And where did you see the biggest misalignment between product and engineering usually?
Director: When you have engineers basically just being given a list of stuff to do or a list of tasks to do, it’s very common to get to a situation where the product team feels that, oh, our strategy is perfect, our plan is perfect, but the engineering team is just not delivering. And then on the other side, the engineers feel that they are being asked to do stupid stuff or being asked to do very complex stuff with very tight deadlines and they need to compromise on quality. So this is the most common thing I’ve seen and the most common pattern I’ve seen is the distance between product and engineering, leading to this lack of trust. It’s kind of one of the five dysfunctions of the team, see it very much between product engineering, which is lack of trust.
Giuseppe Silletti: Okay, makes sense. Why do you think it goes like that in the first place?
Director: Why does it go like that in the first place? Because building a plan independently of you being able to achieve it or not makes people feel good. It’s like starting something. When you start something else, it makes you feel good. Having the presence of mind to understand that starting small and bringing small and validating small brings better results is not easy. I think it also comes from the fact that it’s very common for us in general in tech to think that we know what the users want without talking to them. So when we know what we want, why are we talking with the users? We should just go and build it. And this is very, very common. I’ve seen this very, which I feel it’s, arrogance might not be the best word, but I think this is one of the patterns, which is we think we know what users want and we just go and do it.
Giuseppe Silletti: Right. Okay. And so as you have a, regarding this last thing you said, have you ever experienced a situation where you had the engineers pushing back on product specifications, some of their different point of view, different ideas, not much on the technical side, but on the product side? And if so, how did they go?
Director: In my perspective and what I’ve seen and what I’ve pushed for is instead of pushing back on product specifications, actually push back on actually creating those specifications in the first place. You don’t need to create specifications, you need to be able to decide what’s the smallest problem that you can solve and actually go for it. And what you need to do is convince the product team that working like that has some benefits. And if you can convince them to run an experiment, run a test, let’s say, let’s work like this for a couple of weeks or for a month, and let’s figure out what is the tiniest, smallest thing we can do for this, the tiniest, smallest problem that we can solve, and let’s solve it. And instead of you trying to specify everything, let’s just say this is the problem, and let’s go now together and figure out how to do it. Let’s run a user story mapping or something, let’s figure out how to do it instead of you trying to come up with all the edge cases and so on, that makes no sense. So this is my perspective, how this problem should be solved. Because going in infinite conversations around all this product definition is wrong. The difference is product definition is too big or too small. I think it’s a waste of time and it’s like discussing the size of a pull request, which is kind of, in the end, it’s kind of pointless, which you should be discussing is why do you need pull requests in the first place. Right.
Giuseppe Silletti: So you’re saying it’s more about kind of trying to negotiate the scope to make it less risky to build stuff.
Director: Not just the scope is what is the first step. What is the first step? And I’m convinced and actually explain to people or try to bring to people that we can always test this with a smaller set of users and see how they react. If they react wrong, we can adapt faster if we just do a small thing compared to doing a big one.
Giuseppe Silletti: Yeah. Yep. Yep. Makes sense. And do you personally like to… Do you encourage engineers to think like that?
Director: Yes, I do that. That’s my expectations with engineers every time I work with them. It’s part of the hiring process, it’s also part of the roles and expectations of the job, the different levels in the career ladder. This is part of it.
Giuseppe Silletti: Okay, and what do you try to do in practice to help them?
Director: Encourage people to talk and to actually ask to be part of, I want to be part of a customer call. I want to be part of a call with sales, I want to be part of a call with this person. Always ask, why are we trying to define, let’s say, why are you trying to build a huge Figma design for I don’t know how many pages, if we haven’t even determined if this is going to be a good idea or not to do, why are you spending time doing this? Let’s first figure out what is the smallest thing, and instead of trying to build a huge thing in Figma, trying to build a huge thing in I don’t know where, let’s look at the smaller thing, because if not, this is all a waste of time. You’re building a page in Figma for three weeks, or for a month, by a designer working in isolation, and then I look at it and say, this is impossible to do, or why are we doing this in the first place, what problem, is this really the smallest problem we can solve? And I think that’s one of the biggest questions that engineers should always keep asking is, is this the smallest problem we can solve, or what is the smallest problem we can solve?
Giuseppe Silletti: That’s maybe the most important mindset shift that engineers should have.
Director: And this comes in hand with something we need to do on our side, which is we need to be able to feel confident to deploy anytime and not deploy just, oh, it’s Friday, I don’t want to deploy. We need to be able to feel confident that we can deploy anytime, anywhere, and we need to feel confident that we can deploy to, and if needed, we can test with one customer or with a bunch of customers without causing issues to others. We need to be able to test the new functionality without impacting the rest. So we need to feel confident that we can do all these things. If we’re not confident that we can do these things, all our conversations with product in terms of changing ways of working will go nowhere because then it, they will be blocked by not having the ability to change something or bring something to production under a feature flag.
Giuseppe Silletti: Interesting. That makes sense. And so getting a bit on the hiring side, what signal do you look for that an engineer is product-minded? What characteristics?
Director: I actually asked for examples of situations where the person actually had an impact on a product decision. I asked this as part of the cultural fit interview. And actually, this is one of the questions that people usually need to respond when they apply to the job in a text format. So this is one of the questions. And the other is doing the coding interview. I look for someone that is looking to solve the problem. One, in the simplest way possible, and two, try to speak his mind frequently, and ask questions frequently. If someone is very quiet and not open to ask questions, or not open to change his mind even, this will not work.
Giuseppe Silletti: Makes sense. And would you be able to quantify the cost of this misalignment between product and engineering? Like, if it was solved somehow, how much could we save in terms of time?
Director: It’s really hard to quantify, but I think the only thing that what you need to do is you need to select a few metrics and show to the rest of the organization that these metrics improve along the way. One of the metrics from a customer perspective or from a product perspective, this could be something like user adoption or even the NPS. But this is something that we can only influence up to a certain degree. So there are other metrics more related that we can and should influence. So things related with how long do we usually take to do work. For example, our average cycle time. Expectation is that these numbers go down. Our average cycle time is going up. This means we’re doing something wrong. And also the ratio between the planned work versus unplanned work, and support requests versus support work versus user stories and so on should be consistently low. Our support work and our number of bugs and our, let’s say, MTTR and so on keeps going up, we’re doing something wrong. We should show that consistently this goes down. Actually, this is part of what I agreed with the CEO of the company here, which is like we agreed on a certain metrics and we agreed to keep looking into it month by month. And this is what is going to show from a quantitative perspective if the team is improving or not. Of course, this is not the only way. There will be other things like how does the rest of the company feel about engineering? How do the engineers feel? Do people feel motivated and so on? But this from a quantitative perspective is something that we can do.
Giuseppe Silletti: Okay, that’s cool. So I will just move a second to the training. Same part, just to get a bit of your feedback on the idea. So first of all, would you consider, as a head of engineering, suggesting this training to the engineering department, something like this to help them get better?
Director: I would do it myself. Or I would hire people that have experience in doing this, so that they could help me do that.