Credit Leadership Program at PayPal: Rotation 3 Learnings

Disclaimer: This is my personal blog - all opinions are my own and do not represent those of my employer.

In this rotation, I was in business operations for our sales organization, where I got to see how our talented staff of BizOps leads, salespeople, finance managers, and sales enablement worked together to solve problems for our merchants and our organization.

Here is a bit of what I learned during those six months.

A Manager's Leverage is Her People

To oversimplify a bit, as an engineer, you are typically graded on your ability to write code to accomplish some business thing. As a manager of engineers, you are typically graded on your engineers' abilities to write code to accomplish some business thing. Your leverage as an engineer comes from your ability to write that code, whereas your leverage as a manager comes from your people and your ability to empower them to write that code. It follows that if your leverage is your people, you are also responsible for making sure the right people are in the right seats, and that the team's processes allow them to be effective.

Focusing on the report's perspective: your manager has a direct stake in your work because it represents a large chunk of her work. Your success is her success, your failure is her failure. She wants to help you accomplish your thing however she can because the sum of your things are her thing.

As you're talking through your work with your manager, she'll typically ask you questions like, "How can I help?" or, "What kind of support from me do you need to get this done?"

Know What Support You Need and Ask For It

When your manager asks how she can help, you really want to have a good answer - you should be thinking about what additional pushes could help get you over the finish line. Sometimes it may be, "All good at the moment - nothing yet," if you think that's the case. But your manager can be a real operational asset and wants to help.

If you haven't asked for help ("I think I'd like to escalate this request that's not getting traction" or "Can I use you as a sounding board on my approach?" or "I'm trying to understand more about problem X - do you know anyone on team Y I can reach out to?" or ...) you're probably not making the best use of your resources, and you could likely be even more effective.

This is sometimes called "managing up." It involves asking for support when you need it and keeping your manager informed of what is going on. I wish I had done a better job of this, and it's a learning that will certainly stick with me.

Chesterton's Fence

The more modern type of reformer goes gaily up to [a fence] and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it. - Wikipedia

Chesterton's Fence is the idea that before changing something, you should understand how and why it got to be that way in the first place.

For some of my projects, I was tasked with improving a process. As I learned more about the process, it became clear that, while it may not have been ideal for our current situation, it had grown organically with the needs of the organization and people over time. There was a reason it was the way it was, and I would have ignored that at my own peril. I spent time talking to several people trying to understand how the process evolved over time and why. That history became instructive as we tried to come up with a solution. One of my managers framed it well: rather than reinventing the wheel, we were taking the time to reassess our needs moving forward and tweak our process to fit those needs.

We could have destroyed the fence and replaced it with something new, but by understanding why the fence was put up, we knew what challenges and priorities shaped the fence in the first place. This gave us a better idea of how to move forward.

I've been a part of several engineering projects where we had to modify what we had built a year later as our needs evolved. Knowing why it was built that way and why we made those decisions was helpful, and forced us to see problems in their larger context rather than making changes in a vacuum. (Good documentation was also helpful for remembering why we made those decisions...) And as you onboard to a new project, it can be easy to look at it and say, "This is the wrong way to do it, and it doesn't suit our needs - let's rewrite it in this language / architecture / infrastructure / etc." But by keeping Chesterton's Fence in mind, we can be more nuanced, thoughtful, and surgical with our approach to solving problems.

Look For Opportunities to Leverage Your Skillset

... but don't be just a solution looking for a problem

Anywhere you can use your unique skills to help your team, that's an advantage they wouldn't have had without you. Being able to use your technical background in project management or your operational background in engineering can be hugely impactful if done thoughtfully.

Given my background with automation, technology, and tooling, I was able to help my team see process problems in a different light. At first, I found myself advocating for change for change's sake - not a helpful thing. When all you have is a hammer, everything looks like a nail. Over time, I got better at recognizing what problems to solve rather than trying to shoehorn things into a vision I had for what could be. Part of that goes back to Chesterton's Fence: understanding the context surrounding a problem, rather than just seeing problems at the immediate, surface-level.

Understanding what is important to your team, how the team and its members operate, and what processes and problems they struggle with will guide you as you look for ways to use your hammer.

Give, Don't Just Take

As you're focused on your work, it can be easy to ask people to help you out or contribute to what you're doing - in your day-to-day projects or in your career in general. But to really make an impact, look for opportunities to give rather than just taking. It goes above and beyond the call of duty but can make a big difference.

In my rotation, I got used to asking people to do things - asking someone to send me some information, update a deck, or complete a task. Instead, I could have spent more time asking myself, "How can I help?"

In hindsight, there were opportunities to help all along the way, but using my network effectively was a big opportunity that was pointed out to me.

Leverage Your Network

One way to be a giver and help more is by connecting dots in your network - if a teammate is working on a project, connect him with one of your contacts who has solved a similar problem. Given that I'm part of a leadership development program with access to a talented alumni network, I could have looked for opportunities to connect my teammates with people in my network who had solved similar problems or had insights to share. Had I done more giving as well as taking, especially by connecting people in my network, I think I could have had a bigger impact.

Don't forget to look up every once in a while for opportunities to connect people.

The Problem is the Opportunity

I was pointed to a commencement speech given by Robert Clarkson for UVM's MBA class. One of the key takeaways is that careers are made by solving difficult problems that others can't - where others stop, the superstars use creativity and perseverance to overcome obstacles.

When you frame your job in terms of your boss giving you problems to solve and it being up to you to solve them, you recognize that each problem is an opportunity to prove your capabilities and talents.

The people I saw solving problems really well in Business Operations typically followed a process:

1. Understand the problem and current state (by talking to others, digging in yourself, etc.)

2. Using your analysis and expertise, propose a solution to your stakeholders and gather feedback

3. Plan, prioritize, and implement the solution

As trivially obvious as it sounds, I saw my BizOps teammates follow that process consistently. Rather than waiting for someone to tell them what to do, they would identify a problem, raise their hand to solve it, and kick off their process. They determined who would be accountable for what and when they would be accountable for it. They provided regular updates to their stakeholders on progress and direction. Everything was a chance to revisit: is this the right solution for us? Each problem was their opportunity.

Leaders Set the Tone for Their Organization

I've been lucky enough to watch really great leaders at work, and one of the things I've noticed is that the things that are important to a leader will generally be important to her people. There is probably some self-selection here, but I think people also tune in to the expectations of their leader.

Good leaders are aware of this and know that the things they say and do will be examples for those around them. As I'm finding my voice in technology leadership, I've started asking myself questions like, "If I wanted to affirm a culture of [some value or principle] on this team, what would I say here? How can my actions help set that tone?" Being deliberate and intentional helps me stay on the right track. If you want to set a culture of even-keeled, consummate professionalism and teamwork, it starts by reflecting that behavior yourself.

It sounds obvious, but I was impressed with how, when a leader carried the torch for diversity and inclusion or built community by being engaged in organization-wide forums and chats, the rest of the organization followed his lead.

Someone once said to me, "Rational people like to work with rational people." Fair enough - that implies that people will work with others who value the things they do, but I think I am arguing a step further: when people know what their leader values, they will accentuate those values in themselves.

Leaders Let People Know What's Expected of Them

The best leaders I've seen will say things like, "Please come to Monday's Ops Review having reviewed this dashboard of your open issues, and be ready to present a plan for how your team is going to fix them," or, "Please come Wednesday prepared to discuss your team's feedback on X."

Not only do people like to know what is expected of them, you give everyone a chance to thrive when there are clear, explicit goalposts.

Mind Your Say/Do Ratio

One of the biggest things you can do to build trust on a new team is to mind your say/do ratio - the things you say you'll do compared to the things you actually do. Conversely, when you don't follow through on the things you say you will, it also affects your team's trust in you. I dropped the ball a few times by not following through on things I said I would, and I noticeably damaged trust by doing so.

It's such a simple principle, but what an impact it can have... when you say you're going to do something, follow through.

Reflection Takes Time, but Insight Is a Sign of Growth

I finished this rotation over six months ago, but I am still learning from it. The things I took away from the rotation in June '22 are different than the things I am taking away from it in January '23 with six months additional experience, and in another six months, I hope I'll have more insight still. That's part of why I took so long to write these reflections - I felt like I still had more to explore.

When you look back at your old code and see what you could have done differently, I think that's a sign that you're getting better. (And if you look back at your old code and still think it's perfect, submit a pull request 😉 )

-Ben

I owe a tremendous debt of gratitude to my team and coworkers, my managers, and my sponsors who allowed me to have the opportunity to be a part of this program. None of this would be possible without them.