Arthur Sabintsev

Hello! What's your background and what do you do?

Heyo! My degrees are in biological physics (BS) and nuclear physics (MS). I am a self-taught software engineer as I spent the majority of my teens and college years making websites and firefox browser extensions. Thanks to a couple of lucky breaks, I was able to transition from physics to iOS development in 2011, which is when I began honing my CS skills.

During my career as an iOS developer, I’ve worked at a mobile-focused agency (Fueled), a couple of startups (Shelby.tv, ID.me), and then right before joining Capital One, I was one of the lead iOS developers at The Washington Post (WaPo) for 3 years. During my time at WaPo, I led the mobile development of the mobile-component of their SaaS platform, Arc Publishing, which resulted in a white label architecture that currently powers over 60 major news publications, including The LA Times, The Chicago Tribune, and The Boston Globe.

Presently, I am an engineering manager and people leader at Capital One. Specifically, I manage the iOS Credit Cards Payments team and oversee architecture of the payments features on our iOS application.

How was your transition from software development to management like?

For the most part, it’s been pretty natural. I have always enjoyed leading initiatives, projects, groups, and teams at school and university, so every time an interesting opportunity would present itself, I would jump at it.

Before 2017, I had a few opportunities to hire and mentor interns and junior developers. I would do technical screens and technical mentorship, but nothing more. When the Arc Publishing platform started to take off at WaPo in early 2017, I was put into a position where I began transitioning from leading architecture to customer engagement, people management, and hiring. It was there that I truly realized that I enjoyed the people-aspect of software engineering as much as, if not more than, the technical/coding aspect.

When I joined Capital One in the autumn of 2018, I was specifically hired as a people manager, meaning that my main focus would be managing the careers of others, and everything else would be secondary to that.

As mentioned above, I’ve been the engineering lead on the iOS Payments team for the last year, which means I am the accountable individual for mobile payments on Apple devices. More importantly, I am also responsible for the careers of the people on that team, namely their happiness and their growth opportunities.

What does your day-to-day work look like, and what motivates you to do it every day?

At present, I have 5 people that report to me, one of which is an intern. I also mentor another individual, meaning that they do not report to me, but I do meet with them on a regular cadence to discuss their career and aspects of their life and personal development.

In a nutshell, my day is full of meetings, but I love it! Read on to find out why.

I hold weekly 30-60 minute One-on-One meetings with each of my direct reports, my mentee, and another senior engineer. This is my opportunity to really understand what’s going on with my people and find any opportunities to help them grow.

As an engineer lead, I also have many meetings with my Android Payments counterpart around features we’re working on, other mobile engineering leads around forthcoming platform changes, and other people managers about performance and talent management.

And don’t forget about all of the Agile Development rituals!

When not in meetings, I spend time reviewing my team’s code and working on side-of-desk projects.

What are the biggest challenges you've faced so far? What did you do to overcome them?

As an iOS developer, I’ve been very fortunate to work in a statically typed environment. When something goes wrong, the compiler throws a warning or an error.

However, with people, there’s none of that. Everything happens in real-time and a lot of it, especially at the beginning, comes down to following your gut instincts, which may not always be right.

To compensate, I’ve made sure to meet with my people early and often, and do my best to really listen to their wants and needs. Then, if possible, I do what I can to find or create opportunities for them.

I’ve also spent a lot of time reading/listening to books on having effective One-on-One’s, leading teams, and managing teams, which has provided me with some much-needed wisdom.

What has been the biggest surprise so far? Something you didn't expect?

How much more rewarding it is to give a task you yourself want to complete to your direct report and watch them knock it out of the park and appreciate you giving them the opportunity to grow.

The example that comes to mind is around a conference talk idea I recently had. Unfortunately, due to time constraints with work and family, I had no time to prepare for it. However, around the same time, one of my direct reports mentioned that they want to try their hand at speaking at conferences. As I’ve spoken at conferences many times over the years, I presented them with the idea I had and offered to mentor them through the process. They did a stellar job gathering the research, putting together the talk, practicing it, and presenting it.

Personally, I received so much more joy from it than I would have if I were to have given the talk myself!

What's the best advice you've received about being a manager?

The absolute best advice I received was the entirety of this book - Extreme Ownership. For the sake of brevity, I’ll mention my 2 favorite lessons from this book:

1. You need to learn to lead up and down the chain of command.

2. You need to take ownership for everything good/bad that happens to your team or even if you were not involved directly.

The first point essentially says that you need to learn how to effectively communicate information up and down your leadership structure. For example, when it comes to building a new feature and communicating status updates, my direct reports care about the impact and User Experience (UX) of this feature. Going up the chain of command, I care about this feature being architected properly, in a reusable manner, and by an engineer that can grow from the opportunity of building out this feature. My manager cares that this feature is built in a timely manner and that all business stakeholders are aware of any potential issues that impact the timetable. Without going into too many details, I will succinctly state the farther up the chain you go, the more conversations become about the business impact, including the viability and penetration of this feature, the cost of maintaining this feature from a technical standpoint, and then the cost of maintaining this feature from a human capital standpoint. Therefore, to me, leading up the chain of command means knowing what information to provide to an individual for them to effectively do their job.

I will paint the second point through a hypothetical example. Let’s say that you have two teams, one of which is yours, that consistently contribute changes to the same shared component. Let’s say on one occasion, the other team introduces a bug into this component that presents an unwanted user experience in your team’s feature. Let’s then say that this bug is only caught in production when end-users start reporting it through reviews or calls to customer service? Who’s at fault here? As the engineering manager, you are culpable.

But why? There may be a dozen ways to answer this question, but the immediate examples could be the lack of great automated tests, or poor manual test cases. Maybe it’s the architecture? Maybe it’s the lack of communication amongst the teams? Maybe it’s the lack of tools like GitHub’s Code Owners?

Even though you may not have written any aspect of the code, or even been involved in any conversations around changes made to the shared component, you are ultimately responsible for setting the team’s culture and best-practices --- how the team writes, tests, and approves any code that affects the team’s features.

What do you tell developers who are considering making the switch or new to the role?

Before you take the leap, make absolutely sure you are ready to drastically reduce the amount of time you’re willing and able to devote to writing code. Also, you must accept that your skills will slowly begin to atrophy, as you will have less time to stay up-to-date or to hone your engineering skills. I still struggle with this sometimes, so I’ve done my best to, at a minimum, maintain a few of my open source projects. While everyone learns differently, I've personally started spending a lot of the time I previously dedicated to coding, reading and listening to books/podcasts/blogs on management and leadership.

Final call to action! Where can we go to learn more about you?

You can find out everything on my website: http://www.sabintsev.com