Credit Leadership Program at PayPal: Rotation 1 Learnings

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

Since January, I've been a part of PayPal's Credit Leadership Program, which consists of 4, back-to-back, 6-month rotations in various parts of the company to learn about the business and grow as a technologist. Today is the last day of my 1st rotation, so I've taken some time to jot down what I've learned, and I hope sharing this will help someone like the reflection has helped me think about what I'll take away from these 6 months.

For rotation 1, I was embedded on the Operations Architecture team within our Site Reliability and Cloud Engineering (SRCE) organization. This team of architects and operations engineers is responsible for overseeing and advising on initiatives such as data center migrations and builds, software deployment patterns, and the critical infrastructure that keeps the site up and running. Also, they are technical enough to get their hands dirty and jump into a project (and often do) to help out with the technical work when needed.

I got to work on a few different projects, including writing tools to help automate pieces of our international expansion, architecting an automated traffic management solution for the site, and helping out with some of the team's odds and ends, like quick scripting to find common application connections to verify during a data center migration. I also got to see how involved a public cloud migration can be - "lift and shift" is great in theory, but things look different when you're on the ground. I had great mentorship on the team from some pretty senior operations architects who knew our infrastructure backwards and forwards and were always willing to answer my questions. I got the chance to learn about our traffic management and load balancing systems, DNS infrastructure, the site architecture & operations, and how it all comes together in one organization managing lots of different workstreams.

But just as important as the technical learnings were the higher-level lessons. Here is some of what I've learned in the past 6 months, taken from my notes.

Getting Alignment is More Important Than Getting the "Right" Answer

As part of CLP, we are lucky enough to get face time (virtual, for now) with leaders of our business unit. This learning came from a 1-on-1 with one of our organization's leaders, Wes.

As engineers, we try to make the best technical decisions we can, but more important than getting it "right" is getting everyone aligned on one answer. Part of your job as an engineering leader is to help your team find that alignment.

And, it's important to have a team culture where, even if someone didn't vote for the decision, he will internalize it and own it as if he did - no I told you so's after the fact.

Also, sometimes you may need to make a "burn the boats" decision. It's a risk, but there may be times not having a fallback plan is the right move, and it may be the best way to move the needle when you need commitment.

A few years ago, I had a tech lead on a previous team who grew tremendously when he made the shift from attempting to convince the team of his solution (or asking them to poke holes in it) to helping the team align on a solution under his guidance, based on his technical expertise. Not only did our velocity improve because we were working on the implementation rather than arguing about the design, but the team gelled because we all had ownership of the solution. With that, the team found its own operating cadence, and as another benefit, because our lead was helping us find alignment rather than dictating the answer, it gave the next leaders a chance to step up. When he transitioned to a different role, we already had another engineer who had been taking on a lot of leadership within the team, and he was able to seamlessly step into the tech lead role. The outgoing tech lead was able to grow those underneath him by allowing the team to drive more and helping them align around solutions rather than dictating from the top down.

Solve Problems, Don't Just Execute Tasks

Sometimes it can be easy to fall into the trap of executing tasks rather than solving problems. Ask yourself: Is there a better way to do this? Focus on the problem, and make time for yourself to zoom out and look at other options.

Especially if you're new to a domain where the people around you have more expertise, it can be tempting to rely on them for direction. You should absolutely be able to lean on your teammates, but don't do so at the cost of abandoning your ability to think independently about the problem.

Digest the problem so that you can understand it, which will take a while. You'll probably need to reach out to a lot of people - and because you don't know the domain, you may need to reach out to people to even figure out whom to reach out to to understand the problem better.

Be Flexible Enough to Change, but Committed Enough to Move Forward

One of the other engineers I was working with gave me a problem he wanted me to solve and the steps he thought I would need to take to do it. So I started working on each of the steps without "zooming out" to see whether this was even the right approach to solving the problem.

It took me several weeks to realize that there was a better approach, but by that point I had already done a few weeks' worth of work that needed to be thrown out (in software development, this is called "churn"). I had gotten locked into a solution early when I should have reevaluated whether there were better approaches.

Seek Others' Opinions, but Trust Your Gut

During your Technology Leadership Program experience and your career in general, lots of people will be happy to help guide you, offer you advice, and be a sounding board for you. It's important to seek different perspectives and value their input, but it's equally important to be able to synthesize their input into your own process. If everyone is telling you to zig, and you still think the best answer is to zag, it's good to ask yourself (or even those around you), "What am I missing?" Seek to understand why others hold that opinion. If after you've hashed it out, you think your path is the right one, then trust your instincts and give yourself permission to zag.

Leadership is About People

During a 1-on-1 with a senior technologist at the company, he started the conversation with, "So, how's Timonium?" I knew of him but I wasn't sure if he knew who I was, so I had no expectations. Still, it was really nice that someone I looked up to knew who I was and what office I was from (we have lots of offices around the world). Regardless of whether he knew that because he was familiar with my work or because he simply looked it up in the company directory or LinkedIn, it meant a lot. It really reinforced for me that a leader is someone who cares about the people around her and shows you that you matter.

Be Thoughtful When Examining a Decision, but Don't Be Afraid to Act

It can sometimes be easy to procrastinate on a decision, hoping you will have more clarity or information later. When I was choosing my next rotation, I had narrowed my choices down to my top 4 but was struggling to pick the order. They were all great in different ways, and I could have picked any one of them. I started to see myself spinning my wheels, and that was my cue that I was far enough along to make a decision. I had done all the legwork - my 4 options were there because I thought they would be great choices, and the only thing standing in my way now was just picking one.

I had to trust that no matter which one I picked, even in the unlikely event that it ended up being a bad rotation, I would still find a way to get something interesting out of it. There really was no wrong answer at this point. Also, if I did the best I could and the rotation still turned out bad in hindsight, there was probably nothing more I could have done to make a better decision anyway - you can't control everything and you can't predict the future.

When I talked with my current manager, he suggested I timebox the decision to prevent it from dragging on. This was helpful as well - I probably would have made the same decision whether it was timeboxed or I spent more time sitting on it.

Be Specific When Communicating Goals and Asking Questions

People usually want to help you - if you can say to them, "Here's what I'm trying to do and why - do you think you can help?", they can usually figure out how best to help. And if they know why you are trying to do something, they could also recommend a better approach that you might have missed.

When I was interviewing for my current and next rotation selections, I told potential managers what specific skills I was hoping to learn and why. For example, I've noticed that sometimes, my decision-making style leans towards putting off a decision as long as possible while I gather more information and understand the problem. After speaking with some of my mentors, they gave me some good advice: that I needed to get comfortable making decisions in ambiguous environments. Now I was able to point to something specific I was trying to get better at.

When I was able to be specific with my potential managers that I was looking for an ambiguous environment where I had accountability for my project and why, they were able to see what I was trying to do and help me find opportunities to do it.

Create Your Own Structure to Work Effectively, And Don't Be Afraid To Shape Projects Around Your Needs

Make a plan for yourself - work with your manager to make a 30, 60, and 90 day plan for how you're going to onboard into your new job. Whatever you need to get the project done effectively, do it. If you need a regular cadence with a stakeholder and there is none, create one. Don't assume the structure that's already in place is the right one. Chances are, the people you're working with are waiting for you to ask for what you need anyway. Shape the project structure around what you need to be successful where you can (keeping in mind others' needs as well). It gets rid of the excuse of, "Well, we could have done this better if it weren't for our lack of communication" or whatever the excuse is.

Don't Wait for Someone to Spoon-Feed You - Jump in and Drive

You're accountable for these projects and initiatives you're working on - it does no good for anyone for you to sit around and wait for someone to pull you into a meeting explaining what you need to do. If you need help, pull people into meetings or dig through documentation, but do what you need to do to make progress... part of operating on a higher level is that you have the ability to drive the initiative more. Don't wait for someone to put a story on the backlog and assign it to you during a planning session. The onus is on you to setup a situation where you have what you need to get your work done.

Manual Work is Expensive - Seek to Automate, but Move Upstream

Engineers like building new stuff, but sometimes we don't put enough thought into upgrading our old stuff - and all that is new will soon be old.

While sometimes, we need to move quickly to get a project out the door, in the long term, having people manually doing repetitive tasks is expensive, slow, and error-prone. For example, if someone is logging into a machine to run a few commands every day, it can be tempting to automate that individual process. It would be easy to say, "I'll write a script that does this."

But, what you end up with over time is a bunch of one-off, custom tools that nobody owns, nobody knows how to fix when they break, and they're not really operationalized. Rather than automating the individual task, zoom out and move upstream of the problem: ask, "Why do we have to log into this machine to manually run this command several times per day?" For example, the answer might be, because we get several requests per day from development teams around the company to do this. Then you will start to see the problem you actually need to solve. For example, why is this happening enough that dev teams are asking us to jump in? Should the development teams own this process? Should we build a tool for them to service themselves?

This goes back to solving problems rather than executing tasks. Move upstream and solve the problem rather than executing all the tasks after the problem has happened (though those need to get done, too).

For more on solving problems before they happen, I found Upstream by Dan Heath to be a great read.

Communicate Early and Often

Especially if you have multiple things on your plate - let all your stakeholders know what your priorities are so they can adjust accordingly. There's nothing worse than having someone ask you, "How's project X coming along?", and you answer, "Oh, I haven't been working on it - I was pulled into project Y."

If you've gotten to that point, that's probably a communication failure on your part. Communicate what's going on to the people that need to know it - don't avoid it, and don't always assume everyone is on the same page implicitly, especially virtually.

Block Off Weekly Time for Learning and Networking

Make use of your learning time for whatever you want - you may want to catch up on articles from the newsletters you subscribe to, read up on optical computing, do a tutorial on serverless applications, or watch a video from a conference on clean architectures. (This time is separate from any "20% projects" you might be working on in your spare time.) It's important to make a habit of continually improving your skills and trying to understand the world changing around you.

I don't like the word "networking," but you can use this time to check in with people you haven't spoken with in a while - you can setup 1-on-1 meetings with previous managers or teammates to say hi, and they may want to hear what you've been up to as well. This is especially helpful in the remote work world where these types of conversations might not happen otherwise.