Maria Gomez is the Director of Engineering for BCG Digital Ventures, a corporate investment and incubation firm that invents, builds, scales and invests in startups. Her role there is to work closely with stakeholders, coordinating their vision and strategies with the engineering team as they work to develop new organizations and endeavors.
Women Who Code’s Lead Software Engineer, Rachael Wright-Munn had a chance to sit down with Maria and ask her a few questions. The result was an incredible conversation between two brilliant and inspired leaders in the tech industry, with topics ranging from team building and development to corporate culture, diversity and inclusion, and the merits of microservice architecture. We hope you enjoy.
Note: BCG is a strategic consultant group. They own several, what they call “Alternative Business Models.” These are organizations with a more specific focus. Digital Ventures (DV) is a business that was founded and is owned by BCG. DV is the specific company where Maria is currently working as the Director of Engineering.
How are you enjoying DV so far?
It is really cool. I think that it has a lot of the things that I was looking for. I wanted to make a big change and jump into the realm of entrepreneurial pursuits, and explore that area more. And I also wanted to get more exposure to building a product from scratch, and that’s what DV does. We build ventures for corporations, and that is like building a new company or a new organization when you do that. So it is much more than technology and product management, which is a lot of what I did at Thoughtworks. This has a much wider scope in terms of economics, business, investments, and even recruitment.
That’s an impressively wide scope of duties. How do you balance them all?
As an Engineering Director, which is the role I have here at DV, I mostly stay fundamentally wearing my technology hats, so I generally focus on that part of the project. But I have to work very closely with all of the stakeholders. So the Product Director is something I was very used to before. But now I also need to work very closely with what we call “Venture Architects.” These are basically people who have very business mindsets. They talk about profit, they talk about what kind of investment they want to make here, and where are we going to find the return on those investments. So right now I am absorbing a lot of knowledge of all of these other things that I was not that familiar with before, while still contributing in my core skill, which is technology.
What is the culture like at Digital Ventures?
The Digital Ventures culture is not like a normal startup. Even though you are building ventures and you’re building startups, they still have a culture that is very friendly. Not that all startups are not friendly, of course. But DV has a very cool culture, it is focused on creating safe spaces, and on getting people to learn, and on growing, and on making an impact. So it is very focused on what are the goals, and what are the outputs, or the impact that you want to get out of those goals? How do you work? And it is also very people-centered. The people that work there are normally very curious in every department.
Curiosity is one of the main traits that we are looking for. And we also prefer people who are generalists, versus people who just have knowledge of one niche technology. So if you are very good at a particular technology in, for instance, the mobile space, such as a specific thing within iOS then this is probably not the place for you. But if you are a mobile developer that is happy to jump through different technologies and have an opinion on them, then this is the type of organization that can work for you.
What do you think is important for technology organizations, and even communities, to build these inclusive, safe spaces that support diversity?
I think it’s important to recognize that there is a bias and that we unconsciously apply the bias every day, every one of us. Once you get that realization then you can start looking at ways to mitigate that unconscious bias, and how you can create spaces that will allow people to grow and be more inclusive as time goes by. It is not like going from black to white or white to black, it is more like a journey and a progression.
To me, a place that is diverse and inclusive has safety, that’s very important. It has to understand that people have different opinions and that everyone should be respectful of those. And also be intolerant of people being disrespectful of something or someone. It is important to make a stand as a company and as an organization and take appropriate actions to allow that not to happen again. Those are things that I think organizations are getting better at, but there’s still a lot of work to be done in that respect.
There are a lot of people who talk about how you can get more diverse people in technology. But the truth is that unless you fix those spaces, you won’t get people into those workplaces. It doesn’t matter how many women or people of color you try to employ if they don’t feel safe going on an interview with your organization then you won’t get them to work there. So what I try to do is use my position of privilege - because I am a leader and a woman leader in technology - to try and help others and make the gateway to get to where I am easier, for women or people from underrepresented communities that come in after me. And hopefully, some find a way to overtake me.
What advice do you have for women who are struggling to be recognized in their current organizations?
That’s an interesting question because there is an easy answer and there is a difficult answer. The easy answer is if you don’t get the recognition that you need, or that you think you deserve, then quit that job and find a place where you can find that recognition. But that is a very simplistic answer because not everyone is in a position where they can just quit their job and be able to make a living while they find a different job.
So there are situations where you need to balance that, when leaving that organization is not an option, or is not an easy option. I think it is important, regardless of whether you can find another job or not, it is important to find allies within that organization. Someone who can advocate for you and for the work that you’re doing, and who can also help you make the impact that you are having more visible to the important people who need to see it.
A lot of the things that I have done in the past when I’ve been in situations where I want to grow in my career, make a jump, or whatever, is find more senior women that I can learn from, or that can help me, or advise me, or coach me. I’ve been very lucky that most of my career has been at Thoughtworks and more recently BCG where there are a good amount of senior women who believed in me and helped me in achieving my goals. And I have done the same with a few people as well. There are other organizations where you might not be as lucky to have senior women who can be role models for you, but you can find men or people of different backgrounds that can be a springboard to make that progress or get that recognition you are looking for.
You have a long history of building high performing software development teams. In your opinion, what are the keys to unlocking a team's potential?
Safety is super important. People need to feel safe. People need to feel like they can fail, and that’s okay. That doesn’t mean that they don’t need to feel responsible and accountable. That’s a different thing. But it’s important to say, ‘you failed, let’s talk about it and try not to make the same mistake again.’
I think building a good relationship with the people that work with you is super important. Team building exercises, being able to be vulnerable in front of your teammates I think is essential to gain trust and be not just in a safe environment but an environment of trust. Understand their strengths, and their areas where your teammates might not be that great, and also understand how you can compliment them, and how different people will have different strengths, and that can make a very awesome team.
You can’t know all of this at once. So you need to start somewhere. I normally start getting to know the people we’re working with, do some exercises, it helps to bond. You can do some kind of drawing exercises, where one of the team members tries to draw the eyes of the person next to them, and then you pass that paper around so the following person will try to draw the nose, and the mouth and the head and all of that stuff. So things that are fun, but which help you build trust and safety.
There are also tests that you can use, not personality tests, but they can help you to understand your strengths. Sharing that with the rest of the group is also very efficient to get to know the people a bit better. Things that can help you earn that respect. Also being able to understand the purpose of what you’re doing. What is the product that you're building, who are the customers, why are we building it? Being able to rationalize and articulate that is also fundamental to build those high-performance teams. It takes a lot of time. It’s not something that happens overnight.
But once you start building the trust, and cementing the team, that’s when you start getting really good and you get people who are motivated to work, and enjoy what they are doing.
How do you determine if a team is high performing or not?
It’s a difficult thing to say. I could give you the consultant answer which is ‘it depends.’ And it does depend. I don’t think there’s one unique sign or signal that you would look for. There will be things like, people are not talking to each other, or they start not showing up for certain meetings you might have or showing up late. Kind of losing track of their commitments.
If you go to a team space and everyone is wearing their headphones and not talking to one another all day, at the start, it might not mean anything, but it could develop into a lack of communication and the moment you start losing communication then that’s an early indication that a team is going to start losing performance because they don’t understand what the other person is doing, therefore they can’t support them or they cannot compliment them, or they cannot ask for help.
There’s something you can do when you do a Retrospective that is called a Safety Check. Retrospectives are these meetings where, as a group, you talk about the previous week or the previous two weeks. You talk about things you want to celebrate or recognize and things that could have been done differently, or what are the improvements you can make in the future. And you have a discussion. And then you kind of vote and decide the certain actions that can be done to improve the performance of the team or the relationship of the team.
Before starting a retrospective you can do a safety check. Basically, you hand over stickies to everyone on the team and ask them to number the sticky from one to five. And that number expresses how safe they feel about sharing their opinions. One can be I don’t feel safe. I don’t want to talk. Five is, I am super happy to talk a lot about anything. No concerns about my opinion being heard. A three can be, I’m okay with staying here, but I might keep some of my opinions to myself.
Once they have done that, then they fold the paper so that you can’t see the numbers, and they are anonymous. Then you can collect them and you can say what is the comfort level of your people. Normally on a team most people would be between a three and a five. Hopefully more towards the five than towards the three. But if you start getting a lot of ones and twos, or too many threes, that tells you that you have some problems.
As a facilitator, you can read through the votes and decide how to proceed. If there are a lot of low numbers, that means that the place isn’t safe right now. You should probably stop the retro. There are people in that room who don’t feel safe. You should stop there and have one on ones with every individual to try and understand more about why they feel that way. You might then take a different approach. And having those individual conversations, it won’t get to the bottom of it, but it’s a start to grasping whyever there are problems there. So that is one way you can start. There might be a lot of reasons why the team is not hitting certain deadlines.
How do you differentiate your high performing teams from your middle of the pack teams? And is there such a thing as a middle of the pack team? Will a software engineering team go from high performing to in danger?
Nowadays teams have a lot of rotations, members are coming in and out of teams frequently. In this industry attrition is a really big thing. And people might want to work on different things and they might leave a team. So the incorporation of a new person or one person or multiple people leaving the team can affect the performance of that team.
Apart from the fact that the moment that you incorporate a new person or another one leaves, your performance will be hit. But sometimes the person that comes in will be really good at something. There are weaknesses and there are strengths. A strength might clash with the rest of the team and might not be a good fit. Sometimes it’s not a question of the technical skills or the technical knowledge that a person has it has more to do with whether that person is the right fit for that team, and the time the team is going through. So you might have people that are really good under stress, you might have people who are not very good at dealing with uncertainty, for example. Making sure that you understand that and observing those behaviors and those patterns can also give you an indication of anything going south.
I don’t know if there is a middle of the pack. At the end, the results will matter. ‘How does this team deliver?’ ‘And how you can measure it all within the team and within the company?’ You might get teams that are very loyal to the company, but maybe their delivery rate or rhythm is not as fast as it could be. That might be the middle of the pack. It’s not something I’ve really thought about before.
What sort of projects and applications benefit from moving to a microservice architecture versus a monolith?
Complex systems are the ones that will benefit the most. If you have a simple system, then you’re just adding accidental complexity for probably no reason, just for the sake of it. Systems that are very complex. That can be an e-commerce site receiving millions of visits, it can be a bank having millions of transactions, it can be a platform for a marketplace for cars. It depends a lot on your environment but I think the ones that benefit the most are the ones that have a complex domain and a complex system or solution to fulfill those requirements that the domain requires.
It is also super important that you have a team that understands the complexities that you’re adding when you’re moving into this system. So the team should be mature enough to understand what they know about microservices and what they don’t know. I’ve seen it being done very nicely and I’ve also seen it done very poorly. It’s not because the people who were maintaining the systems wanted to do poorly.
Sometimes it’s because they didn’t know a variety of things within the scope of maintaining the system. There are many things that are in that ecosystem, that sometimes we don’t think about. It’s like concentrating on all of these little boxes in here when you have a big one. A mature team and a high complexity domain are two requirements that are super important. And if you don’t have those then a monolith might be a better choice.
A lot of times in tech we go with this idea that there is a problem that’s suited for a solution, but you’re also saying that your solution shouldn’t just be based on your problem statement, it should also be based on the engineers you have available. Can you expand on that?
Microservices uses the complexity that you might have on the service level because you are creating a smaller service. But the test coverage you will have is super light and can be deployed using a container, so they allow you to do many things.
They allow you to choose the language that you want to use to implement it. But at the same time, it’s moving that complexity, which will always exist, to the infrastructure layer. So then you have to worry about how to keep the systems talking to each other, what type of integration will they have, what are the security concerns that you have to get ahead of now. Can anyone access these services? Does this service have the same privileges as another one? There are a lot of things that require you to think in a different way. And software engineers were not trained for most of those things.
In the last 15 years, the system was not like that. The system was a three-layer architecture, developed by the engineering team, and then pass over the fence to the operations team which then will deploy and maintain the infrastructure. So when you have a microsystem environment we are now adding complexity to that infrastructure. And the people who are on the other side of the fence are like, ‘Hang on, why do I need to know how to deploy and maintain a python service? Or a Clojure service, or Go or whatever? When I was really happy just maintaining my java monolith.’
Then that complexity now relies on those two groups of people taking on untrained responsibilities. They were not trained for that. So that is something that the engineers need to learn or commit to learning, and that’s why training or thinking or learning more about infrastructure and operations is super important and is a crucial factor in successfully maintaining microservices.
As the innovation, incubation, and investment arm of The Boston Consulting Group, BCG Digital Ventures invents, launches and invests in game-changing businesses with the world’s most influential corporations. Interested in joining a dynamic team? Be sure to check out the careers page for the latest opportunities around the world!