« All Blogs

Urvashi

Women in STEM Profile: ADP’s CTO, Urvashi Tyagi

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.”Urvashi-profile-pic

Urvashi Tyagi

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.

Urvashi-With-family

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?

Explore the stories of these and other ADP Women in STEM, and learn about careers at ADP.

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.

« All Blogs

ADP speakers at CES

Creating human-focused solutions in today’s product strategy

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.

« All Blogs

Close up of lights on computer devices in server room

How to select, gather, clean, and test data for machine learning systems

https://explore.adp.com/spark3/how-data-becomes-insight-the-right-data-matters-454FC-31577B.html

 

How Data Becomes Insight:

The Right Data Matters

By SPARK Team

What goes into selecting, gathering, cleaning and testing data for machine-learning systems?

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.

Q: How do you go from lots of information to usable data in a machine-learning system?

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.

Q: This sounds difficult.

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.

Q: If you are working with HR and payroll data, doesn’t it have a lot of personal information about people? How do you handle privacy and confidentiality issues?

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.

Q: Once you have your initial data set, how do you know when you need or want more?

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.

 

 

Learn more by getting our guide, “Proving the Power of People Data.”

« All Blogs

Person on ladder reaching up into the clouds

Lifion at ADP’s cloud transformation journey

https://eng.lifion.com/lifions-cloud-transformation-journey-2333b7c0897d

 

Lifion’s Cloud Transformation Journey

On moving to managed services in a microservice architecture

Zaid Masud
Zaid Masud

Mar 26, 2019 · 5 min read

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.

Why Services Don’t Share Databases

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.

The Right Tool for the Job

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:

  • Shared vs dedicated clusters: Should services share database clusters with logically isolated namespaces (like logical databases in MySQL), or should each have its own expensive cluster with dedicated resources?
  • Ownership: What level of ownership does a service team take for the deployment, monitoring, reliability, and maintenance of their infrastructure?
  • Consolidation: Is there an agreed set of technologies that teams can pick from, is there a process for introducing something new, or can a team pick anything they like?

From Self-Managed to Fully Managed Services

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:

  • Shared vs dedicated clusters: Dedicated clusters for services, clearly preferable from a reliability and availability perspective, became easier to deploy and maintain. Offerings like SQS, DynamoDB, and Kinesis with no nodes or clusters to manage removed the concern altogether.
  • Ownership: Infrastructure simplification meant that service teams were able to develop further insight into their production usages, and take greater responsibility for their infrastructure.
  • Consolidation: We were now working with a major cloud provider’s service offerings, and found that there was enough breadth to span our use cases.

Evolutionary Architecture

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:

  • Build to evolve: We design our domains and services fully expecting that they will evolve over time.
  • Backwards compatible, versioned: Instead of big bang releases, we use versions or feature flags letting service teams deploy at any time without coordinating dependencies.
  • Managed deprecations: When deprecating APIs or features, we carefully plan the impact and ensure that consumer impact is minimal.

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.

« All Blogs

Manjula Ganta Headshot

ADP Women in STEM Profile: Manjula Ganta

Manjula’s mantra: “Don’t focus on fitting in; figure out how to stand out.” After reading about her hard work, success and leadership, you’ll see Manjula walks the talk — and encourages others to do the same.

Growing up, Manjula Ganta wanted to be a doctor. She loved science and biology and was fascinated by how the body works as a machine. But med school was financially out of reach, so she chose a career in mathematics. Manjula’s mother encouraged her and her sisters to learn computers.

“My mother was a visionary and could see technology evolving even before the internet existed,” Manjula said. “From her experiences and struggles as a homemaker, forgoing a job opportunity due to culture constraints, my mom inspired her four girls to be independent and encouraged us to pursue our careers. She is the greatest influence on who I am today.”

From India to Omaha

Manjula grew up in a small town in southern India near Hyderabad. In school, she was very outgoing, smart, and well-rounded – a trait she carried into adulthood and her career. Manjula pursued a bachelor’s degree, majoring in mathematics. She simultaneously enrolled into a Diploma in Systems Management program that introduced her to computers. Manjula later earned her MBA with a major in finance, and graduated as class valedictorian.

She moved to Hyderabad to work for a financial services company as a management trainee. Manjula was quick to learn the intricacies of the business and even as an intern courageously presented her ideas. Soon she had an opportunity to design the development of an integrated app to better manage the company’s branch reports. “Curiosity and rapid technology changes led me to learn relational databases and the integrated enterprise application software,” Manjula recalls.

A few years later, Manjula married her high school sweetheart, who had moved to Omaha, NE. She moved from Hyderabad to Omaha, and they started a family. “It was a big adjustment for me, both culturally and professionally,” Manjula said, “and it took a while to figure out how to balance my career and family.”

Manjula began working in Boston as a Peoplesoft consultant for the state of Massachusetts, going home only every couple of weeks. “It was a very challenging time in my life, being a young mother with a traveling job – staying away from home and my toddler son,” she recalls.

Manjula then worked as a Peoplesoft technical consultant for a project with General Electric (GE) in New York in variety of roles. She successfully implemented various Peoplesoft modules, leading offshore teams. After a few years, Manjula’s husband took a new job and they moved to Atlanta, where she continued to work with GE remotely.

Have grit and break your own expectations – expectations can be a weight on your shoulders.

– Manjula Ganta, Director of Application & Development, GPT

After her nine-year project at GE, Manjula joined ADP National Accounts Services (NAS) Outsourcing (COS) division as a senior business systems analyst. “It was a big shift going from development to a business systems analyst role,” Manjula recalls. “I would still get into the code and give the developers inputs about the issues.” She laughingly added, “I think they got frustrated sometimes, but it also helped improve our communication.”

Manjula’s role soon expanded to managing the same development team across analytics, robotics process automation (RPA) and other web/cloud tools and technologies, and she was tasked with managing diverse virtual teams as a single global team. “I was responsible for helping the team see and execute the vision, removing any roadblocks and partnering with other leaders to make it successful,” she recalls. Manjula’s ability to combine business acumen and technical competency, along with her pragmatic approach, enabled her to be decisive and impactful across the COS business.

Manjula then became the Director of Strategic Initiatives for the NAS Tools & Technology Operations, where she worked on several technology and transformation initiatives to develop, support, and enhance ADP’s internal and client-facing tools.

Manjula says she’s taken this approach throughout her career: “As a thoughtful leader, I strive to create a positive and collaborative work culture with emphasis on employee recognition – helping teams to look beyond their differences. Celebrating associate birthdays, work anniversaries and key project milestones helps everyone feel valued and included.”

Currently, Manjula is a Director of Application Development, Global Product & Technology (GPT), where she takes an even broader responsibility for building ADP’s core products from a technology architecture, design, quality and user experience standpoint, to make them more effective for ADP’s clients.

Developing Self and Others

“ADP has a unique culture in which they put their associates first,” she says. “Prior to ADP, most of my development was self-initiated, but here we have many career development opportunities, mentorship programs, stretch assignments, networking events through employee resource groups, technical workshops, etc. You just need to be motivated and find the time to develop yourself.”

Manjula had the opportunity to enroll in an external Pathbuilders mentorship program. “The program helped me to become more self-aware, building my own personal brand inside and outside of ADP,” she says. Manjula is thankful to the leaders, mentors and sponsors who invested their time by providing her exposure at the business unit level.

Carrying it forward, Manjula helps mentor others at ADP and through various non-profit organizations. She is an active volunteer for Women in Technology based in Atlanta, which helps girls and women succeed from the classroom to the boardroom. Manjula recently joined the ADP GPT Women in Technology Leadership Mentoring Initiative (WiTL) that helps develop a diverse leadership talent pipeline through a formal mentoring program. She also volunteers for the American Heart Association, Special Olympics of Georgia, and leads several ADP business resource group events in the Alpharetta location, creating awareness and raising donations for causes she cares about.

Best Advice

Manjula offers this advice for women starting their careers in STEM: “Have grit and break your own expectations – expectations can be a weight on your shoulders. Don’t be afraid of making mistakes; it’s important to learn. Life is not just about success; it’s also about failure, difficulty, and learning to recover. Focus on the present, stay positive, and keep going.”

Manjula also recommends finding a mentor. “Mentors have helped me realize my worth and have inspired me to speak up, be myself, and encouraged me to take on the next challenge. One of my leaders would say, ‘I wish you had had your voice earlier.'”

“Always find your support system, family, friends or coworkers and don’t be afraid to seek help or delegate,” Manjula said. “You don’t have to be a perfectionist or do it all.”

She is very grateful for her husband, Ranjith, and two sons, Abhitej and Ritvik, who have always supported her career, helped at home, and offered new and different points of view.

“Have fun, no matter how hard things can get. Humor and fun can always make the journey (personal or professional) easier.”

Through all the learning and big changes as an Asian Indian immigrant and a woman in STEM, Manjula’s best advice is: “Don’t focus on fitting in; figure out how to stand out.”

Read about other ADP Women in STEM and learn about careers at ADP.

« All Blogs

Paper boats in a triangular pattern

Being a first time Engineering Leader

“You did a great job as a senior engineer. You are now promoted to a manager to lead the new team that we just formed. Congratulations on your new role!”
It is something on these lines that most people get promoted or at least that is how I remember when I was promoted to a manager. There is nothing fundamentally wrong with promotions such as this. The key though is in recognising that the expectations change when this happens. As we moved up the individual contributor (IC) ladder we learnt to solve harder technical problems. This change in role, though changes the operating field a little. It is in this context that I am listing out a few things that would have helped me transition into my role as a manager better, when I started out.
Transition from a maker to manager schedule
Staying hands on — in other words writing production quality code is a reality for most first time managers making this transition. It is also likely the first time where you end up navigating both kinds of schedules on a daily basis and it is a hard thing to do. Learn to be protective of your calendar. You could do this by:
Blocking your time in the calendar where you need to stay heads down. I’d suggest at least 3 hours at a time and then adjust up or down depending on what is an ideal chunk of uninterrupted time for you to get something meaningful done
Being ever more mindful of how you now schedule time with your direct reports. Just because you have moved onto a different schedule does not mean they should have to. If you are conscious of how you set up these meetings, that is one more thing you are doing for your team
Doing what you can to string your meetings into one contiguous block. Better yet, define your meeting times and agree with your peers. With a little back and forth, this usually works well for everyone and is another barrier for folks who gatecrash into your time with unplanned meetings
If you want to know more about different types of schedules, Paul Graham’s article explains it quite well.
Stay hands on
You are most likely a manager of a team with highly opinionated ICs. You need to be able to have a conversation with them, ask the right questions, pressure test their approach.
Pressure on your time as an IC will only increase as you grow and if you don’t strive to stay hands on, very soon you will find yourself too far from where the action is. You don’t necessarily have to pick up the most critical problem to solve but do what you must to stay relevant and make a meaningful contribution.
Impediment remover, not always a problem solver
After years of being an IC where you are used to solving problems yourself, it can be hard to take a step back.
Be the person who helps your teams get over the hump even if you are not the one who identified the problem or fixed it. Serve the team in the capacity that is best needed at the time and avoid being a seagull manager. With a young team, it could mean leading with a solution while with more mature teams, it could just be about asking the right questions. And in some other cases, maybe it is just carrying pizza!!
Carve out time for career development
A key reason you choose to be a manager is that you genuinely believe that you can have a greater impact on your purpose by developing a strong team. Be interested in each member’s aspirations, be on the lookout for their strengths and biases. Provide timely feedback. Help identify opportunities that will help them hone their newly acquired skills. These are all things perhaps any standard course on “New Managers” will refer to. There are many talks and articles out there to drive home the point that when you can align aspirations with the organisational goals that is when you are likely to have the most impact, but also derive personal satisfaction. Do the most you can to make this a practice.
Bar raiser
You have to do this at every opportunity you get, not just when hiring someone into the team. You have to be the cheerleader during your team’s journey towards excellence. Raise the bar when it comes to technical excellence; be the torchbearer when it comes to upholding your organisations credos and values. Often in the quest for an organisation’s immediate imperatives culture takes a back seat. Protect, sustain and improve your organisation’s culture like your organisation’s life depends on it; because it actually does.
Manage upwards and sideways
Managing upwards or to the side is typically seen by engineers as an ugly part of organizational politics. Other than the typical activities that are required to manage information, the biggest reason to do this is because software development is a collaborative activity. Managing in its purest sense is about aligning priorities across teams. You will be able to achieve your goals better if you can influence your peers to row in the same direction and are aligned with the direction your manager has in mind. At the same time, this is also about course correcting if need be and ensuring people on the impacted teams understand why a correction is better for everyone.
Conclusion
Doing some or all of these things will not turn you into a super manager overnight. I like to compare this to going to the gym. You will not notice any change after your first day at the gym, but keep at it long enough and the results will be clear for all to see.