Interview with Andrew Gomes, Project Manager at Paradox Interactive

‍Mateusz Radomiński: 

Hi everyone, I'm here with Andrew Gomes, who is a Project Manager at Paradox Interactive and today we are going to talk about building and leading development teams. Andrew, could you tell me more about your role at Paradox Interactive? 

‍

Andrew Gomes:

Well, so I'm a project manager at Paradox, and I know that's a very broad title. That means a lot of different things in a lot of different places. But in my context, what that means is that I'm working with our development teams to ensure that the processes and delivery expectations are all aligned and realistic and healthy. And to that extent, it varies between the teams, sometimes I operate as a scrum master, sometimes it's much more than what people would consider traditional project manager capacity. Looking at timelines and roadmaps. 

‍

Mateusz Radomiński: 

Got it. And how about structuring the teams that work on the projects? What’s your approach towards that? 

‍

Andrew Gomes: 

Typically, we use scrum format. I would say in general, we tend to add a side of agile development practices. We find that for our teams that are working on live services and products. Scrum can work quite well. Of course, there are other teams that may be more interested in Kanban or Scrumban, but it really is something that we try to coach and develop with the teams themselves rather than putting a top-down way of working on them.

‍

Mateusz Radomiński: 

Alright, and are you able to define a “typical team” or do you adjust the teams structure depending on the project they're working on?

‍

Andrew Gomes: 

It's a bit of both. There are a few core things to every team. There's we typically have someone in a position of technical leadership, someone in a position of process leadership and then someone in a position of product leadership. But beyond that, how we how we structure the team around those three pillars can vary quite a bit, depending on what the team is trying to accomplish. 

‍

Mateusz Radomiński: 

And if you had to point out one thing that, in your opinion, is crucial when it comes to structuring an effective team, what would that be? 

‍

Andrew Gomes: 

I think probably one of the biggest things to have an effective team is making sure that you have informed buy in from everyone who's participating in that structure. Processes don't work very well when they are being forced on people, when that just creates an environment where people view a process as something that is in the way of their own creativity and their own freedom and autonomy to complete their work. What's really helpful is when people are educated on why the process is there, what it's meant to help facilitate and are given the opportunity to see it actually fulfilling those needs as part of onboarding to the team or onboarding to the processes.

‍

Mateusz Radomiński: 

Got it. And could you tell me a bit more about working with external partners? Like how do you find yourself in working with people who are outside of Paradox and how is it different?

‍

Andrew Gomes: 

So I would say, luckily, I mean, in this day and age, we have so much remote capacity that and especially after the pandemic, it's just become kind of a common way of working that it doesn't feel particularly strange to be in that position. Working with teams that are based in a different city entirely. I think one of the challenges that does arise, though, from any sort of purely remote setup is that it is that much harder to build deeper emotional trust that you typically want to find in a team. I think a lot of folks take for granted just how important it is to having a happy and productive workspace, but you really do need to feel that you can rely on the people who are working with you, that they're not just a face on the other side of the internet who has no sense of consequence to you. So I think that's probably the biggest challenge. But at the same time, this isn't a unique challenge to remote teams, remote setups, at least not anymore.

‍

Mateusz Radomiński: 

So building relationships, trust and ownership are crucial here.

‍

Andrew Gomes: 

Definitely. I think there's a lot of fear that people feel around just how easily they, just how easily they suspect other people can detach from the team and that that creates a suspicion that everything is going to pile up on them. On this one person. So it's really important for remote teams and especially teams that are working in this sort of agency and client relationship to develop this sense of being on the same page, being in it together and having a shared sense of of ownership and contributions so that it minimizes this fear of this fear that someone is just going to bail and leave the project hanging.

‍

Mateusz Radomiński: 

Yeah, I understand that. And let’s get back for a while to the process of composing the team. What are the key things that you look for when you build the team like, are there any specific character features that you look for in people?

‍

Andrew Gomes: 

I would say an interest in process for me personally is something that's really helpful. So that doesn't necessarily mean that the person has to be an expert at any process in particular or that they have even necessarily need to have had good experiences in the past. But a willingness to try to understand why another group does things a different way, I think is vital to being able to to join a team and integrate with the best practices that typically have evolved for good reason. Now that's not to say that all best practices and all processes should be reviewed and changed on a regular basis as needed. But it's rare that a process is in place just because it's usually developed over time to solve some sort of problem. And it's it's really important that when you come into a space that you try to understand what those problems were and have they been solved or are they still present? Is the process something that is actively helping? Or is it something that maybe the team has moved past and it's time for a change? But those are all questions that I think are really helpful to be ready to address.

‍

Mateusz Radomiński:

Alright, so kind of a curiosity about the process and understanding why some things happen in a certain way and questioning if that’s still the best way to work. And since the Brainhub team works on the Paradox project, could you tell me how to they fit in that criteria?

‍

Andrew Gomes: 

Yeah, so the the team has been with us, actually, they've been working with us longer than I've been working with that team in particular. They've actually been around for a lot of these changes. So they've seen processes evolve over time and then relatively recently brought on some new people. And one of the things that really facilitated that transition was that they understood what the product was, that they were joining because, of course, their colleagues had already been working on it previously, but they also had a pretty good sense that processes from our perspective, from our client perspective. Our processes were not necessarily set in stone. What was of most interest to us was that the team was ready to come in and contribute and essentially function just like in-house developers would and take the same level of ownership and input over the way they work. And I think it was very clear to us that the guys who joined the team were ready to have those kinds of conversations and ready to provide that kind of participation and input, as well as just being great developers.

‍

Mateusz Radomiński: 

Awesome, it's nice to hear that. And now, I’ll get back to the curiosity you mentioned before. That’s one of the soft skills that you look for in people. Are there any others that you consider crucial and how do you balance them with the hard skills? 

‍

Andrew Gomes:

So I mean, I think hard skills are always a pretty straightforward thing.There's certain languages that you would need to know certain ways of working that are just kind of fundamental to building the product, but the soft skills that really come up are really about. Things like expectation management and having the the confidence to engage with unclear questions. I know it can definitely be a challenge when when the developers are given a set of requirements, but the person given the requirements may not fully understand the issues that stand in the way. So it is vital that the developers feel that they are in a position that they can say: well, wait a minute, we need to have a deeper conversation on this. Because the alternative is that they either risk making something incorrectly and not meeting the actual requirement or they stress themselves out and things kind of grind to a halt because there's just too many unknowns. So I think the soft skill of engagement is really, really important. Especially in the context of having treating the development team as it's an internal team. It's really important that the developers take this perspective of contributing their minds as developers, not just as fingers on a keyboard.

‍

Mateusz Radomiński: So we're talking about kind of open communication, like if I don't understand something, I dig deeper and even over communicate that so I don't make the mistakes. And how do you look for these things during the recruitment process? If you see that, for example, somebody is pretty good when it comes to technical skills but has some troubles with the soft skills, how do you approach such a candidate?

‍

Andrew Gomes: 

So when it's a situation like that, the most important thing is that we see that the person is interested in learning that they recognize that that may be a weakness, but that they're also interested in growing in that space. And I know that sounds kind of like a fluffy answer that of course, people want to do that, but it does happen a fair bit. You come across people who are just not interested in developing that aspect of being a developer. So it is something that is worth showing a demonstrating.

‍

Mateusz Radomiński: 

Got it. Now, could you tell me more about your dev teams? Are they cross-functional or fully specialized? What does it look like at Paradox?

‍

Andrew Gomes:

Well, I wouldn't say there's necessarily specialized, but they're focused. They are certainly cross functional in sort of the the most technical sense of that and that they are solving multiple issues on oftentimes different tech stacks. But we also try to help compartmentalize teams to a point that they can really focus in on one or two tech stacks. They're not being asked to reach across the entire spectrum of things that we're doing. And in that capacity, we try to make sure that there's easy points of communication across teams, but the teams themselves are able to really focus in and specialize the within the teams themselves. We try to avoid any sort of siloing. We like our development teams to generally be internally rather cross-functional. There might be some cases where we have both front-end developers and back-end developers working in one team. And then of course, in those cases, the work they do will generally be rather specific. But they are always working in parallel with regular communication and being part of the same processes so that everyone's on the same page and knows what the others are, even if they can't technically do the same work.

‍

Mateusz Radomiński: 

Ok, and in terms of the size, how big are Paradox teams? Do you follow any best practices?

‍

Andrew Gomes: 

So we generally follow the best practices prescribed by scrum in general, which really says like once you hit around the eight to 10 people range, you're getting pretty big and clunky. So our teams almost always tend to stay smaller than that. Anywhere from three to six people. It’s quite normal when occasionally teams get quite large, that's when we start to look at either splitting them or creating two specialized sub teams within the group. And that's always a more ad hoc conversation, there isn't a specific process for how that plays out because of course, when those things come up, it's typically a unique situation each time.

‍

Mateusz Radomiński: 

And how do you divide the workload between the teams, do you have any established processes?

‍

Andrew Gomes:

So dividing work between teams isn't really a top down system. Teams typically have a product owner, so requests will come in through that product owner rather than being distributed from one central place. Within the teams, the distribution of work is treated more as a conversation, so developers as a group commit to or accept a certain amount of work that they are going to do for whatever period of time they're functioning under, or whether it's a sprint or if they have more of a flowing system like combine, they have their work in progress limits. So the negotiation of who does what is treated much more as a an open discussion of: oh well, I have vacation for the last two days of the week, so I should not be taking on a job that's going to take five days, or maybe this person has more expertise in this topic, so maybe they're the right one to do this because we have to do it. We have to get it done as fast as possible. Alternatively, maybe this person wants to learn about a new topic. So they're going to take a task which maybe they're not so familiar with, but we can afford to take a bit longer on.

‍

Mateusz Radomiński: 

Nice, so kind of a conversation like what people are capable of doing and what they would like to learn. 

‍

Andrew Gomes: 

So like it's very much a pull system when it comes to developers taking on work. And of course, we try to remove any blockers that would prevent them from pulling things onto their plate. But I think they'd be the best work gets done by people who are engaged and want to actually do the work. So insofar as possible, a pull system is is preferred to a push system.

‍

Mateusz Radomiński: 

Awesome. Andrew, are there any tips that you'd like our listeners to take from this interview? 

‍

Andrew Gomes: 

Yeah, I'd say the biggest tip is just remembering that people do the best work when they're happy. They don't always show you when they're stressed, so it's really important to make sure you're maintaining an open dialogue with the people that you're working with to make sure that they are enjoying the work that they're doing and that they feel that they have the ability to speak when something just isn't clicking for them without the fear of reprisal, because you will get you will get much better work from folks who feel they can be engaged and invested in the work that they're doing, rather than that they have to just sit there and crank it out just for the sake of calling it done.

‍

Mateusz Radomiński: 

Nice. So, open communication in the first place to be sure that people enjoy the work. And the perfect sum up to finish this talk. Andrew, thank you for your time and all the tips that you provided, I hope that there are some people who’ll find this useful and hopefully one day we’ll have another talk. 

‍

Andrew Gomes:

Thank you Mateusz.

‍

Mateusz Radomiński:

Thanks Andrew. 

‍