At Urvashi Tyagi’s first job after college, there were no other women in the company. None. ADP’s Chief Technology Officer knows first-hand how challenging the path can be for a woman in STEM.
Urvashi Tyagi grew up in India. She and her three sisters are all engineers; her oldest sister paved the way. When her sister told the family she wanted to become an engineer, Urvashi’s parents, aunts and uncles were worried no one would want to marry a woman engineer. And besides, it wasn’t even a good career choice with barely any job opportunities for female engineers. After an extended family meeting resulted in an unfavorable outcome, her parents had a change of heart and let Urvashi’s oldest sister join the engineering program. When it was Urvashi’s turn, no one questioned the decision. (And she and her sisters are all happily married and enjoying their professions.)
The Only Woman
While both technology and culture had changed a lot, there were still many challenges for women engineers. When Urvashi was a college undergrad, she was one of only four women in a class of 90 engineering students.
As she was graduating, most companies were not interested in recruiting women. So, she didn’t get a job from campus interviews. But Urvashi noticed an ad in the newspaper at a company that developed machine tools and wanted to hire college grads with design and computer numerical control programming experience. She was invited to interview and was delighted to get the job.
Show up, keep learning, and often it works out better than you could have imagined.
– Urvashi Tyagi, Chief Technology Officer at ADP
When she showed up on her first day, there were no other women in the company. There had never been a women’s bathroom. “Someone printed out a sign that said, ‘Women Only’ and taped it to one of the bathrooms for me,” She says. Grateful, Urvashi overlooked the fact her bathroom was in a different building than where she worked. “I had to figure out how to co-exist on the shop floor and focus on the work. Most of the time it was good. I learned a lot about solving complex engineering problems.”
Later, she found out the hiring manager never had the permission to hire her. He sent the offer letter because she was one of the top two candidates selected based on test scores and interviews. His boss was not entirely pleased. “I got the job because of one individual who did not see things in a stereotypical way and was focused on finding the right person for the role.”
While working full time, Urvashi went back to school to earn her MBA. From there, she decided to teach operations management and information systems. As an academic associate for a couple years at the premier Indian Institute of Management Ahmedabad, she had the opportunity to work and connect with top professors all over the world. But she realized she enjoyed solving problems more than being in a classroom. One of her colleagues encouraged her to apply to a master’s of science program at Worcester Polytechnic Institute, in Worcester, MA. Urvashi wasn’t sure she wanted more school or how she was going to pay for it, but she looked up the program. The customizable curriculum and the focus on applied learning swayed her. She learned that the deadline to apply had already passed, but after speaking with a professor at the school, she submitted her application and was admitted.
Her family didn’t want her so far away. Once again, her older sister supported her and encouraged her family to let her go. Urvashi’s sister was also moving to the United States with her husband and promised to keep an eye on Urvashi. Her parents scraped together the money to purchase their first-ever airplane ticket and a couple months of living expenses. She arrived in Massachusetts with two bags, one full of snacks.
Learning and Solving Problems
Since graduating from WPI in 2001, Urvashi has worked for many of the big names in technology, including IBM, Microsoft, and Amazon. She’s led global engineering teams doing product strategy, architecture, and development. When you download an audiobook or send an Outlook email, know that Urvashi was involved with the engineering and teams that made that possible.
Lockdown birthday celebration at home (left to right): daughter Riya, husband Shishir, Urvashi and son Tanish.
Today, she is ADP’s Chief Technology Officer, taking on that role in 2019. “I had no idea that I would be a CTO three years ago,” she says. “I didn’t plan it. I try to live in the moment and put all my energy into what I am doing and the problems I am working to solve. That drives the next things that happen.”
Urvashi’s approach is to make sure she is always learning and delivering in her role. “While the foundations of engineering and technology may not change that often, the applications are evolving constantly,” she says. “The only way to keep up is to be a lifelong student.”
It’s also essential to understand your own value to the organization. “Always know how the work you do will impact the company’s bottom line and how your work is adding value and taking the company forward.”
This can be challenging for women of color who often experience more scrutiny of their work, more criticism, and less credit for their accomplishments. “The one area where I have experienced unconscious bias is with criticism,” Urvashi says. “I have to listen carefully and know when the feedback is genuine and when it is more about the person giving the feedback. When I understand that, I can embrace the situation and not take it personally.”
Urvashi’s best advice is to live in the moment. “Things don’t have to be planned or the way you think they should be. Show up, keep learning, and often it works out better than you could have imagined.”
Ready for more?
Related Video: How ADP Walks the D&I Talk
One way ADP encourages diversity and inclusion (D&I) among its associates is through business resource groups (BRGs). ADP’s iWIN BRG is the company’s largest with 5000+ members (male and female) from 19 countries across the business. Learn how iWIN engages, equips and empowers its members to achieve personal and professional success through networking, professional development, and other educational opportunities.
ADP Business Anthropologist Martha Bird sat down with Daniel Litwin, the Voice of B2B, at CES 2020, discussing a wide range of topics related to how her anthropological work and research impacts businesses and consumer needs.
Bird has worked for numerous companies in the field of business anthropology since the early 2000s, working to create human-focused solutions to business needs.
Bird and Litwin touch on their CES experience, a modern focus on human-centered and human-responsive products and how those concepts affect consumer product development, consumer longing for personalized experiences, and more.
By SPARK Team
It’s not enough to have a lot of data and some good ideas. The quality, quantity and nature of the data is the foundation for using it effectively.
We asked members of the ADP® DataCloud Team to help us understand what goes into selecting, gathering, cleaning and testing data for machine-learning systems.
DataCloud Team: The first thing to figure out is whether you have the information you want to answer the questions or solve the problem you’re working on. So, we look at what data we have and figure out what we can do with it. Sometimes, we know right away we need some other data to fill in gaps or provide more context. Other times, we realize that some other data would be useful as we build and test the system. One of the exciting things about machine learning is that it often gives us better questions, which sometimes need new data that we hadn’t thought about when we started.
Once you know what data you want to start with, then you want it “clean and normalized.” This just means that the data is all in a consistent format so it can be combined with other data and analyzed. It’s the process where we make sure we have the right data, get rid of irrelevant or corrupt data, that the data is accurate and that we can use it with all our other data when the information is coming from multiple sources.
A great example is job titles. Every company uses different titles. A “director” could be an entry-level position, a senior executive, or something in between. So, we could not compare jobs based on job titles. We had to figure out what each job actually was and where it fit in a standard hierarchy before we could use the data in our system.
DataCloud Team: There’s a joke that data scientists spend 80 percent of their time cleaning data and the other 20 percent complaining about it.
At ADP, we are fortunate that much of the data we work with is collected in an organized and usable way through our payroll and HR systems, which makes part of the process easier. Every time we change one of our products or build new ones, data compatibility is an important consideration. This allows us to work on the more complex issues, like coming up with a workable taxonomy for jobs with different titles.
But getting the data right is foundational to everything that happens, so it’s effort well spent.
DataCloud Team: We are extremely sensitive to people’s privacy and go to great lengths to protect both the security of the data we have as well as people’s personal information.
With machine learning we are looking for patterns, connections or matches and correlations. So, we don’t need personally identifying data about individuals. We anonymize the information and label and organize it by categories such as job, level in hierarchy, location, industry, size of organization, and tenure. This is sometimes called “chunking.” For example, instead of keeping track of exact salaries, we combine them into salary ranges. This both makes the information easier to sort and protects people’s privacy.
With benchmarking analytics, if any data set is too small to make anonymous ― meaning it would be too easy to figure out who it was ― then we don’t include that data in the benchmark analysis.
DataCloud Team: The essence of machine learning is more data.
We want to be able to see what is happening over time, what is changing, and be able to adjust our systems based on this fresh flow of data. As people use the programs, we are also able to validate or correct information. For example with our jobs information, users tell us how the positions in their organization fit into our categories. This makes the program useful to them, and makes the overall database more accurate.
As people use machine-learning systems, they create new data which the system learns from and adjusts to. It allows us to detect changes, see cycles over time, and come up with new questions and applications. Sometimes we decide we need to add a new category of information or ask the system to process the information a different way.
These are the things that both keep us up at night and make it exciting to show up at work every day.
Since Lifion’s inception as ADP’s next-generation Human Capital Management (HCM) platform, we’ve made an effort to embrace relevant technology trends and advancements. From microservices and container orchestration frameworks to distributed databases, and everything in between, we’re continually exploring ways we can evolve our architecture. Our readiness to evaluate non-traditional, cutting edge technology has meant that some bets have stuck whereas others have pivoted.
One of our biggest pivots has been a shift from self-managed databases & streaming systems, running on cloud compute services (like Amazon EC2) and deployed with tools like Terraform and Ansible, towards fully cloud-managed services.
When we launched the effort to make this shift in early 2018, we began by executing a structured, planned initiative across an organization of 200+ engineers. After overcoming the initial inertia, the effort continued to gain momentum, eventually taking a life of its own, and finally becoming fully embedded in how our teams work.
Along the way, we’ve been thinking about what we can give back. For example, we’ve previously written about a node.js client for AWS Kinesis that we’re working on as an open source initiative.
AWS’s re:Invent conference is perhaps the largest global cloud community conference in the world. In late 2018, we presented our cloud transformation journey at re:Invent. As you can see in the recording, we described our journey and key learnings in adopting specific AWS managed services.
In this post, we discuss key factors that made the initiative successful, its benefits in our microservice architecture, and how managed services helped us shift our teams’ focus to our core product while improving overall reliability.
The notion of services sharing databases, making direct connections to the same database system and being dependent on shared schemas, is a recognized micro-service anti-pattern. With shared databases, changes in the underlying database (including schemas, scaling operations such as sharding, or even migrating to a better database) become very difficult with coordination required between multiple service teams and releases.
As Amazon.com CTO Werner Vogels writes in his blog:
Each service encapsulates its own data and presents a hardened API for others to use. Most importantly, direct database access to the data from outside its respective service is not allowed. This architectural pattern was a response to the scaling challenges that had challenged Amazon.com through its first 5 years…
And Martin Fowler on integration databases:
On the whole integration databases lead to serious problems becaue [sic] the database becomes a point of coupling between the applications that access it. This is usually a deep coupling that significantly increases the risk involved in changing those applications and making it harder to evolve them. As a result most software architects that I respect take the view that integration databases should be avoided.
Applying the database per service principal means that, in practice, service teams have significant autonomy in selecting the right database technologies for their purposes. Among other factors, their data modeling, query flexibility, consistency, latency, and throughput requirements will dictate technologies that work best for them.
Up to this point, all is well — every service has isolated its data. However, when architecting a product with double digit domains, several important database infrastructure decisions need to be made:
When we first started building out our services, we had a sprawl of supporting databases, streaming, and queuing systems. Each of these technologies was deployed on AWS EC2, and we were responsible for the full scope of managing this infrastructure: from the OS level, to topology design, configuration, upgrades and backups.
It didn’t take us long to realize how much time we were spending on managing all of this infrastructure. When we made the bet on managed services, several of the decisions we’d been struggling with started falling into place:
On our Lifion engineering blog, we’ve previously written about our Lifion Developer Platform Credos. One of these speaks to the evolutionary nature of our work:
When we started adopting managed services, we went for drop-in replacements first (for example, Aurora MySQL is wire compatible with the previous MySQL cluster we were using). This approach helped us to get some early momentum while uncovering dimensions like authentication, monitoring, and discoverability that would help us later.
Our evolutionary architecture credo helped to ensure that the transition would be smooth for our services and our customers. Each deployment was done as a fully online operation, without customer impact. We recognize that we will undergo more evolutions, for which we intend to follow the same principles.