“The best employees love what they do”, former PepsiCo CEO Indra Nooyi once responding to a crowd of bright-eyed summer IT interns. Quite a simple answer to the question “what do the best employees do, and how can I be like them?”. The more you think about the fast response Indra had given, the more you realize it extends to more than simply ‘what’ we do. As one of those interns, I didn’t quite understand the depth of this statement until I had exposure to different roles later in my career.
Loving what you do is inherently important, yes, but it’s not exactly the single most important aspect to making you an incredible employee. Whether people want to acknowledge it or not, what you do for work becomes part of you. For example, I may have been called a ‘tech bro’ once or twice after being asked what industry I’m in, to which I usually respond: “I’m not fixing your computer”. After the laughter calms down, I usually begin talking about the work I do, and then inevitably, the “are you happy?” question arises. Most people respond fairly quickly, and to varying degrees, but if you stop and think about the rounded picture of happiness at your job, it usually comes down to one thing: personal fulfillment based on the investment of your time. Many concepts can be abstracted from this — work relationships/enjoyment, culture-driven benefits, monetary compensation, societal impact, etc. How many start-ups have you heard say that they’re going to change the world? Have you ever stopped to think about this as a marketing ploy, rather than a vision statement?
We all have different opinions on what’s heavier when it comes to our personal happiness, but I’ve found that one particularly weighs more than others, and that’s culture. From an organizational perspective, culture is tough to get right and easy to ruin, but when fostered correctly can truly breed the best and happiest employees. Culture is something that’s created organically, targeting the basic human desire to belong, fit in, and feel like a contributor to the group. A group that allows for the dynamism of thought, and freedom to express it without judgment, enables each individual to feel heard while allowing the best outcome to become possible. This, in turn, opens up avenues for new and personal discussions between individuals, potentially turning into friendships. When an employee goes into work every morning, considering his/her coworkers to be people he/she looks forward to working with, that’s where the magic happens, and culture is born. Good relationships grow general satisfaction with a person’s environment. Happy employees are much more likely to go out of their way to make the organization succeed, which full circle, makes them a good employee in the eyes of the organization.
How often in pop culture is work-life balance portrayed with someone comically saying “I don’t know any of you outside of work”. Now, full disclosure, I’ve never once heard anyone explicitly say this, but have seen individuals act in this way. This mentality simply doesn’t instill a sense of trust, no matter what organization or industry you work in. Don’t get me wrong, separation is good and healthy to have, but communication is key.
At Lifion, by ADP, we’re in the business of ‘Human Capital Management’, and we understand that if an organization doesn’t manage its resources correctly, the strongest culture won’t prevail. Everyone wants to be treated as an individual, rather than just another employee. No inhuman litmus test for happiness should ever suffice for a one on one, a drink together at happy hour, or a sincere “hey, how are you doing?”.
In summary, you never know the amount of impact you have on someone’s daily work experience. People are more than just resources to get a job done and respond well when treated as an individual. At the end of the day, you can have the best strategy in the world, but with no one to build it, it’s not worth anything. Simply put, whether you are a company, a manager, or a coworker, the best advice I can give: be human.
This inspirational woman in STEM lives by a four-word personal mantra: girls can do anything.
Kanyatta Walker’s unapologetically fearless outlook began when she was only three years old. A boy cast as Santa in her preschool Christmas play did not enjoy being on stage and kept missing lines. Kanyatta offered to step in, but the teachers said she couldn’t because Santa was a boy. When it turned out none of the boys knew the lines and Kanyatta did, the first female Santa debuted in the play. The crowd loved it.
In high school, Kanyatta was interested in occupational therapy and planned to major in it in college. Then she did some aptitude tests with a good friend who wanted to join the marines. The recruiter told her she was excellent at math and could pretty much do anything she wanted – except be an engineer.
Kanyatta graduated from college with a degree in software engineering technology and has never looked back.
“I always loved math,” Kanyatta said. “My aunt was a math teacher and the way she explained it just made sense to me. I love that there is always a precise answer. But there is also always more than one way to get to that answer and lots of trouble shooting.”
She was recruited by Accenture, a multinational consulting firm, where she worked in a variety of roles from sales to program manager and development manager. By 25, she was leading a team with a significant budget. “I learned by trial and error. There was so much I did not know and I made a lot of mistakes. But I also knew that teams are a mirror of their leaders. I worked at a grocery store when I was 16. When it got busy, the managers would leave their office and come help wherever needed. After the store was bought by a chain, the new managers didn’t come out of their office to help. I learned how important it is for leaders to understand what people need and show up for their team.”
As her career progressed, Kanyatta realized that there are multiple roles for leaders too. “It’s like a baseball team,” she said. “There are coaches and general managers. Coaches assemble the teams and knows who to play to bring out their best. The general manager deals with the overall strategy and choosing the right coaching staff to create the win.
“To be an effective leader, you don’t personally have to play every position. When I see something I want to do, I work to understand the underlying skills. I see how to unravel things and figure out what I know, what I need to know, and how to learn the skills I need. With core skills and ability, you can do anything.”
The desire to understand executive strategy led Kanyatta to an MBA program at Emory University while she was still working full time leading product managers, business analysts and program managers for a large telecom company. She discovered the perfect combination of math and business in her finance courses. “I can look at a company’s finances and tell you what their strategy is,” she said.
Coming to ADP
After finishing her MBA, a friend helped recruit Kanyatta to ADP in Atlanta. She was excited at the opportunity to combine her business skills with her software engineering experience. She started out as Vice President of Operations working in National Accounts on outsourcing operations. Today, Kanyatta is Vice President of Global Product and Technology – Client Product Support, where she leads teams providing product and technical support for ADP’s business units and clients.
“I love the ability to transform here. As the company is transforming, so are the opportunities for people within the company and our clients to grow. I love helping people connect the dots and see where we are going from process to technology to culture, Kanyatta said.
“I also appreciate seeing women executives at ADP and how women help each other here. I met ADP business unit presidents Debbie Dyson and Maria Black within my first six months, and they always find time and make themselves available to help others.”
Helping others succeed
Kanyatta is also committed to helping others grow and achieve their dreams. She is involved in Women in Technology International and Emory’s Executive Women of Goizueta —while also mentoring and coaching rising leaders in her role at ADP. She loves helping women figure out what they want and how to get there.
“Connecting with others can be scary, but it’s important so you can understand the playing field,” Kanyatta said. “You have to lift your head up to see and for people to see you. There’s no way for people to know how amazing you are if your head is down all the time.
“There are not many women of color in tech, so I always try to say yes when people ask me to speak. It’s important to build bridges and for younger women to see people who look like them doing the things they want to do.”
Kanyatta is quick to say that she does not do it all alone. Her husband is very supportive and encourages her to connect with others and volunteer. Together, they manage a busy family schedule with their 12 year old daughter who is playing softball on a traveling team. “I love being a softball mom and spending time with my family,” she said.
Kanyatta, Kya and Kevin Walker enjoying time as a softball family.
Kanyatta’s advice to others
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.
There is nothing quite like the existential dread of realizing you may have a performance issue. Months, possibly years, worth of codebase are suddenly now failing you in a live environment. Reproduction is difficult, and even if you can reproduce it on your dev machine your usual methods of debugging are likely useless. Sure, you can litter your code with entirely too much analytics, or leverage Node’s own profiling, but this results in a data hose that takes a deep understanding of Node, V8, and data science itself to make sense of it. This is a rather dire situation.
A common scenario in any service is you may have some asynchronous operation that you need to perform on a data set of unknown length. Your first instinct may look something like this:
You quickly discover that this is not very fast. Simple interrogation of CPU utilization will show Node is spending a lot of time waiting. Depending on your lint rules, you may not even be able to get this code past a CI build. The solution for many is to simply fire all the promises then await all of them. That, in and of itself, is not a bad thing; for example, say you know that every time you execute a given route, you need to make 3 unrelated calls to other services. Since you know it will always create 3 promises, this is bounded and safe. The problems arise when the promise creation is potentially unbounded.
You test your code and discover it is much faster, Node is not spending time waiting around, and the lint error is gone. You merge and deploy your code, all the integration tests pass, and you go home to watch The Expanse. Suddenly, right when the Rocinante (a legitimate salvage) is entering a tense battle, you start getting PagerDuty alerts. Your services containers are getting restarted constantly due to Out of Memory exceptions, the container host is experiencing socket exhaustion, and your response times are through the roof. You have a major performance and scalability issue.
This is a nice clean scenario, so the suspect code is easily identified, but what if it isn’t? Why does this code fail to scale? This is where Clinic.js shines. For the sake of exercising Clinic.js, I created 6 scenarios that all perform the same asynchronous work some n times using different strategies. They are using for…of, the new ES2018 for await…of, the Promise.all() scenario described above, using Bluebird.map() with a concurrency limit set, the promise-limit module, and the p-limit module.
For the test, I start a clustered web server that accepts a get and post request. Both verbs will perform some arbitrary work before completing the request. In the test itself, I get the data, do arbitrary work, and post the results back. In both cases the work is primarily parsing JSON and manipulating the object in an attempt to simulate a common Node workload. Each test run does this work 500 times, for each element in a mock collection. For the limiting modules, they are all set to allow 10 concurrent promises. All tests were performed using Node v12.14.0. The average execution times over 10 test runs can be seen below.
╔═══════════════╦══════════════════════════════════╗ ║ Test ║ Average Execution Time (Seconds) ║ ╠═══════════════╬══════════════════════════════════╣ ║ await-for-of ║ 6.943 ║ ║ bluebird-map ║ 4.550 ║ ║ for-of ║ 6.745 ║ ║ p-limit ║ 4.523 ║ ║ promise-all ║ 4.524 ║ ║ promise-limit ║ 4.457 ║ ╚═══════════════╩══════════════════════════════════╝
The results here certainly reflect the performance improvement when going from for…of to issuing concurrent promises, but the limiting libraries have similar execution times. Let’s dive deeper into what is going on.
In the for await…of and for..of scenarios (respectively), the CPU utilization is bouncing around and is averaging well below 100%. This means the Node process is spending a lot of time waiting around. The execution time is also non-ideal at roughly 7 seconds averaged over 10 runs. Clinic detects this and reports a potential I/O wait issue bottlenecking the process. It recommends running a ‘bubbleprof’ to better identify the issue.
Note the light blue segment in the graph, this represents network I/O waits. It is spending quite a bit of time waiting for network operations. Perhaps we can speed this up by issuing them concurrently.
In the Promise.all() scenario, execution time has improved dramatically to 4.5 seconds on average. The CPU is now being efficiently utilized. However, notice the memory usage spiking up much higher with incredibly high event loop delay. Clinic detects this issue and reports a potential event loop issue. Why is this?
As you can see, the promise callback is invoked first, then it executes to the end of the block. Only after that do the `then` blocks fire. This, however, is only part of the story.
In the case of the Promise.all() code above, it will create a request for every item in the collection before any `then` block is resolved. This is true even if the early requests complete before it reaches the end of the collection. It will not process the responses until the event loop ticks over. This is due to I/O callbacks not being invoked until the event loop ticks into its I/O phase. It is only at this point `.then()`, or the code block proceeding `await`, is executed.
Ultimately the creation of an unbounded number of promises will result in all of the response objects becoming queued in memory and waiting for the event loop to tick over. This can swamp the Node process with excessive memory allocations, or worse, cause out of memory events. When these objects go out of scope, it will freeze up when the garbage collector executes as it is primarily a blocking, O(N) operation. It also means when the event loop finally does tick over, all of the `.then()` callbacks of completed requests fire synchronously. If this contains heavy work, the event loop will be stuck in the callback phase until this work is completed or another truly asynchronous operation is encountered. This means any events, inbound requests, timers, etc. will not be handled until the ‘.then()’ callbacks are all completed. The biggest concern here is that response times can spike to several seconds. To solve this, we need to limit the number of concurrent promises created.
As indicated in the graphs, Bluebird.map() with a concurrency limit pretty much eliminates the event loop blocking and the high memory usage while maintaining efficient CPU utilization. It matches the performance of Promise.all(), completing the test in 4.5s. Bluebird however has lost its performance edge in recent versions of V8 when compared to native promises and is a rather heavy complete Promise replacement. Let’s consider some other native promise options.
The promise-limit module also resolves our issue, and against matches the performance of Promise.all() at 4.5s. This is due to the aforementioned pressure on Node’s memory system creating unnecessary memory allocations and complex garbage collection events. The overhead of this module does get flagged by Clinic.js as creating some event loop blocking. It notably also is nowhere near as popular as the last module, p-limit.
The p-limit module has the least amount of event loop blocking of all the options, while providing the same performance as Promise.all() at 4.5s. Given the popularity compared to promise-limit and the performance of this module, this is the clear winner.
Clinic.js enables introspection into how your Node application is performing beyond simple top line execution times. It introspects not only your resource utilization, but what the code itself is doing. By no means have I explored all the capabilities of this tool here, however it grants us insight into why a specific codepath may appear to perform without issue on its own, but wreak havoc inside of a live service. NearForm presented this to us during Node Day 2019 and it has quickly become an indispensable debugging tool for us. Its ease of use and clear presentation helps not only quickly identify problematic code, but also convey the “why” to others who are not deep into the debugging process with you. It was the obvious choice to illustrate the issues with unbounded promise creation.
“Finding commonalities and accepting differences is the key to belonging,” said ADP’s business anthropologist, Martha Bird.
When I started to consider belonging at work, I knew exactly who to call — ADP’s business anthropologist, Martha Bird [MB]. Here’s some of our conversation about why belonging matters and what organizations can do to create and sustain a culture of belonging.
HB: Having a sense of belonging seems so important to how we move through the world and how we relate to our work. What is belonging?
MB: Belonging almost strikes people as poetic. It seems like a feeling, so it can resist the critical lens we need to unpack it.
People think of belonging as a psychological state, but it is actually cultural. It’s the notion of being inside or outside and relates to enacted phenomena like what the cultural norms are around us and how we compare ourselves to those norms.
Everything cultural is nested in other things and is influenced by power, resources, how things have been done in the past, and what the expectations are for the people involved.
Kids can feel like they don’t belong because of their clothes. New employees can feel like they don’t belong because of the jargon used in the organization. I’m a social scientist surrounded by tech people and it’s not surprising that my sense of belonging is tested from time to time. Ultimately, I’m privileged to feel I’m part of something bigger than myself.
HB: What makes a culture of belonging? It seems like belonging is relational. It’s partly how I perceive the circumstances and culture, how people already in that culture see it, and what’s actually going on regardless of our individual perceptions and opinions.
MB: There are so many ways to feel like you don’t belong — socially, economically, intellectually, emotionally. It’s that sense of other. To make sense of it, we can look at othering, break it down, and pick it apart to see what’s happening. We identify the discreet instances where someone feels alienated and read the cultural cues about what is happening. This gives us information about the culture.
There is no universal recipe for what makes a healthy culture. There are many good and right ways to do things.
It partly has to do with a culture’s view of the individual and how the individual should relate to others. In the United States, belonging often evokes family, but we also have strong cultural values in individuality and being recognized and valued as an individual. In other cultures, a sense of harmony is highly valued and working toward common goals is more important than individual achievement.
A culture of belonging fundamentally has to do with common goals and values, respect for each other, and a sense of our shared humanity.
HB: How can we help people feel like they belong at work?
MB: We want workplaces where people feel like they can be themselves, but are also working with others to do the work. It’s less about fitting in and more about complementing. There has to be room for difference. It’s like an orchestra where the manager is the conductor and we have all these different instruments playing different parts in the same piece of music. We don’t want just the violins or the tubas. We need all the different sounds, rhythms and harmonies.
Belonging at work starts with leaders modeling the values and behavior for their teams. Is it comfortable to embody those values? Sometimes that means being vulnerable and asking for help.
I recently gave a big speech to a large group of people in a setting where I felt anxious. Walking up to the stage, I decided to tell the audience that and ask for help. So I explained how I was feeling and asked them to tell me, “It’s okay, Martha!” It was great, so I asked them to do it again. And they did! I felt so much better and they were all on my team at that point, because I was vulnerable and asked them to help me in a way they could.
In cultures of belonging, it’s okay to be honest about what’s going on, even if it’s that you don’t feel included.
HB: What are some specific things that managers or leaders can do to foster belonging at work?
MB: At the organizational level, it’s essential to ensure that the values of the organization exist at every level and in every manager without exception. It’s also important to consider how to structure teams and make sure they can communicate effectively, based on where and how people work.
At the team level, good manager training is key. Managers need skills in working with teams, allowing for different views, and figuring out how to handle disagreements and how decisions get made. When people can weigh in on something, there is a sense of being in it together.
It’s important to see each other as people, not work roles. Connecting in person and outside of work makes a difference. We need to tell and know each other’s stories and create opportunities for sharing. Have lunch, have informal video meetings where everyone gets to tell something about themselves. I was in a meeting recently where we all told the story of our names. I learned a lot and felt like the people who heard my story knew me a little better, too.
We need more awareness and cultural consciousness by design. People are fundamentally creative and want to learn. We all have different experiences and different lives.
Finding commonalities and accepting those differences is the key to belonging.