Gediminas Brencius: Driving Better Product Development in Teams

And here at Nord Security, we have experts who know how to quickly and efficiently build advanced cybersecurity solutions used by millions of users. In this interview, Gediminas Brencius, Head of Product for NordPass, an advanced password management tool, shares how changing their team management methods helped drive their product development to the next level.

The growing team

First things first, could you introduce your role at Nord Security and your team's focus?

I am Gediminas, and I am the Head of Product for NordPass, a trusted password manager for safely storing credentials and eliminating password stress. With our team of experts, we build a simpler, faster, and safer tool for everyone to feel at ease when browsing online.

With your team growing, what challenges do you face in product development and general day-to-day tasks?

I think that the challenges we face are similar to every team responsible for developing products. Our primary focus is to deliver the best possible experience for our customers. However, new projects, shifting priorities, and emerging opportunities definitely take a toll on team performance. Our main mission is to ensure that our customers feel safe and secure. That takes immense effort. Therefore, last year we doubled our product team in numbers. The sudden growth came with challenges. Unfortunately, having more people doesn't guarantee faster delivery. That's why we started looking for ways to improve the team's efficiency.

Level up your online security

Store and manage your digital valuables safely

Start Free Trial

Squads and guilds vs. silos

We know that your team operates uniquely - could you explain squads and guilds. How do they work?

Of course. Squads are the smallest, fully cross-functional units of the team. They can deliver solutions from start to finish. One of the main things we wanted to achieve was giving the squads autonomy to choose how they want to solve problems. Since their teams are small, they're much easier to manage. We created them for quick scalability and performance. In a way, they're like a strike team of product development. Once the decision to expand is in place, we know that we'll be able to get it done much quicker by forming a squad. The Product Owners are like squad generals: they're responsible for managing the members and defining their priorities along with the focus areas.

Guilds, on the other hand, are groups of people within a single area of expertise. These units share knowledge and point the direction for technological advancement. Guild Leads are the key people of guilds. They define the technical direction, act as mentors to others, participate in hiring and onboarding new guild members.

Inspiration behind the change

Why did you choose this model, and how does this impact your results regarding the product development process?

With the rapid growth of the team, we were facing a lot of challenges accommodating various stakeholders. There were issues with timely request management, especially when working with high-velocity areas like marketing. Following the original structure, we worked in silos, where specific tasks would get stuck with one team and then move on to the next, and so on. It was hindering the growth period, and changes were in order. We chose this model because it allowed us to break up the department silos and enable smaller teams to deliver results efficiently. Using this model gives us the ability to plan better, account for unexpected changes, and provide a more unified experience for our customers and stakeholders.

How did you come about this work model, and what inspired you to try it?

The initial inspiration was the infamous Spotify model. They were probably the first tech team to implement it. However, this was seven years ago, and now they've probably moved on to something else entirely. We were considering this for a while and read many articles that listed this particular system's flaws. The risk was there. And that's why we adjusted Spotify's model to suit our needs better. At the time of their article, Spotify had three thousand members in their product team, so the scope of challenges wasn't the same for them. Also, we picked a couple of pointers from another great company - Basecamp. They use the “Shape Up” principle and have a team size that is somewhat similar to ours. So it made sense to apply some of their methods.

This type of organizational management was and still is an experiment. We picked it because of specific problems. It's far from perfect. You can introduce a new model to people but changing their habits takes some time. Nonetheless, at this time, we can say that it's working for us.

Challenges and outcomes

What are your desired outcomes for this team formation, and how do you think you're progressing towards it?

As I've mentioned before, our primary focus right now is making the squads autonomous. But together with autonomy, they should also be aligned with the general product vision. Squads need to deliver solutions from start to finish, have their say in tackling problems, and make quick releases. Essentially, we want to give ownership to squads, let them learn, and deliver a great product to customers. However, it's still in progress.

There's room for improvement, but I think we're moving in the right direction. Our people are doing their best while we introduce processes to help with the change. It's not exactly a cakewalk, but nothing worth having comes easily.

Have you had any issues with it regarding the product development process? Did you make tweaks from your initial idea?

Absolutely! The first challenge came during the first lockdown - our communication models had to change since we started working remotely. Information wasn't getting through as clearly. We're still working on finding the best ways to keep everyone aligned and within the product vision.

Other tweaks include the responsibilities of squads and guilds, feedback on the team. Thankfully, the hardest part is in the past. The initial change was a bit rocky since we worked with other Nord Security teams, and they had to adjust as well. However, I believe that we're moving in the right direction.

Would you recommend other product development teams to follow this model and why?

Yes and no. Changing your workflow is necessary only if it solves a problem in your team. Be it the lack of efficiency or hitting the local maximum, having a reason is the most important thing. The model we're using is customized to our needs and might not work for others. But if teams have issues that are no longer solved by incremental change - reorganizing the whole operation is a viable option. You have to put in the work to make it feasible.

You can find the original blog post here at Nord Security.