How I operate

I have led platform engineering teams at Credit Karma for a while now, both as a manager of engineers and as a manager of managers running multiple teams. Over time, I have developed a set of opinions about how to lead. Some of these were intentional. Some I only recognized in hindsight by noticing what I kept doing. This is my attempt to write them down, both for people who work with me and for anyone who finds it useful.

What I think my job is

I see my role as two things that sometimes pull against each other. The first is to unblock and amplify the people around me. Remove friction, create clarity, make them more effective. The second is to set direction and hold us to that direction. Those two goals can conflict. Sometimes amplifying the team means letting them run. Sometimes holding direction means pulling them back. I do not think there is a clean resolution to that tension, but I try to be transparent about which one I am doing in a given moment.

When I am managing managers, the job shifts. I spend more time coaching leaders on how to develop their own people, and more time making sure multiple teams are pointing in a coherent direction. The problems get less concrete and more systemic. But the foundation stays the same.

Trust and alignment

If I had to reduce my leadership philosophy to one sentence, it would be this: people do their best work when they feel trusted and when they believe in what they are working on.

So I try to establish trust early. I default to trusting people until they give me a reason not to. And I spend a lot of time trying to align work with what someone actually cares about. If an engineer believes the work matters to their growth and to the business, they will perform better at it, and they will probably enjoy it more too. This is not always possible, but it is always worth trying.

How I handle disagreement

I am not the type to walk in with a strong opinion and push for it. When I disagree with someone on my team about a technical direction, my default is to ask questions. Not gotcha questions. Genuine ones. I want to understand how they arrived at their conclusion. Sometimes their reasoning is sound and I update my thinking. Sometimes the questions expose a gap they had not considered. Either way, we get to a better answer than if I had just overridden them.

What I expect

Two things I care about more than most leaders probably do:

Think about the consumer. We are a platform team. Our users are other engineers. It is very easy to get lost in implementation details and forget that someone has to actually use what we build. I push on this constantly. Who is the consumer, what do they need, and are we making their life better or just making ours easier?

Own more than your work. I do not just expect people to own their tickets. I expect them to own the output and presence of our team in the business. That means noticing problems that are not on the roadmap. Surfacing things that feel off even if they are outside your current domain. Advocating for the team to address something you think matters. That kind of ownership is what separates someone who is good at their job from someone who makes the team better.

Communication

I want people to be direct with me. Skip the preamble, get to the point. But I also want to see how you got there. Show me your reasoning, not just your conclusion.

The thing that builds trust fastest is surfacing problems early, even when they are half-formed. I would much rather hear "something feels off but I do not know exactly what yet" than get a polished post-mortem after it is too late to course correct. If you are stuck, say so. If something is going sideways, say so. I will not punish you for being early and wrong. I will notice if you are late and right.

How I give feedback

I give feedback directly. I do not wait for a performance cycle to tell you something you need to hear. If I see something, I will say it close to when it happened, and I will be specific about what I observed and what I think should change.

I also expect feedback in return. If something I am doing is not working for you, I want to know. I would rather adjust than have someone silently frustrated.

When things go wrong

I do not blame people for failures. Outages happen, deadlines slip, bad decisions get made. What I do expect is accountability. Not performative accountability. Real accountability. "I got this wrong, here is what I learned, here is what I would do differently." If you can do that, we move forward. If you cannot, that is a different conversation.

Growing engineers

I spend a lot of time thinking about what people on my team actually want from their careers. Not everyone wants the same thing, and not everyone knows what they want yet. Some of my job is helping people figure that out.

Once I understand where someone is trying to go, I try to match them with opportunities that stretch them in that direction. I also give honest feedback, even when it is uncomfortable. I think the least kind thing you can do as a manager is let someone believe they are doing great when they are not. That does not mean being harsh. It means being clear.

Managing managers

When I manage other managers, I stay connected to their teams but I do not override them. I have skip-levels and informal touchpoints with ICs so I understand what is happening on the ground, but decisions and direction go through their manager. My job at that level is to coach the managers themselves, help them develop their own judgment, and make sure the teams they lead are working toward something coherent together.

The hardest part of this is knowing when to step in and when to let a manager work through something on their own. If I solve every problem for them, they do not grow. If I stay too far back, their team might pay for it. I try to bias toward coaching, but I am not rigid about it.

1:1s

I do not use 1:1s for status updates. I can get status from standups, Slack, or PRs. Unless I explicitly bring something up, our time together is for career development, coaching opportunities, things that are on your mind, or topics that do not have another natural venue. I want 1:1s to be the space where we talk about things that matter but are not urgent.

Beyond that, I do not have a single template. Some people want structure. Some people want space to think out loud. Some people need coaching, some need me to just get out of the way. I adapt to what each person needs, and that changes as they grow.

What I am still working on

I am not great at celebrating wins. I tend to ship something, feel good about it for about thirty seconds, and then immediately focus on the next problem. That is fine for me personally, but it is not great for the people around me who put real effort into something and deserve to have it acknowledged. I am working on slowing down enough to recognize what the team has done before moving on.