Culture’s Role in Successful Technology Transformation

Urvashi Tyagi is a lifelong problem solver. In engineering school and early in her career, she solved technical problems. Now, as ADP’s CTO, she’s working on problems that span technology, culture, and mindset — from unifying the architecture of the payroll and HR solutions company’s technology platform and improving developer experience to facilitating digital transformation for ADP and its clients.

I recently spoke with Tyagi; the following is an edited and condensed version of our conversation.

MIT Sloan Management Review: You have held technology positions at ADP, Amazon, American Express, Bridgewater Associates, and Microsoft, among other firms. What have you learned about culture from your time spent at those organizations?

Urvashi Tyagi: One of the ways I look at culture is what people do within the company when no one is watching. Throughout the course of the pandemic, we’ve seen that companies that had a healthy culture continued to thrive and adapt versus companies where culture was more of a work in progress.

Something I noticed about ADP — and this was true of American Express as well — is that employees tend to work here for a longer period of time. At ADP, part of this longer average tenure traces back to the fact that careers and trajectories are not defined by one’s initial role in the company. Here, there are opportunities to grow, to learn and experiment, to build new skills, to take on different functions and different roles. It is a core part of the culture.

We also have each other’s backs, which creates a safe space to engage in healthy debates — because what we have seen through the digital transformation is that nobody, not one person, really knows the right thing to do next.

Technology is actually a team sport where you build on the ideas of your colleagues. Of course, people need to have technical skills. But you also want them to be great collaborators who support and work efficiently with each other. They have to understand how the code they write drives value for the business and helps clients. Maybe 10 years ago, it would have been acceptable for a rock star developer to just write code, but those days are gone.

Engineers have traditionally been thought of as left-brained subject matter experts whose jobs are task-oriented. But the culture you describe sounds like it is much more people-oriented. How do you help engineers make that transition successfully? How did you navigate that transition as a leader?

Tyagi: Something I have experienced at ADP that I have never seen before is that there is no mechanism for formal employee performance evaluations. Every company where I worked before I came here experimented with different ways to conduct performance reviews. For example, Amazon did 360-degree evaluations, which meant that your entire review was based on what your team said about you.

The challenge with the various approaches to performance reviews is that not every year will be a banner year — it is just not going to happen. During some years, people will pivot from one role to another one, or they will try to build new skills. So if your performance is graded relative to your seniority and your peers, and you work at the company for five years, then I am sure that for one or two of those years you will not have a good review.

The problem with yearly or twice-a-year performance reviews is this: If you fall short one year through no fault of your own, then that one bad review sets the stage for the rest of your career at the company. I saw that happen at every company where I worked before ADP.

Instead of relying on annual reviews, we have employees focus on continuous feedback and conversation. I think this is a much more modern way of thinking about performance — both how we work and how we learn and grow throughout our career. Each week, employees use an ADP-built tool, StandOut, to update their managers. Each week, the program prompts you to respond to questions like, “What did you love this week? What did you loathe? What held you back? Do you need anything from your manager?” Everyone across the organization participates in these updates — myself, my boss, my team. Sometimes it takes me five minutes, and sometimes it takes me two hours — because I use it for whatever I want.

Meanwhile, in the background, there are machine learning models that track engagement in informal ways that remove subjectivity. Machines are not perfect, but we do not use the results of machine learning to penalize employees. Rather, we use the information to assess if someone enjoys their role or if they are ready for something else. The data are conversation starters.

One of the implications of the traditional performance evaluation system is that it can punish people for taking risks or learning something new. They can also privilege men, who are overrepresented in the technology field. Has that affected your career?

Tyagi: I have three sisters, and our parents gave us two options: Become a doctor, or become an engineer. My family preferred that I study medicine, but I always loved to solve problems. I enrolled at an engineering college in India in 1990. I was the only woman in many classes, and I just got used to it. No one talked about diversity or gender equity; those conversations were not on the table.

My final year of college was 1994. Job notices for engineering graduates were posted in the hallways, and almost every company that was recruiting for engineering roles had a notice that said, “Female candidates need not apply.” One of the companies that was hiring was located in my hometown, a few hours away. Since they would not accept my application at the college because I was a woman, I asked my father to take my resume directly to the company’s HR department. I was called in for an interview as part of a local recruitment effort. The hiring manager did not have approval to offer me a job, but he did it anyway — a stroke of luck.

There are some advantages to being a woman in engineering. If you do good work, you are easily noticeable. If you present at a senior leadership meeting, people will remember you if you do a great job. If you mess up, people will remember that, too.

But there are cons. Women can be at a disadvantage when negotiating architectural decisions, and they have to do more to get their point across. And sometimes, as a woman, you have to do more to prove your technical credibility, to demonstrate your technical competence. These are some of the areas that I think female engineers often have to overcompensate to be taken as seriously or considered as good as their male peers.

I wrote a book called Meltdown, and it was about complexity and how complex systems fail. I am curious to hear your perspective on complexity. Do you think about it in terms of your systems? Do you think about it in terms of how your organization is designed?

Tyagi: We are a 71-year-old company. We began to write code in the late 1960s. Over the years, we had to not only evolve our technology but also help our clients do the same. It was not good enough for us to simply offer our clients the latest and greatest technology; we needed to help them integrate and modernize their processes, too.

If you look at ADP as a business, you see that we have about 10 core domains, including payroll, benefits administration, and HR. Over the years, we have seen the emergence of hundreds of competitors in these domains. We have had to modernize our systems with the agility and speed of a startup while also supporting our clients in the same stable way that we have done for decades.

Obviously, this causes complexity in a couple of areas, one being, how do we prioritize which systems to modernize? We cannot solve all of the problems or modernize all of the systems. So for the last year and a half, we chose to focus on developing a unified user experience across strategic ADP products and all customer touch points, regardless of which business unit a product came from or how a customer prefers to engage with us.

We also simplified and modernized what we call the developer experience — everything from DevOps to how applications are deployed in the cloud. Instead of developers in every business unit doing it their own way, we now have an enterprise team that leads developer experience. We believe that if we provide our developers with a great experience, then they can build great products for our customers.

Our back-end systems are truly becoming platforms, which improves our ability to pivot based on business needs, to go to market faster, to spin up new products, to experiment with those products with our customers, and then to either double down on them or shut them down.

What I am hearing is that ADP considers itself a technology company. But I think that there is a qualitative difference between people who see technological systems as a core part of their job and what they do and people who see systems as a secondary thing that is supposed to just “support” the business. It seems to me that you and your colleagues have a systems-first approach. Did I get that right?

Tyagi: You got it right. We provide cloud-based digital products to our clients, so we are absolutely a technology company. But we also pride ourselves in providing great service to everyone, from our small-business clients to our multinational ones. We have clients who stay with us for over a generation; we become a part of their lives during their time with us. The reason that we retain our clients and meet their needs is because we provide them with more than a technology solution.

One last question. I think one of the hardest things to do in the modern world, not just as a leader but as a human, is to recognize that there’s a lot we can’t control. I think there’s a real benefit for leaders who can sit with uncertainty without feeling pushed too quickly toward an answer. Do you think about uncertainty like this — when you’re comfortable with it and when you’re uncomfortable with it?

Tyagi: It’s a great question, and I think it’s interesting to think of it from a change management standpoint. This happens often, in my experience: You come up with a strategy that you think is the right fit for the business from a bottom-up perspective, but you’re just not ready to embrace it at that point.

Taking people along takes patience. Change management isn’t going to be a straight line. There will be resets, and sometimes the “best” option might not be the best thing for your team to embrace. This can be hard, especially at companies that don’t have a “wait” culture.

My time at ADP has helped me, where I’ve realized after navigating changes like this that there’s nothing wrong in waiting for the right time. One or two quarters’ time is not going to disrupt your whole vision.

Another thing that’s helpful to remember is that decisions made in the past don’t have to be set in stone. Instead, you can embrace a model of being flexible, reviewing data points as they come along, and evolving as you learn new things.

My career has taught me that digital transformation isn’t a one-time thing; it’s ongoing. It’s a transformation of the mindset and how you think as a business.