Talking about Data Driven Engineering with Alexandra Paredes

Alexandra Paredes is the Head of Engineering at Code Climate. She focuses on building the right processes to ensure that her teams are productive. She is one of the co-founders of Latinas in Tech New York City.

Here is a transcript of the interview with her, edited for brevity.

What does Code Climate do?

Code Climate is an engineering intelligence tool where we create useful products for engineering leaders. Our tools offer data-driven insights into how engineering teams work together and what opportunities can improve the processes, communication or organization of teams. With the help of these tools, engineering leaders can coach their teams and work towards a goal.

What are your roles and responsibilities at Code Climate?

I'm the Head of Engineering. The engineering team works closely with the product team to understand the features and roadmap of the product. I manage a small team of seven full-time engineers, and we also work with three contractors.

Engineering organizations trust in our products to help with their objectives and for that reason, security and performance are a top priority for us. So I would say my primary responsibilities are growing the team by coaching, mentorship and hiring as well as keeping up with the product’s new features, performance and security.

What are the top challenges, and where do most of your time go?

Managing a small team is great in some ways because there aren't many barriers to communication. But it is challenging in other ways because you have different or sometimes opposing goals. Another challenge is finding career-building opportunities for the engineers on the team that help them explore their interests without conflicting with the product’s needs. And most of the time goes into making sure that everyone is aware of what our priorities are and how they could be using their time most effectively to build a stable and performant application at a good pace.  

Could you give us some insight on how scaled yourself from an individual contributor to engineering leader at Code Climate in about two years

I joined Code Climate as a senior software engineer. I was super excited to build products for engineers. It's like a dream; you’re building products for an audience that you thoroughly understand. You know their challenges and pain points. And all of these are very technical products, so that's great. I used my skills to help others be more impactful, get better and be more productive, and then I realized that this is a real role.

My manager at that time was very supportive when I approached him with my idea. I had the training, and mentorship, which made it better because I knew that I had support at my company and they knew that even though I wasn’t the most experienced engineering leader, I was open to learning and that is important.  

If you are ready to exit your comfort zone, you will always find that there are a lot of opportunities to grow, especially in a small startup. I do get overwhelmed sometimes, but I am okay with trying something new. I am comfortable being in that position, so I just asked for it.

How do you use your "Velocity" tool to drive your team?

I use the product for a couple of different reasons. One is to make sure that the product works and is valuable. Another reason is that it gives us insight into how we are working as a team without any biases or assumptions. With the help of the tool, we can figure out if pull requests are taking too long to deploy, it could be because a lot of discussions are happening in the pull request which ideally should have occurred before starting the implementation. It also helps us have more open conversations on how we can support each other, how to improve the process or figure out better channels of communication.

We have quarterly metrics at Code Climate mostly based on the Velocity power metrics. So I check these metrics weekly to make sure that we are in a healthy range. If I see a problem, I start researching potential causes, and this can lead to a retro or one-on-one where I can address the problem.

How do you see the data-driven engineering evolving?

I think it is a new space in the market. We’re working with our customers by helping them understand how "Velocity" fits into their daily workflow and long term direction. We have also seen that companies that practice continuous delivery are more open and eager to use data to gain better visibility. I see this trend becoming more and more popular if you look at other products like GitHub, CircleCI and others who are exposing more data around the basic development cycles.

We at Code Climate try to give you visibility into your code from the first commit to deployment, i.e. the whole development cycle on an individual, team, and project level. An engineering leader wants to have a preview of everything that is impacting engineers. For example, something that I track is incident data. I want to know if my engineers are getting woken up at night with an incident. This is a huge red flag and indicates that I need to prioritize stabilizing the system and making sure everything is performing well. Having all this visibility in one place helps me know which part of the system I need to prioritize.

What do you think would be the reason why companies fail to do data-driven engineering?

It depends on the communication maturity of the team. Especially engineers-- if they don't feel confident that leadership is going to use the information positively, there is some concern. Something that we emphasize is that data is not being used to punish; instead, it’s giving us the insights to understand what part of the process is not working. Some organizations are not mature enough to have these conversations, so I think that would be one of the main reasons.

What do you think can be done to improve the ratio of women in Engineering Leadership roles?

I think a lot of it has to do with biases. There are small but significant biases that prevent women from growing as quickly as men. I think that in a way, I am fortunate to be part of an organization where biases don’t dominate the culture or career growth. I do notice that a lot of people in engineering leadership roles have certain traits in common, not only are they mostly men but also personality-wise, they speak loudly and confidently. I am certainly not the loudest person in the room, nor am I a know-it-all, but I am here to support my team by enabling to do their best.

Sometimes when I look back and think about how we can make things better, I feel we have to change the perspective of what we believe a leader should be. I see a lot of engineering leaders, especially women, do talks about this, explaining that there are different kinds of leadership personalities out there. I think the first step to changing the landscape is to have existing leaders be aware of their own biases and be open to challenge their own perspectives by taking action.

What has been your experience in building the community "Latinas in Tech" in New York?

I’m from Venezuela. I moved to the U.S. six years ago. And when I moved to New York four years ago, I didn't have a support network. Part of me felt a little bit alone, even when I knew I wasn’t. My situation was not unique; others were going through the same experience. That's when I realized I could start a community where I could meet people that understood the situation I was going through, and we could support each other. I met the three other co-founders on the Slack community, Techqueria. There were people from different disciplines like designers and engineers in the group who felt the same way. There was not a community out there telling you how to navigate tech in the U.S., how to be aware of certain things that you should be mindful of, and how to make connections.

We got started a little bit over a year ago. Fortunately, companies are very supportive when we reach out with regards to having an event with them. Even everyone at my job is always excited to help by sharing the event with their network. Currently, most of the members of the community are very junior and one of our challenges is to find the right connections for them to get the opportunities they need to start their careers.

Recently you have given a talk about the importance of feedback. We would like to know how feedback has helped you in your career growth?

I think feedback is one of those things that’s hard for everyone. It's hard to give if you're not used to it. It's hard to receive because obviously, no one wants to hear they're not doing something right, but there is nothing more effective to help you grow than someone

being honest with you and telling you what you did right and what you could do better next time. And if you remove your ego, take that constructive feedback and apply it, you can grow quickly.

What are the lessons that you learnt while building your team at Code Climate? And what are the challenges that you faced?

The first would be to remain focused; it makes you more productive. A little over a year ago, I had a conversation with my manager about our pace of delivering the product. I was worried that we were not delivering it as fast as we needed to. My manager helped me realize that we were focusing our attention on too many different initiatives, and obviously, we were not doing well in any of them. Since then, we have changed the way we approach things. We select two or three essential features that our customers will benefit from and focus on those. We made a lot of progress very quickly, and once we solved the problems, we repeat those same steps to decide what issues to work on next. I think that has been one of the most important lessons.

Having a team that is supportive of each other also makes a big difference. We have different levels of seniority on the team, so I always encourage senior members to support the less experienced members. It helps us to move quickly as a team. It's not effective to have just a superstar engineer, so I try to avoid having one rock star on the team. I think that's another valuable lesson.

One of the main challenges I would say is, it's hard to experiment when you have a small team. Everyone is often very focused, so finding a room for learning or experimentation means we I need to be creative for example I organize half-weeks every quarter for trying new tools and technologies.

How do you onboard a new engineer into a team without making him/her feel left out?

I'm fortunate to have very nice engineers. When a new engineer joins, we pair them with different engineers on the team for the first few weeks, and this helps to start the bonding process. I also try to do more informal activities like team lunches, ping pong outings, or other fun activities to build the rapport. It can be a bit scary to join a team where everyone is close, but I try to make sure that we have processes and activities to start incorporating new people as quickly as possible.

What advice would you give yourself when you started as an engineer manager?

When I started as an engineering manager, I was worried about doing a lousy job and letting people down. This was because I was lucky to be managing engineers who were  extremely smart. I learned from them every day, and knew they deserved a good leader.

Fast-forwarding to the present, I realize that being a good leader is not about having all the answers, it is more about getting all of the context you need for a situation and using that information to empower everyone that's on the team to do their job. It's about being open and transparent about your worries as a leader, where you see the team going, and how everyone on the team can help achieve that goal.

---