Interview Transcript (Anonymized)
Giuseppe Silletti: What’s your role at the moment and what are your responsibilities?
Senior Engineer: I’m currently a senior software engineer at an e-commerce retailer. It’s an online e-commerce platform. Well, we have physical stores as well, but I work only on the online shop side of things.
I work particularly on the team called Checkout, which is basically responsible for orchestrating the whole checkout workflow of various goods. So essentially anything from the moment you have your basket, click checkout, and all the way to that order being placed and processed. That’s the set of services that I work with.
Giuseppe Silletti: Can you tell me the last time you had a conflict between the business or the tech team regarding the development of a new feature?
Senior Engineer: I’m currently working on a piece of work which does have some tension between tech and business aspects. We need to migrate a whole bunch of customers - well, all of our customers really - from one login system to a new one. We’re basically moving it from a monolith architecture to a brand new service so that login can be its own microservice.
There are a lot of things in this piece of work that if we focus just purely on the tech side of things, you can probably make things easier, but it will not be great for user experience. So from a product perspective, it would be a bit more difficult.
Basically, one of the easiest ways you can imagine to shift a person from one login system to another is to do a forced password reset. Let’s say you ask everybody, all of your customers, to suddenly switch passwords. This would be the ideal case for us as tech people, because it’s very, very easy - you just ask everybody to reset, and suddenly their user information, login information, gets stored in a brand new database.
But from a user experience point of view, imagine you’re a customer and you want to just buy something. You are hit with this barrier, which is going to set you back, I don’t know, it can be anything from 10 to 15 minutes. It doesn’t sound like a lot, but it’s certainly a consideration for people, because why spend the extra effort doing this right at the moment where you want to purchase something? It interrupts your flow, adds a lot of friction.
This is why we’re trying to find some sort of middle ground, which makes things easier for our users, essentially.
Giuseppe Silletti: What was the challenge here in the collaboration between the business and the tech side?
Senior Engineer: To be honest, in my team in particular, I think a lot of us are very product-minded to some extent. So we quickly recognized that there’s a huge potential to have a better user experience than just forcing people to reset.
I think from that point of view, it’s really a collaboration where we just talk regularly with our product people, and we’re just trying to come up with a strategy which is acceptable to both sides, essentially.
We did come up with a middle ground, which is essentially: use the login flow or the existing change password flow where once a customer logs in with valid credentials, you just save them on the new system, and from there it’s as if they did nothing. The user does not need to do anything, no mandatory actions on their part. And from our side, it’s just taking on a little bit of extra effort to implement this.
So I think there’s often this trade-off where if you want to improve the user experience in a piece of work like this, you do need to spend a little bit more time coding the logic to facilitate this user experience.
Giuseppe Silletti: Let’s start at the beginning of this. What happened first? How did you kick off this new feature with the product or business team?
Senior Engineer: It’s more of a high-level business priority to move away from an old monolith architecture. This transition has been going for at least a couple of years now, where all the functionality in this old monolith is being created in a brand new microservice architecture. And this is the very last piece of this transition, where we want to shift all of our customer logins into a new system.
From there, it’s been maybe a couple of months of basically discovery work, talking to multiple different teams to see what the requirements are. Talking to business people to see what sort of business priorities in terms of deadlines we have and the user experience considerations that I mentioned.
Giuseppe Silletti: What challenges did you encounter during these two months of discovery, if any?
Senior Engineer: I think in a lot of these cases, especially in larger organizations, the biggest challenge is often coming to some sort of consensus.
This whole strategy that I mentioned, we’re still not 100% certain that’s going to be the case. In large organizations, you have a lot of meetings where you try to come up with some sort of outcome. And a lot of different people bring their own perspective into this. And it’s very hard to reach consensus sometimes.
So that’s certainly been a challenge. I really think in a lot of these pieces of work, the biggest challenges are not really the tech side of things. It’s more what the workflow for coming to an agreement is. And if you constantly bring more and more people in, that slows things down significantly.
It’s often the case that organizations don’t give one particular team autonomy to make all the decisions they want. And I think that’s certainly been a challenge with us because I do believe from a tech perspective, we can probably do a prototype in, I don’t know, let’s say two to three weeks. We have smart developers that can probably easily do a lot of the tech side of things fairly quickly.
Giuseppe Silletti: How did you and your team try to overcome this challenge?
Senior Engineer: We try to make the argument in front of other people that are not particularly involved in the work, that there are a lot of costs to prolonging this. There are hidden costs, which I think are often unseen. And I think that’s the case with a lot of different features.
As I mentioned, this is a monolith system that we’re porting from. There are licensing costs, there are costs for maintaining it, there are the opportunity costs for doing more things with a brand new system.
For example, this old system is also managed by a third party, a large consultancy company. In a situation like this, it’s good to decouple these things as fast as you can, especially when you want to provide a first-class user experience.
There are limitations to the old platform. It’s not the most secure. Certainly, the new one has a bit more functionality around multi-factor authentication, for example, or passkeys. All these things are a factor which can have an immense impact on the organization.
So we try to come up with all these arguments to nudge things forward. And I think one of the biggest points here is we need to communicate these things to people who are not close to either the tech side or the business side.
For example, staff engineers - they’re often not familiar with the intricate details of the user experience. Whereas product people, they may not be familiar with the tech side of things. They may think that something is going to take three months, where in reality it can probably take one month if decisions just are done a bit faster.
So we try to present all of these different perspectives based on the audience that we have in a certain meeting.
Giuseppe Silletti: In this specific experience that you had, developing this feature you were talking about, once you explained this user experience to business, what happened next?
Senior Engineer: We’re still kind of in the middle of it, to be honest. We are trying to move things faster, essentially.
Right now we’re at the stage where we’re trying to involve more senior managers into this whole decision, up to a director level, so we’re escalating the chain of command, basically. I am of the opinion that we should go up that chain as soon as we can, just because if we’re going to end up needing a decision from someone more senior, it’s great if we can get to that point as fast as possible.
Right now, I think there’s a few outstanding meetings where we’re going to present all of these different options to someone at a director level so that we can get a decision soon. So things have started to pick up pace.
On our end, we’ve started doing POCs of how we can do the various different options. We have a brand new microservice which we’ll be able to connect to both systems. And eventually, we want to have a state where we can easily shift between the two different systems.
Hopefully, by the time we get a decision, we’re going to have all of this up and running so that we can implement a very simple routing logic inside of this. Basically, we’re preempting the work that we’re going to have to do. We’re setting up the groundwork, we’re abstracting all the bits that we don’t know about, implementing the bits that we do know that we’re going to need, and as soon as we get that decision, we’re going to be able to implement the logic that we agree is going to be the best migration strategy.
Giuseppe Silletti: Can you think of a case where you had an idea or opportunity in mind, but you found it difficult to communicate the benefits?
Senior Engineer: Something that I noticed in a previous job - it was kind of a startup/scale-up company, less than 100 people. A company of that size needs to experiment a lot. People from different teams were running their own experiments in terms of presenting different ideas to customers, different pilots, different offers, but all of that was very manual and there was no way of tracking progress within the business of what exactly works and what doesn’t.
The opportunity that I spotted there was to create a tool, an internal tool, so that people from the various business departments can track the success of their pilots. Do they want to increase signups? How is their experiment affecting those signups?
What I created was - because we had a hackathon - I created a platform where they could basically log their experiments as pilots. They could choose one of a few different types of pilots, and then they can track results there, essentially. They could query the database - well, there were a few very simple queries to allow them to track the success of their pilots. They could basically select a cohort of customers who they’re using as part of their testing pool, and they can track metrics related to those customers.
Giuseppe Silletti: Did you have any difficulties in communicating to the product or business stakeholders?
Senior Engineer: It’s certainly difficult sometimes because you do have to convince people to see the value. And I think with a tool like the one that I described, what I was relying on is basically the ability to have a very consistent workflow of doing things.
Because a lot of those pilots, the way it usually worked was people would basically create brittle spreadsheets where they log a bunch of stuff. And it’s really the time-saving aspect and the consistency aspect that you need to communicate.
There’s a lot of different ways to communicate this. And that was sometimes difficult, especially I was much more junior then. And I was basically giving all of the tech-y arguments, and I had to make this shift to thinking of what’s the benefit for them.
Are they going to save time? Is their job going to be made easier? And that’s the thing that I was trying to communicate, essentially. It helped them do their job faster and easier.