Leader Spotlight: Cultivating relationships and fostering collaboration with Scott Burgett

Scott Burgett is Vice President, Software Engineering, at CoverMyMeds, an integral part of McKesson Corporation. He joined McKesson in 2002 and previously served as Senior Director of Development, overseeing all developments for the pharmacy network, value-add, and data services. Scott received the McKesson “Distinguished Technologist” award in 2015 for sustained technical achievements.

We recently connected with Scott to learn more about CoverMyMeds’ initiatives and his current role within the company. Scott shared insights on leadership, recruiting, and retention. He also reflected on his own professional journey, including how he stays motivated and finds fulfillment in his work.

---

Increasing access to prescriptions

Could you explain what CoverMyMeds does and your role within the company? How does the engineering department that you head up contribute to CoverMyMeds’ overall initiatives?

For context, CoverMyMeds was acquired by McKesson in 2017. I was part of McKesson prior to that acquisition. About two years ago, my group and a few others were combined underneath the CoverMyMeds brand.

CoverMyMeds is focused on helping people get access to their prescribed medications. Access can be limited for a variety of reasons. The area of CoverMyMeds that my team supports is focused on affordability — things like co-pay assistance.

For example, let’s say someone with employer-sponsored health insurance goes to a retail pharmacy to fill a prescription. The retail pharmacist keys in what’s basically an insurance claim to see if the prescribed drug is covered by the insurance plan, checks the pharmacy reimbursement, and sees how much should be collected as a co-pay.

However, consumers have different sensitivities to cost. We’re able to see the behavior patterns associated with these claims and get a sense of whether there’s a financial sensitivity to the co-pay. We partner with retail pharmacies and drug manufacturers to offer co-pay assistance.

Let’s say a particular drug appears to have price sensitivity when the co-pays reaches $125, but we can see that there’s less sensitivity around a $75 co-pay. If we can buy down that prescription drug price from $125 to $75, then we’re more likely to help that patient stay adherent to their prescription therapy. That’s one example of what my part of the business unit does in helping with co-pay assistance.

Helping others grow

You mentioned being at McKesson before the CoverMyMeds acquisition — in fact, you’ve been at McKesson for over 20 years, in several roles.

Yes, I’ve been with this organization for 22 years. Prior to joining McKesson, I worked as a software engineer. I joined McKesson as a technical project manager, and then my career just kind of progressed. I became a first-line development manager, then a director, then a senior director, and then moved to my current role as VP.

I did have a stint where I was managing the infrastructure side of our organization, too — the data center, servers, networking, operations, and things of that nature. It became too much for one person to handle, so we split the role up, and I took over product development — software engineering. Today, I have about 120 full-time engineers reporting to me, a variety of different agile and scrum teams, if you will, working on the different products we have.

When the engineering groups moved under the CoverMyMeds umbrella, teams were still under their individual lines of business. There are four or five lines of businesses within CoverMyMeds right now, but a little over a year ago, we started centralizing the different functions. In doing so, we started organizing the business by function rather than by line of business.

Some parts of the organization have already started that journey. From a technology engineering perspective, we have just started to work on this initiative — bringing us all together under one engineering organization.

That kind of longevity with a single org will probably feel foreign to a lot of readers. In a market where many engineers make a jump every few years, what keeps you engaged and motivated?

I always tell people that to get into leadership, you have to want to be in leadership. To be an effective leader, you have to have a passion for helping your team members grow. It’s not just about completing projects on time, on budget, or within scope. A successful leader helps team members progress in their careers and also helps them figure out where they want to grow, getting them the resources or training opportunities they need.

On my leadership journey, I’ve learned to ask myself: “How can I help other people achieve what they want in their careers?” Asking that question, as well as having a passion for the work that we’re doing and a sense of purpose, is what keeps me motivated.

Before I came to McKesson, I worked as a software engineer. My typical tenure at a company would last two or three years. I would create a software package, build it, and it would be done. I’d never get to see it used. I didn’t know if it was helping someone. But at McKesson, I’ve always been able to see the work that we’re doing actually be applied and it instantly being leveraged and used. I get so much satisfaction from that.

Aligning the organization using VMOST

With that in mind, what projects have you worked on recently that you’re most proud of?

We do an employee opinion survey every year and consistently get feedback that team members would like to better understand how their day-to-day work ties back to the overall strategy of the organization. Oddly enough, it can be a very difficult thing to help people understand.

For example, as an organization, we want to help patients continue to get the medications that have been prescribed to them and be able to afford them. That’s high-level vision. Now, imagine you’re talking with someone who is setting up a server or building one feature for a particular solution. It can be very hard to clearly communicate to them how their work ties back to that overall vision.

To help address this, a couple years ago we started creating VMOST diagrams — it stands for vision, mission, objectives, strategies, and tactics. Many agile organizations use these. With this pyramid-shaped diagram, you define your vision and, below that, your mission. Next, you create your objectives. Then, below those, you develop strategies and tactics you can use to help achieve the objectives.

Let’s say a company’s objective is to be the best place to work. One strategy to tackle that might be to improve both technical and leadership training. A tactic might be getting a learning platform that offers relevant classes. Then, you get agreement, roll it out, and measure each team member’s progress.

This project also addressed another piece of feedback from our employee opinion survey: that collaboration could be better. To tackle this, I told my leaders, “Not only am I looking to use this VMOST tool to help show how the work our team members are doing ties back up to the overall vision, but I want all the people leaders working together to come up with the objectives, strategies, and tactics.”

We’ve been using the VMOST diagram as a tool to help improve the collaboration among the people leaders and the team members, too. For me, personally, that is one of the things I have been happiest to be a part of. It’s not complete, though — it’s still evolving.

It sounds like the VMOST tool has been helpful at a high level for collaboration and communication. How do you measure performance or efficiency on a more granular level in your day-to-day work managing teams?

The metrics I look at may sound weird to a lot of software engineers! The most important things I pay attention to in terms of metrics are: What is the capacity of my team to do work, and what is their utilization?

Ultimately, I need to make sure I’m not burning out my team members by just dumping more and more work on them. So I need to understand how much work they have been allocated, if they have the ability and resources to complete it, and if they have any remaining capacity.

I’m basically looking at labor data — it could be the velocity of story points or timekeeping. I know some people have concerns around the validity of timekeeping, but it’s just one of the metrics we can look at to determine next steps.

On top of that, I consider: How are we investing our effort? How much time is spent in strategic work? How much time is spent in support, maintenance, or implementations?

I also look at this data from the perspective of Gartner’s run-grow-transform (RGT) model. Run refers to the day-to-day activities to keep a product running — “keep the lights on,” or KTLO. Grow refers to adding capabilities to your platform or solutions. Transform is work that helps you get into a new market, reach new customers, or improve the efficiency of the organization.

Here’s an example of the transform metric. Let’s say back in the day, you didn’t have CI/CD pipelines. You’d spend a certain amount of time implementing CI/CD so that you could move away from manually building and deploying your software. By investing in transformation, you expect to see a reduction in costs.

The challenge with this model is getting consistency around how people classify their work. We first need common definitions. I’ve been collecting labor data for the past three fiscal quarters. So far, it’s been up to me to classify the data using the run-grow-transform categories. But in my opinion, to be effective, I will need to partner with product management and get their agreement on how to categorize the work that’s being done.

I would like to understand how much RGT work I’m doing at a product level. For example, you might ideally like to see your organization spend 20 percent on transform, 60 percent on grow, and the remaining 20 percent on run — just enough to keep the lights on.

As I said, I have just three quarters’ worth of data at this point — this project is still in an early stage.

Recruiting and retaining happy team members

Every hiring manager would agree that engineering positions can be difficult to fill. Do you have any tips for recruiting talent?

I think there are a couple of helpful angles. First, focus some part of your recruiting efforts on entry-level positions. Recent graduates can be a valuable resource for an organization. Instead of work experience, look at the innate soft skills like drive, passion, and the desire to own something.

You can teach technical skills. I can easily teach someone a programming language, architecture, or testing. But it’s really difficult to teach someone how to be collaborative, have initiative, or be a good speaker. So instead, look for recent graduates who have that drive and raw passion and teach them the technical side.

I would also give similar advice if you’re actively looking for someone who is more experienced. Don’t overlook a candidate just because they lack a specific area of technical experience. Instead, look for someone who is motivated to learn something new and has the drive to get stuff done.

How about retention? What are your secrets for keeping a large engineering team excited and motivated?

I would tell you that retention is largely tied to interest. But one thing I’ve noticed that makes a difference is staying in touch and having frequent conversations with team members. For example, if team members only saw me or other company leaders once a quarter, it would be difficult to build a relationship, and that would make it challenging to convey the organization’s messaging.

Helping people understand the organization’s messaging can be difficult. The higher up you go in the organization, the broader the messaging tends to be. It’s up to each leader to tailor that message to each of their teams and allow their team members to ask questions.

I have an open-door policy. Anyone can reach out to me and schedule time to talk. They may have specific feedback about something I’m doing, questions about something that’s going on within the company, or they may want information about decisions made on a particular project.

I also have regular meetings that have no specific agenda other than to answer questions or just talk about fun stuff. I won’t say “transparency,” because I feel like the term is overused, but I believe in creating the opportunity for people to ask questions. This helps build trust. I think a big part of the key to retention is cultivating relationships and building trust.

Do you have any other strategies for increasing a technology team’s work satisfaction?

In an effort to ease uncertainty with new tools, languages, or platforms, we started giving team members time to experiment. I want to note that I chose that word “experiment” intentionally — I didn’t say “pilot.” A pilot has an outcome — it’s either successful or it’s not. But with an experiment, the only expected outcome is to learn.

If you’re a leader, you really should be giving your team an opportunity to experiment. Make it clear that you don’t care if the experiment is successful. Ask them to try something new, do something different, or maybe create some functionality. Then, ask them to share what they learned.

That, to me, is the key. For any technology — artificial intelligence, machine learning, blockchain, or maybe the next version of a programming language — give team members the opportunity to invest in themselves.

At a time when we hear a lot about doing more with less, it’s refreshing to hear a leader say, “Just go experiment and see what you learn.” How did this idea come about?

Around five years ago, we experimented with a concept that came from one of our own managers. At the end of each sprint, the manager’s team members would each take an “investment day” — one full day to go do something and invest in themselves.

It could be experimenting with a new language, doing something in Google, or working with a cloud function. They could do whatever they wanted, but after, they would present their learnings to the team.

Other company leaders started mirroring it to their teams, and it kept propagating. Now we do it at a broader level throughout the company. The idea was driven by just one team, but they were listened to and allowed the time to try it.