https://medium.com/feed/xandr-tech

One afternoon, I was asked to speak to a visiting class of engineering students about what it was like to be an engineer. I found myself in an open meeting space in our office (remember when we met in offices?) surrounded by kids in their late teens and early twenties. I was not sure what to say. My coworkers seemed confident, so I pretended to be too. I figured I could tell them something valuable about my experience that they could take away, maybe something they did not already know that would spark their interest in a similar career. I did not expect they would change me. They caught me off guard and blew me away with their questions and stories about their school projects. Their eloquence was extraordinary, and their questions were on point, sharp, and articulate. Their maturity was impressive; I certainly did not think and talk like that when I was their age.

That night ended filled with emotions. I was inspired and hopeful for the future of our industry. My heart was racing, and I was so happy that I had been pulled into the meetup. It would take another year before I collaborated for the first time with The Marcy Lab School. Those students, the first cohort to graduate from the Marcy program, will always remain dear in my memory. They, however, were not an exception. Every group to graduate from this alternative school is as remarkable as the previous, if not more.

The Marcy Lab School is “an alternative to traditional higher education for students who face financial barriers or for those who are simply looking for a unique experience better suited to their interests,” offering tuition-free instruction for high-achieving young adults from underserved backgrounds to prepare them for careers in software engineering.

What this means for students is the opportunity to graduate debt-free and go on to make over $100K a year, working with companies that collaborate with Marcy to improve their curriculums and provide internships, apprenticeships, and direct-to-hire opportunities. They get a top-notch education without paying a cent — an education tailored to their needs, their interests, and the opportunities they will have upon graduation.

The Marcy mission is “to create an alternative pathway to wealth-generating technology careers for young adults from underestimated backgrounds.” They achieve this by leaving no student behind and providing an amazing student-to-teacher/mentor ratio, offering a ratio of 1:20 vs. the 1:5000 average of public college computer science programs. The classes are small, and the study groups are even smaller. They leverage peer-to-peer mentorship, with more senior students paired with newer ones. It is common to see Marcy graduates paying forward this opportunity as volunteers, mentors, and teachers. Those who struggle with concepts or practice get more attention, not less (like they might in a traditional college). With this strategy, they help everyone realize their potential.

The Marcy Lab School curriculum is far from a boot camp format. They divide the day for their fellows into engineering classes, labs, and leadership and workforce readiness classes. They go deep into computer science essentials that you could find in CS classes at a traditional college, then apply that to tools we use in our day-to-day engineering tasks at our Xandr offices (and probably yours, too).

The co-founders, Reuben Ogbonna and Maya Bhattacharjee-Marcantonio, are inspiring. You talk to them and are immediately drawn to their energy and the culture they’ve created at the school. Reuben and Maya were teachers who got fed up with the state of education, its level of support, and the economics of the overall educational system. So they set out to change it. Now they have an equally passionate supporting staff and an inspiring student body.

As an engineering lead, I often think about the meaning of equity and inclusion. Not as labels and figures to meet our annual goals, but as true measures of creativity and ingenuity. Working with Marcy means reaching into a diverse pool of engineers that are ready to pay forward the opportunities they found through the school’s program. We want to help the school expand, and then continue its mission by bringing their fellows into the workforce of a company that values many of the same principles.

Xandr, part of Microsoft Advertising, has embraced the value of giving back through donations and volunteering. Microsoft has a long history of philanthropy, reflected in its mission “to empower every person and every organization on the planet to achieve more.” Through its corporate matching program, Microsoft matches employee time and money to help others advance, fighting financial and racial inequality. Our company’s values align with Marcy’s mission. Our people’s values do, too.

At Xandr, we have a “teach and learn” culture because we understand that a great way to learn is by teaching others. We believe in giving people time to absorb the complexities of our systems and business when they join us and asking them to teach their learnings back to the group, often improving our own onboarding materials. This process is similar to how Marcy works with their fellows, listening to their graduates to adapt their curriculum to the changing needs of the tech world.

It is only fitting that our teach-and-learn culture would make us a great candidate to have a strong partnership with Marcy. Earlier this year, we became a sponsor for Marcy’s Summer Social, where we joined them in celebrating the graduation of their 2021 cohort. There our love affair started, and we hit the ground running. We arranged for a group of volunteers from our engineering organization and other groups in the company to become mentors to the Marcy Fellows.

Each of our volunteers donates their time by meeting with a student throughout the school year, helping them navigate the hurdles of becoming an engineer ready to join the workforce. Some of them will also help during the interview process to select future cohorts. They also hold mock interviews, where current students can face technical and cultural panels in preparation for their job search.

Our volunteers do this because they care. It’s the same care that drives The Marcy Lab School, and the reason why equity and inclusion are important. We should care about everyone and take action to lift them up in ways that inspire them to lift others in turn.

For us, this is just the beginning. The partnership between Xandr and Marcy Lab is off to a great start, and we hope to add more volunteers next year. If what I’ve said resonates with you, know that you can help with very little time or money, and that your volunteer efforts could positively shape the future of our industry. I go back to that afternoon in my office’s kitchen often, and I hope that those incredible graduates are in some of your offices today, adding value, being amazing human beings, and changing the culture of engineering for good. I’m proud to have known them, and I’m excited to see what each subsequent cohort will bring to our industry.

Xandr and The Marcy Lab School was originally published in Xandr-Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Being a software engineer is scary. We are surrounded by some of the world’s most talented, intelligent minds, solving complex problems with constantly evolving technology. As a new engineer, it’s easy to get overwhelmed by the intimidating skills of our brilliant peers and the ever-changing technology we are expected to master.

I started my career as a professional software developer right before I turned 30. I am self-taught, mostly learning to code through online tutorials, making video games, and a scattered amount of introductory computer science courses. My coding background left me feeling inadequate, constantly behind my peers, and thinking I would never achieve the status of being a real software engineer. Thankfully, I didn’t let that stop me.

In this article, I hope to offer insights about overcoming hurdles as a new software engineer and practical solutions to fighting the fear of never being good enough. To do this, let’s start by looking at a few problems commonly seen in our field.

Imposter Syndrome

Most of us have heard of imposter syndrome. You know the feeling: somehow, despite all your successes, your portfolio of past work, and getting through an intense set of interviews, you are stuck feeling like you don’t belong — that you aren’t skilled enough to be a real developer. I often find myself doubting my ability to accomplish a task, especially when I’m unfamiliar with the technology or an aspect of a codebase. However, time and time again throughout my career, facing these challenges head-on has helped me overcome these feelings of self-doubt, and I remind myself of this whenever these feelings creep back into my mind.

Imposter syndrome plagues even the most talented engineers, and it’s understandable. Our career path forces us to constantly learn new things; for many of us, this can feel like we are forever trapped in beginner-land. The fact is, however, that this is what we signed up for. We are here because we love solving problems and we love learning new technology. If we embrace this reality, we can dispel the myth of inadequacy that imposter syndrome makes us believe, and realize the beginner’s mind is an asset that will help us overcome the many challenges we regularly face in our profession.

The Dunning-Kruger Effect

Imposter Syndrome can be explained, in part, by the Dunning-Kruger effect — a cognitive bias where an inexperienced person may perceive their ability to be higher than their performance, while an experienced person perceives their ability to be lower than it is. Another way of putting it: the less you know about something, the more you think you know, and the more you know about something, the less you feel you know. Sound familiar? It is impossible for a software engineer to know everything there is to know about a given topic. This can make us feel inadequate; that there is so much to know that we really don’t know much at all! Many of us feel imposter syndrome because we are experienced enough to know—in the grand scheme of software development—we don’t know that much, and that’s ok! So, how do we combat imposter syndrome and accept that our place on the Dunning-Kruger curve is actually a good thing? Start with your ABCs.

ABC — Always Be Coding

The best way to overcome imposter syndrome is trivial: write code as often as you can. Our coding brain is like a muscle, and we must use it often to help it grow stronger. This can sometimes be a challenge due to family circumstances, mental health, or a variety of other factors. The good news is if you have a job writing code already, you can gain confidence and experience just by going to work and focusing on your tasks. For a new engineer, this might not feel like enough, so it’s important to prioritize learning outside of work hours if you can. Don’t just do work after hours for the sake of it, though, unless you are still learning the fundamentals and need the extra time.

Instead, spend some time doing something fun with code. Create a website and experiment with CSS you wouldn’t use in business-grade software, recreate Wordle with your own twist, or use your raspberry pi for home automation. I enjoy game development, so I often tinker with new game engines or participate in game jams. I also have a large backlog of web development Udemy courses that are applicable to work, and I try to always have one of those courses in progress. The key is to flex your coding muscles regularly, solving unique problems that will help you learn to overcome new challenges and build your confidence.

Learn how to read code

While it may not feel as productive as putting fingers on keys, being able to read and comprehend code is arguably more important than writing it. As a software engineer, you must be able to quickly understand code you didn’t write, whether it is reading the documentation for your framework of choice, reviewing a teammate’s pull request (PR), or extending an existing codebase. Reading code is not like reading a book; it requires you to jump around the codebase to understand the full story, keeping many different ideas in your head at once. As you get better at reading code, you’ll start to see patterns that will help you discern what is important to investigate and what can be left for later. You will come to know the cost of writing confusing code and will start fully thinking through problems, breaking them down into easily digestible chunks which will result in writing better, cleaner, easier-to-understand code.

How do you get better at reading code?

• Always have a software book you are reading through. Some good starter books are Clean Code by Robert C. Martin, The Pragmatic Programmer by David Thomas and Andrew Hunt, and The Missing README by Chris Riccomini and Dmitriy Ryaboy.
• Find a blogger in your tech stack that you like and read their posts regularly. One of my favorites is Scott Hanselman’s blog.
• Pull down an open-source library and get it running locally, set some breakpoints, and investigate the flow of execution. Not sure what open-source library to look at? Check out this list of great libraries by topic on GitHub and choose something that interests you.
• Spend solid, focused time reviewing your team’s PRs, especially those coming from more experienced engineers on your team. Don’t just hit the approve button after a few minutes of scanning through the PR; dedicate some quality time to fully understand the change and ask clarifying questions along the way. You’ll learn a ton doing this.
• Periodically go back and read code that you wrote. See if you can understand it and think through how you could write it better now.

There are many ways to become better at reading code, and just like writing it, the more you practice the better you’ll become.

On-the-job tips:

• Say yes, often — One of the biggest boons to my career development has been volunteering often for a variety of work, especially if it relates to something I don’t know much about. At my first development job, we had a small development team that supported over a hundred applications, many of which were old and hadn’t been touched by any current employee. When we received a customer request to modify one of these applications, I would often volunteer to handle these requests because no one else knew about these programs and it gave me a chance to learn something new and add value to our team. Eventually, I gained a ton of domain knowledge on applications we weren’t very familiar with. I was able to share this with the team and put myself in a position where I was the go-to developer for many applications.
  
  While it can be scary attempting to deliver on a ticket or project you have little experience with, they are great learning opportunities. You may have to interact with people you don’t know, expanding your network within the company and building connections that will make the next time easier. You are also put in a position where you get to become the subject matter expert on something, which makes you valuable to the team and able to help others who haven’t worked on the thing you just delivered. This is a great technique to squash imposter syndrome quickly, forcing you to overcome obstacles regularly and building your confidence by giving you considerable experience.
• Failing is ok — It never feels good to fail, but it happens to all of us, and it is expected early in our careers. One of the first applications I wrote by myself for work quickly went from a simple application with a clear purpose to one that was so generic that it was hard to enhance, difficult to understand, and ultimately a failure. In retrospect, this was due to unclear requirements and not understanding how to prioritize customer and peer input, so I tried to do it all. While this was a frustrating experience, it was a great learning moment that helped me see warning signs in the future when a project has drifted out of scope.
  
  Failing is often one of the greatest ways to learn. Ever break production? What a terrifying experience, right? But you are forced to learn how to fix the issue on the fly, and that will teach you how to not do it the next time. Failure exposes weaknesses, not just for you but potentially your teammates and their processes. When you broke production, what caused the issue? Was it something in your code, or was it really a safety mechanism in the release process that missed the underlying issue (which you have now exposed to be fixed and prevented from happening again)? Fail fast, fail hard. It’s all part of the learning process, and the more you do it the more resilient you (and your team) will become.
• It’s ok not to know — It can be tempting to pretend to know things you don’t know. You don’t want to look like the only person who doesn’t understand something. However, this can lead to clarity problems, resulting in work that doesn’t meet the requirements. It is far better to ask clarifying questions early in the process to make sure you know what you need to deliver than to wait until it’s too late, forcing you to have a difficult conversation about not delivering what was promised. It is ok to not know something. We can’t know everything, and if you don’t know something, someone else likely doesn’t either. Asking questions is also a very important component of designing resilient software. You might be scared to ask, but clarifying your confusion could expose an issue with the software and lead to a better product overall, so please ask away!
• Try before you ask for help — While asking questions is certainly encouraged, don’t presume you can’t figure something out before you’ve tried your best. Struggling through a problem is a valuable experience that can teach you troubleshooting skills and allow you to process how something works. Senior developers will often expect you to have tried everything you could before coming to them with questions, too. If you are truly stuck, reach out and pair with your teammates, but give it your earnest best attempt first. You will be surprised how often you prove to yourself that you can solve a problem you didn’t think you could, which is another great way to stave off imposter syndrome.
• Don’t forget balance, and avoid burnout — Software engineering isn’t just a job — it’s a way of life. You will have to learn new things often throughout your career, which can easily lead to overwork. Prioritize your work-life balance: take your vacation time, go outside, move your body, get a good night’s sleep, and give your brain a rest!
  
  Before I got a job as a developer, I was working full time, then coming home and spending an additional 15–20 hours per week developing a video game. I was struggling to break into the software development field, so I thought the best way I could gain enough experience to get a job was to ship a full product from start to finish. The result of this was 6 months spent on a game I never finished and burned myself out on. I did gain experience that was crucial to me finally landing a software job, but it sunk my mental health and it took me almost a year before I was excited about coding again.
  
  It is so easy, especially when working from home, to sit at your desk all day for work and then go right back to your desk after work. Try to avoid this as much as possible. While it may seem like using every spare moment of your time to squeeze in a little bit of coding time will help improve your skills and boost your productivity, letting your brain get some distance will clear your mind and allow you to use your time more efficiently when you’re on the clock. Your happiness at your job will depend, to some extent, on your ability to avoid burnout, and keeping this in mind will help pave the way for a long and happy coding career.

Imposter syndrome is difficult to overcome, and it can crop up occasionally even if you have defeated it before. When it does come up, reflect on your past successes and remind yourself that you are here for a reason. If you are early in your career, focus on refining your craft in a balanced and sustainable way, and realize that your commitment to improving every day will help you advance through a successful career. I hope these tips help you, and I’m glad we’re here together.

Overcoming fear and succeeding as a new software engineer was originally published in Xandr-Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Co-authors Andrei Mackenzie and Joe Roepcke

If you’ve worked long enough in tech, you’ve probably had to perform knowledge transfers to rotate individuals or teams on to and off of various projects and products. It’s a common task and challenge faced by engineering teams, whether due to natural attrition, promotions, folks transferring to other groups, or new members joining existing teams. Since Xandr’s technical teams cover a wide range of features including high-performance ad auction processing, cutting-edge frontend UIs, and data engineering at petabyte scale, these engineers often need to learn from each other or even change teams. We actually encourage internal mobility to allow engineers to pursue their passions and explore different parts of our organization and the products we offer.

Being able to handle these sorts of transitions well is key to keeping your engineers growing, learning, engaged and motivated. In addition, this ensures your ability to continue running your business effectively, supporting your clients and products seamlessly, and protecting your sources of revenue.

In this post, we look at some of the most common challenges any engineering organization faces when a developer needs to transfer knowledge in order to take on new responsibilities and/or support new products and what things you should consider in your transition plan.

Usually, an engineer has identified an opportunity they want to pursue on a different team, or a new product team or division is being formed that will include this engineer. Sometimes, the move is based on some specialized skills or interests they have. For the purpose of this post, we’ll assume this is a permanent transfer.

One of the ways we’ve seen this initially unfold is the engineer who wants to move identifies an interesting opportunity and speaks to the new manager to learn more and confirm their interest. Next, the engineer speaks to their current manager to get their perspective on the move. The current manager then has an opportunity to share their ideas and offer some insight on what alignments can smooth the path to transition. Once all three people agree on the move, the engineer and both managers begin work on a transition plan. This is needed to allow the engineer to migrate from their current responsibilities and ramp up on new job tasks without disrupting day-to-day business and the teams involved.

We found that a people first approach worked best. Some key objectives in what such a transition plan ultimately looks like are:

Support the remaining team well — Monitor how the existing team from which the engineer is departing is handling the new responsibilities they will now own (stress level, etc.). This includes how they plan to absorb that engineer’s product knowledge and potentially take over support for those products and systems. You must also determine which projects will soon reach reasonable stopping points, even if they are not fully complete yet, and what those stopping points are.

Support the transitioning engineer’s desire to move on to the new opportunity quickly and minimize the context switching — Design your transition plan in a way that achieves the best balance between letting the departing engineer learn their new product while still supporting their previous team. Don’t let the transition drag on endlessly as it can dampen the initial enthusiasm of the engineer transitioning.

Seamless manager transition — Ensure any context the current manager has is communicated well to the new manager. This is about enabling the new manager to get a head start on supporting their new team member by learning as much as possible about the engineer’s working style, likes and dislikes, career aspirations, etc. The current manager is often the one who knows a lot of these details and has insight into where this employee has shined in the past.

Business Continuity — You need to ensure there’s sufficient coverage for the engineer’s current responsibilities with the remaining team members (so support for the product doesn’t suffer).

Effective ramp-up — This process is not so different from bringing on a new hire. But it’s important to distinguish between what a new-to-your-company hire needs to learn vs. what an internal transfer needs to know. For example, there may be general engineering onboarding for new hires, but then more specific onboarding for sub-organizations (or smaller teams) that is tailored to the products and technology they cover. An internal transfer would only need to complete the more tailored onboarding.

Of course, no matter how carefully you create a transition plan, there will be many things you learn along the way and points where you need to adapt and be flexible. Our transition plan grouped issues into several major areas (your experience may differ). Below, we discuss some actions we took to deal with them:

The actual knowledge transfer

• Identify how you will transition current areas of expertise to existing team members. This means being explicit about who should learn what and setting up focused sessions with the individuals involved. This could include things such as familiarity with testing and debugging tools, code deployment paths, the location of key resources and documentation, or how to connect with other teams that perform essential integration tasks. What’s in this list will be determined by the nature of the role the transitioning engineer performed.
• Try to address any “scariness” the existing team has about learning a lot of new scope (to cover the responsibilities of the departing engineer). Check in frequently with these engineers to gauge their stress level. Reassure them that the engineer transitioning is still going to be accessible. The new manager may also need to address some anxiety around any technology the transitioning engineer has to learn, but this should be minor since they chose the new team and are eager to learn about their new position.
• Consider that some roadmap items might not be achievable on the original schedule given changing team dynamics. You may need to re-evaluate planned work for the transition period to realistically allow the engineer to transfer off in a timely manner. Be sure to set transition timelines that still allow critical work to get done. Also, keep in mind that engineers taking over the responsibilities of the transitioning engineer may not initially be as proficient or efficient in those tasks. This should also be factored into your road map planning, at least initially, until they are up to speed.

In-flight projects

• Be aware of the transitioning engineer feeling rushed to complete in-flight work in order to transition quickly. Be disciplined and set realistic transition timelines to avoid handing off unfinished work.
• Determine explicit milestones for projects and only set transition dates once you have considered a realistic date by which your transitioning engineer can achieve those milestones.
• Ensure the team is comfortable completing and supporting important work-in-progress. If that’s not entirely possible, consider shelving the work or extending the transition timeline. Don’t allow the transition of projects that have not reached reasonable stopping points. This may also require a re-prioritization of what is truly critical and a re-evaluation of what the existing team is able to achieve while still enabling the engineer to transition off.
• Build a framework to govern how the existing team will engage with the transitioning engineer for consultation and hands-on help post-transition. This may involve establishing office hours or holding scheduled sessions for targeted troubleshooting help as well as clearly documenting what steps should be tried first before reaching out for that help.
• Leverage pre-existing documentation and project-related JIRA tickets in any transition documents. This will help ensure continuity, build familiarity with the context of the features or products being handed off, and offer an opportunity for the stakeholders and engineers to learn each other’s names.

Support and Context switching

• The transitioning of the engineer may create gaps in product support, especially if the time zone coverage and overlaps are not sufficient. This is more of an issue if the departing engineer specifically worked a range of hours that had been deliberately chosen to accommodate the customer’s time zone and schedule (e.g., for providing technical support). Once the engineer leaves the team, the time zone difference and support requirements may be difficult for the remaining team to sustain. Therefore, it’s important to establish a pre-defined emergency engagement path for transitioned engineers within your company. Be sure to involve their new manager to establish the right level of focus (e.g., a single work priority order, so that the engineer doesn’t feel pulled in multiple directions by multiple managers).
• It takes time, focus, and effort to train new engineers. Having to shift between learning a new product and training those who are taking over products the transitioning engineer previously built or supported requires context switching. This compromises focus and causes the transitioning engineer to perform each task less efficiently. Below are 3 things you can do to mitigate this issue:
  — Create documentation — Doing this can help the transitioning engineer collect their thoughts, experiences, and knowledge in a central location and allow new engineers to learn asynchronously. These documents can take the form of schematics, process diagrams, specs, component overviews, typical support paths, or whatever the engineer can imagine to be useful. It’s also a good idea to review these documents yourself as reading them can help generate ideas for other areas that might still be missing.
   — Focus — The transitioning engineer needs to be explicit about focus areas and lean on their managers to carve out enough dedicated time, whether it be for pre-transition work or taking on new responsibilities. You need to allow the transitioning engineer to focus on tasks that are either in the old world or new world without forcing them to switch between the two too often.
   — Split % — Define the specific percentage of time that will be spent focusing on the previously supported products over time (e.g., 100%-80%-40%-20%).
• It can sometimes be difficult to stay in the loop after transitioning off of a team or product. The transitioning engineer may still need to offer guidance during the handoff phase. There’s a balance between allowing an engineer to fully focus on the new opportunity with no context switching, and just relying on their memory of legacy projects to support and advise the remaining team’s work. Staying in the loop means still knowing enough about the product and technical direction of the remaining team to not have to spend an inordinate amount of time catching up before being able to share knowledge effectively.
• Be sure to make it clear which meetings, chat channels, and other forums will provide the information critical to maintaining context on previously support products. This will allow the transitioned engineer to remain involved at a sufficient level. For example, the transitioning engineer might stop attending many of the detailed design reviews and team ceremonies that occur weekly but continue to attend the broader long-term planning and monthly All Hands sessions to maintain high-level context about projects on the horizon. In addition, the engineer should remain open to invites for ad-hoc collaboration on specific projects where their expertise could be especially valuable (e.g., some component or feature he/she previously worked on directly).

Time zones

If the time zones of the teams involved are a factor, you may need to consider how to allow sufficient time to collaborate across them. Try to make effective use of the overlapping hours by setting them aside for collaboration between the remaining and transitioning engineers. Initially, office hours and support can be offered during non-traditional working hours (but don’t overdo it, this should not be a long-term strategy). Being mindful of people’s work hours is part of a people-first approach and applies even if time zones are not an issue for your engineering teams.

Having now completed a few of these engineering transitions within our teams recently, here’s some additional fine tuning we added along the way that our fellow colleagues (and you, perhaps) may find useful.

• Put a defined percentage-of-time focus model in place. It’s both effective and worthwhile. This really helped avoid unexpected or excessive context switching. A sample breakdown that we used was to gradually switch the percentage as we progressed through a transition:
  — 80% old / 20% new — the engineer starts the transition phase by participating in some ramp-up activities on the new product while remaining primarily focused on the previous team’s work and training folks to take over previous duties.
  — 40% old / 60% new — the engineer begins to focus primarily on the new team’s work, but remains involved in the previous team’s ceremonies and winds down any in-flight work.
  — 20% old / 80% new — the engineer focuses nearly exclusively on the new team’s work with only lightweight or ad-hoc involvement in the previous team’s design reviews, support requests in emergencies, etc.
• For larger in-flight projects that jeopardize the transition timeline (due to their size, complexity, or the specialized knowledge that needs to be transferred), try breaking them down into smaller, more achievable milestones. This can allow the transitioning engineer to complete the first milestone while allowing the new engineers to start working out the details of the subsequent ones.
• Plan transition timelines in a way that allows for some overlap between the transitioning and new engineers to give those new engineers time to learn while the transitioning engineer is still engaged.
• Be aware of how distance, language barriers, familiarity with the underlying technology, and/or any planned (or in-flight) changes of toolsets might affect your timelines.
• Carefully monitor the stress levels of both the engineer transitioning and the team that is taking over their previous responsibilities. Be sure to do this even if the engineers involved don’t proactively vocalize their potential stress. How? Try explicitly asking folks in 1:1s (weekly one on one chats) how they are feeling about the adjusted workload. If they share that the additional work is affecting their life negatively, look for opportunities to de-prioritize less important things or spread the load more evenly among the remaining team. Another signal could be if you see that people are working extended hours or are dealing with an unusually high number of off-hours emergencies as a result of fewer hands being on deck. Again, just because you are not hearing about these issues doesn’t mean they aren’t occurring (since vocalizing them can be seen as complaining). Be sure to ask.
• Be mindful of how in-flight work is transitioned. Strive for reasonable stopping points and milestones. Don’t let projects end in a place that is difficult to provide support for.
• Cultivate a bias towards action. At some point, it will be necessary to actually give new processes a try and allow people to step away from previous roles. Your people are talented and able to overcome challenges while still supporting each other. Trust that.

As we all know, you can never figure it all out in advance, so be open to lessons that present themselves to you as you make your way through the transition. Some additional nuggets are:

• Once a transition opportunity is identified, strive to make it happen quickly. As much as team members want to support each other, people are eager for what’s next. Capitalize on that enthusiasm!
• Timing estimation is hard, don’t be afraid to shorten the cutover if the remaining team seems well equipped and ready in less time (e.g., we’ve had teams make a transition in 3 months that was planned for 6).
• Look for opportunities to reduce scope along the way. Ask yourself: “Are all of the transitioning responsibilities necessary?” Use the transition as an excuse to descope and simplify rather than just transitioning all responsibilities exactly as they are.
• Set up a recurring retrospective meeting with the teams involved (before the whole transition is done) to reflect on how the plan is going. For a 3 to 4 month transition plan, a monthly cadence can work well. The idea here is to learn and course correct as you go rather than trying to get the plan perfectly defined from the get-go.

And that’s it! We hope you found some of our experiences helpful and that you’re excited that your engineers are so engaged in your company and products that they both want to take on new and exciting roles and help their colleagues support what has already been built and is succeeding.

Knowledge Transfer in Engineering: Both a challenge and an opportunity was originally published in Xandr-Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Co-authored by Oumaima BENBAHAKKA, Dr. Paul Farrow, Dr. Romain Quéré and Dr. Yana Volkovich

GitHub repository

At Xandr, we are actively participating in ongoing industry discussions about the future of identity, as well as carefully evaluating various emerging proposals. One of those proposals is the Topics API. Deconstructing and analyzing the Topics API helped us gain insight into the effectiveness of its inventory categorization methodology, how its categorization is affected by language, and the breadth of its domain coverage.

The Topics API is part of a series of browser APIs Google has introduced to Chrome to help ad tech companies adapt to the deprecation of third-party cookies. More precisely, the Topics API is designed to support behavioral targeting approaches, which have historically relied on third-party cookies.

Rather than sending identified data (cookies) along the ad tech chain, Topics uses the browsing directly from a device to assign users to categories, known as “topics.” These topics are then exposed directly to ad tech vendors via the API, without ever requiring an identifier to leave the browser. Google Chrome believes this will enhance the privacy of its end users.

Because Topics lives in the browser and has been implemented in Chromium (the open-source variant of Chrome), we have been able to extract its source code, dissect its features, and simulate it in a developer environment. Given the public interest in Topics (and in the Privacy Sandbox generally), we have shared the tools and resources we have built for this study with the community. You can find them on our repository.

At its core, Topics relies on assigning categories that compose a tiered content category taxonomy (similar to Google AdX’s) to each website a user visits. The browser then counts how many domains have been visited for each category over a 7-day period, and assigns the top 5 categories to the user. These top 5 categories are then selectively returned to ad tech players through the Topics API, following a set of rules described here.

Internally, assigning visited domains to categories relies on a Bert classifier that only uses the hostname of the domain for its inference. This classifier is coupled with an override list with which Google overrides the result of the classifier for some domains, probably with the goal of enhancing Topics’ performance. Our analysis of Chromium’s code enabled us to extract both the classifier and the override list, and reproduce Chrome’s domain classification (as observable in Chrome Canary at chrome://topics-internals/).

Thus, we’ve been able to study Topics’ domain classification and answer the following questions:

• How does the Topics API’s inventory categorization compare with other categorizations on our platform?
• How does language affect Topics categorization?
• Are all domains classified?

We compared inventory categorization by the Topics API to other content category features available on Xandr Monetize. Xandr devotes significant resources to maintaining a strict set of baseline criteria, so we can prevent unacceptable inventory from being sold on our platform. Inventory available on our platform may be tagged with content categories, brand-sensitive attributes, and intended audiences. This tagging can be implemented by the Xandr audit team or provided by sellers. Because this manual evaluation is available for Xandr inventory, it provides a useful comparison with the Bert model from the Topics API.

The heatmap above shows the distribution of topics across each Xandr Audit content category. (In other words, the column values add up to 1.) For the sake of clarity and simplicity, categories from both taxonomies have been reduced to their corresponding first-tier category. For example, “/Arts & Entertainment/Humor/Live Comedy” has been reduced to an element in the “Arts & Entertainment” category in the heatmap. It’s also important to note that while they appear to be very similar, the Xandr Audit and Topics taxonomies appear to be significantly different.

Globally, there’s a strong agreement between the classification types. Some Topics show a significant overlap with more than one Xandr Audit content category. However, in such cases, the content categories are still often semantically close to the Topics category they are associated with. This can be explained by the reduction to the first-tier category discussed above and the differences between the taxonomies. For instance, the “Smart Phones” category from Topics is part of Topics’ “Internet and Telecom” first-tier category, while the corresponding “Cell Phones” category from Xandr taxonomy is part of Xandr Audit’s “Computer & Electronics” first-tier category. The reduction to the first-tier categories would then lead Topics’ “Internet & Telecom” category to overlap with Xandr Audit’s “Computer & Electronics” categories.

Another interesting observation is that most of the Topics content categories have a significant overlap with the News category from Xandr Audit. This makes sense, because news encompasses a large variety of subjects, and because the Topics model can return multiple categories for a domain. For instance, in the Topics model, vogue.com is part of “Arts and Entertainment”, Fashion & Style” and “News”. Thus, a domain that Xandr Audit labels as “News” might be categorized as both “News” and “Arts & Entertainment” by Topics, leading to some overlap between Topics’ “Arts & Entertainment” and the “News” Xandr Audit label.

Because Topics is an international feature, and its domain classification currently relies on only a single model, it is interesting to see how it handles non-English domains.

Xandr has a large international footprint, especially in Europe. Thus, we were able to collect four sets of visited domains from our traffic. We used data from France, Germany, Spain and Japan in order to compare how Topics classification performs over non-English domains. The classification for each country is then compared with Xandr Audit classification, resulting in the following heatmaps.

Overall, the agreement between both classifications is fairly significant, and very similar to what we previously observed across our global traffic. This seems to indicate that Topics is suitable for international needs.

The short answer is: no. As we discussed previously, the model is a multi-label classifier, and it can assign from zero to five categories to a domain. Hence, some domains do not have any label, meaning they will not contribute to the user’s topics. The following table shows the proportion of unique domains without assigned topics for global traffic, as well as for traffic from the US, Spain, Japan, Germany and France.

| Traffic | % of domains without topic |
|---------|----------------------------|
| Global  |                       9.40 |
| US      |                      12.40 |
| Spain   |                      10.76 |
| Japan   |                       9.59 |
| Germany |                       9.78 |
| France  |                       3.48 |

The proportion of domains without topics is not negligible: up to 12% of unique domains for our US traffic were not associated with Topics. Notably, this includes significant domains such as fandom.com or doctissimo.fr, which are ranked by similarweb.com as the 46th global domain and the 3rd health-related French domain, respectively. It also includes domains with semantically explicit hostnames, such as horoscope.com, conservativejournalreview.com and thesologlobetrotter.com. This is obviously not ideal and shows that the model performance isn’t perfect. However, we still find that its performance is acceptable, given that the model is only using the hostname to qualify the domain’s content.

We successfully extracted the Topics model from the Chrome browser, and were able to apply it to our datasets. Based on our experiments, the model performed well against human classification techniques. This suggests that the Topics API works as a categorization tool alone, including for non-English domains.

While the studied model is instrumental to understanding the Topics API, it only covers one facet of it. Observing how user browsing histories are qualified, as well as how the ad tech players’ footprint affects how many topics they receive, will be crucial for completely understanding the proposal. Stay tuned!

On the topic of Topics was originally published in Xandr-Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Historically, excellent technical documentation combines art and science, not just to collect information, but to create understanding using words. Readers should experience information transfer as smooth, transparent, and simple. As a writer and editor on Xandr’s Technical Communication team, though, I often find myself communicating about the invisible complexity of documentation. Creating a pleasant user experience for an application requires intense collaboration and a big range of expertises; similarly, creating easy-to-use technical information requires solving hard problems behind the scenes. Solving those problems includes making sure our information processes can move forward along with our product technology.

If you’re not a technical writer, you’re likely to be most familiar either with API documentation (if you’re a software developer), or with consumer documentation targeted to a very specific need. At Xandr, our product offerings are both broad and complex. Our documentation not only has to cover the ins and outs of an intricate, highly flexible user interface: it also supports integrations with third-party tools, the complexity of advertising optimization, and the deep technical information that helps developers build their own apps on top of our platform. That’s a huge amount of information, and it evolves rapidly. In other words, documenting our products requires an approach that can handle documentation at scale and over time.

Let’s unpack what scaling and maintenance mean for documentation.

When you write a letter, blog post, or email, you probably aren’t expecting any of the following to happen in the future:

• People will keep referring to what you wrote for years to come. They’ll get very annoyed if the facts are out of date.
• There is so much information out there that your material gets lost. Even people who are highly motivated to read what you wrote will not be able to find it — even with on-site search.
• Other writers will take what you wrote and add some sections, but the new bits will be in a different writing style.
• Other writers are writing related documents all the time, but they’re formatted in a totally different way, or they use different terminology, so nothing matches and everything looks slipshod.
• Several different publications will use parts of your writing, but in different combinations and organizations. Alternately, three different versions of what you wrote will exist at the same time and in the same publication, but 10% of the content will be slightly different. When the facts change, these versions may get out of sync.
• The platform or medium in which you wrote it will be discontinued, so if you want to keep publishing it on your website, you’ll have to master a whole new set of technical processes to keep it out there. (OK, this happens sometimes with blogs, but at a lesser scale.)
• Other people will need to use the same files you do to get writing done, but they’ll be making different (possibly conflicting) updates with different deadlines. Just as with code, merging and branching sometimes get complex.

With many hundreds of documents in play, covering an overlapping series of products that evolve rapidly and require deep technical understanding, our documentation team has to solve all these problems to avoid creating a frustrating customer experience. We not only need to produce timely, accurate documentation for the many new features Xandr releases, but also maintain our existing documentation base by removing information that’s no longer accurate.

We also constantly need to identify gaps that challenge our customers, in order to make sure they can do their jobs. Finally, we need to make sure our docs are usable — searchable, well organized, and well presented. It’s a big challenge with many moving parts.

In the last couple of years, the story of Xandr documentation has been one of almost constant change and growth, as we weaned ourselves off processes and tools that limited our ability to adapt to changing conditions. As the Xandr product universe has grown and diversified, our team has transformed operations to handle information at scale, while staying ahead of Xandr’s technological evolution.

As Xandr grew and diversified its product portfolio, Xandr’s docs team upped our game in the following areas:

• Source: the format and technology we use to create docs
• Publication: how we get documentation reviewed and published
• User Experience: how customers find and interact with information in our documentation portal
• Case deflection: how we find and address customer gaps to create a more satisfying information experience and reduce Support involvement

A couple of years ago we made the big leap from authoring content in Markdown to coding it in DITA XML, a flavor of XML with custom markup designed for technical communication. (DITA stands for Darwin Information Typing Architecture and is an open-source standard: read more here if you’re curious.) This change represented a whole new way of writing for much of our team. It might seem counterintuitive to write words in code, but DITA’s modularity and semantic markup offer great flexibility in enabling multiple outputs. For example, a website, a context-sensitive Help app, and a chatbot could all use the same files, but look and function very differently.

Xandr used to operate as a single product: now it’s a DSP, an SSP, and a curation app, plus a whole family of products that handle TV advertising. DITA lets us handle the overlaps between multiple products using complex conditionalization. That means we don’t have to maintain separate files for every product that uses some of the same information — resulting in thousands of hours of duplicate effort saved, not to mention far greater accuracy than we’d be able to achieve without the ability to reuse existing documents.

Finally, DITA is “portable.” That means if our current toolset is discontinued, we can bring the code into a new system without having to convert it to a new file format, or reapply all the formatting we’ve painstakingly added.

Along with DITA, we’ve adopted a content management system (CMS) to help us manage branching and versioning. Our CMS also provides a web-based review system to collaborate with subject matter experts without emailing multiple versions of files around. We can branch, review, and build in the same interface. And we can run reports identifying content that’s stale, so we can update it or remove it.

Publishing documentation at Xandr used to require a labor-intensive build process involving command lines and multiple apps and libraries installed on a writer’s computer. We also had no way to stand up a staging server to verify changes before they went live on our documentation website. Our current processes allow us to view our changes in staging and push corrections and updates rapidly to both the website and the in-product Help — no more waiting for a weekly build to get it right.

For the last two years, we’ve been working with Zoomin Software to create and refine a unified documentation portal. Our API docs, product docs, and knowledge base articles now use a single searchable and filterable website, which lets customers quickly find articles with the answers they need. They can even favorite the docs they like and provide feedback right in the portal.

Our documentation used to be hidden behind a login: most of it is now public, and that means we have two sets of analytics to work with: Zoomin’s and Google’s. With enhanced access to statistics about web searches, on-site searches, and searches within our in-app Help, we’re getting new insights about what our customers are looking for. These insights help us identify where to allocate effort, understand the terminology our customers are using, and even identify content that’s not getting used much, so we can decide if it’s still valuable. We’ve also launched a project to target those areas where customers struggle by creating highly specific, task-based articles to supplement our existing information.

Most excitingly, we’ve partnered with the Xandr Support team to roll out an integration with Salesforce that directly interfaces with our Support site. We can now proactively offer relevant documentation to customers filing a case — when just-in-time information can solve their problems, they can move on to success without ever creating a case.

Some documentation practices don’t change. From Leonardo da Vinci’s sketches of flying machines on up through the interactive chatbot, solid documentation will always be based on technological learning and clear communication of how things work. How that gets done, though, is highly subject to change. As our products and the state of documentation tools and workflows evolve, we’ll continue to look for both high- and low-tech opportunities to provide information that’s relevant, useful, and up to date.

Bringing Xandr Documentation into the Future was originally published in Xandr-Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

As part of Xandr’s long-term effort to migrate our core engines from a mixture of virtual machines (VM) and bare-metal servers to the new world of Kubernetes (k8s), my team has been charged with migrating any of our applications still residing on VMs onto k8s pods. By moving to k8s, Xandr is taking advantage of enhanced possibilities for application orchestration and maintenance. Our ultimate plan is to have 100% of our servers running on k8s.

Overall, our previous migrations have gone smoothly, with predictable results. As we began scheduling and prioritizing our remaining applications, we discovered that migrating certain complex, event-driven apps posed new challenges around variable resource usage. However, with some research and a proof of concept, we were able to demonstrate how these challenges could be addressed effectively using k8s autoscaling.

Most of the core applications we’d previously migrated ended up using a predictable 2 pods per data center. However, when we put certain event-driven applications under the microscope, we found that this formula didn’t account for the complexity of these applications. These apps typically rely on parallel processing, concurrency, workers, child processes, and other complex operations that can result in variable resourcing requirements. As a result, assigning a fixed number of pods wouldn’t work.

In the short term, assigning a standard number of pods for each of these applications would result in over-provisioning. Calculating a threshold based on the current peak usage over X months would result in excess resource allocation beyond real-world usage.

In the long term, assigning a standard number of pods would also result in under-provisioning. Because demand grows over time, the previously established threshold would eventually be insufficient, causing contention for CPU and memory and — in the worst-case scenario — a growing backlog.

In a VM and bare-metal deployment, application 1 spawns a total of 144 processes. Taking into account 3 different data centers, matching its throughput would theoretically require a total of 48 (144/3) pods per data center. Application 2, also on the to-be-migrated list, spawns a total of 3072 processes.

These applications often belong to an interdependent workflow, as shown in the following illustration:

As a result of these dependencies, we may see:

• static tide throughput.
• idle resources on the previous app, while the next app in the chain is struggling.
• backlogs being created on every app when the magic number is no longer valid and demand spikes occur.

To head off these problems, we needed to tread carefully and consider how to proceed with provisioning in a scalable manner.

If you are a tech enthusiast, you know the primary issue here is scalability. Furthermore, depending on how critical the data generated by those applications is, scalability may also translate to stability, as shown in the following graphics.

Digging into k8s documentation to understand this problem more deeply, we decided to create a proof of concept (POC) of the k8s scaling mechanism using our company test environment.

In this environment, we created a Node Express application that:

• executed CRUD into RabbitMq.
• pushed metrics to our metrics client, an open-source monitoring application called Prometheus).
• did some CPU-intensive calculation.

Starting with the basics (k8s pod metrics for memory and CPU), the first stage of our POC was to scale based on the CPU used by the application. The following code samples illustrate our approach:

Node js code sample

// source from: https://gist.github.com/sqren/5083d73f184acae0c5b7

// higher number => more iterations => slower
function intenseCalculation(baseNumber) {
    console.time('mySlowFunction');
    let result = 0;
    for (var i = Math.pow(baseNumber, 7); i >= 0; i--) {
        result += Math.atan(i) * Math.tan(i);
    };
    console.timeEnd('mySlowFunction');
}

--------------------------------------------

app.post('/work', async (req, res) => {
    intenseCalculation(5)
    res.status(200).send('ok');
})

Auto-scaling sample for CPU

------------------------------
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: poc-k8s-vpa-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: poc-k8s-vpa-hpa-app-creat120
  minReplicas: 1
  maxReplicas: 100
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
        type: AverageValue
        averageValue: 0.01

When our engines were properly deployed, all we had to do was to call the endpoint /work multiple times from several terminals, then stop them gradually in order to see k8s scaling up and down.

We used the following sequence of commands:

1. Trigger command

for id in {1..1000}; do curl -X POST 'ENVIRONMENT_URL/work'; done;

2. kubectl command

kubectl describe horizontalpodautoscaler --context qa01nym2 -n creative poc-k8s-vpa-hpa

Based on the CPU being used, the deployment was scaled up to 3 pods. As we stopped the calls, it was reduced to only 1, as shown below.

As shown above, the initial POC worked like a charm. Now it was time to go a step further and leverage autoscaling based on custom metrics — metrics that are reported by the application and read by the custom metrics API (custom.metrics.k8s.io).

As the error messages below demonstrate, we were in unknown territory. We couldn’t apply autoscaling, or retrieve metrics from the k8s metrics API. In fact, the custom metrics APIs were not registered at all, which also informed us that no one in our company had tried this before.

kubectl describe horizontalpodautoscaler --context qa01nym2 -n creative poc-k8s-vpa-hpa

Warning  FailedComputeMetricsReplicas  18m (x12 over 21m)  horizontal-pod-autoscaler  invalid metrics (1 invalid out of 1), first error is: failed to get object metric value: unable to get metric requests-per-second: Ingress on creative main-route/unable to fetch metrics from custom metrics API: no custom metrics API (custom.metrics.k8s.io) registered

Warning  FailedGetObjectMetric         77s (x80 over 21m)  horizontal-pod-autoscaler  unable to get metric requests-per-second: Ingress on creative main-route/unable to fetch metrics from custom metrics API: no custom metrics API (custom.metrics.k8s.io) registered

kubectl get --raw/apis/metrics.k8s.io/v1beta1/namespaces/creative/pods/poc-k8s-vpa-hpa-app-creat120-5c794d9bb4-jxxsl  --context qa01nym2 -n creative | jq

Error from server (Forbidden): pods.metrics.k8s.io "poc-k8s-vpa-hpa-app-creat120-5c794d9bb4-jxxsl" is forbidden: User "REDACTED" cannot get resource "pods" in API group "metrics.k8s.io" in the namespace "creative"

kubectl get --raw /apis/custom.metrics.k8s.io/ --context qa01nym2

Error from server (NotFound): the server could not find the requested resource

We couldn’t touch the core pieces ourselves to get the metrics to be exported, nor could we see the metrics already exported by the k8s custom metrics API.

Solving this problem required both research and the knowledge of our internal k8s experts, who provided the engines our test environment was missing. We found these articles especially helpful:

• Building Your Own Custom Metrics API for Kubernetes Horizontal Pod Autoscaler
• kube-metrics-adapter

To create a POC of k8s autoscaling, we needed to scale our application requirements up and down, based on the metrics we generated inside the app for messages being pushed to RabbitMq.

To achieve this, we made the following changes at the app code level:

• We updated the code so it would push items to RabbitMq. This wasn’t technically required for the POC, since all that really mattered was that the metric was pushed.
• We ensured that report metrics were sent to Prometheus.

Example: a node.js api exposes a POST endpoint /work, and pushes metrics when called.

app.post('/work', async (req, res) => {
    const message = req.query.message;

    // pushes a message to Rabbit MQ
    await rabbitmq.publishMessage(
        "my_queue",
        JSON.stringify({
            created_on: new Date().getTime(),
            message
        })
    );

   //sends a metric to prometheus
   //metric name: total_messages_pushed
   addTotalPushedData();
   
   res.status(200).send('ok');
})

Example: a YAML configuration sets up autoscaling based on the custom metric.

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
    name: custom-metric-hpa
    namespace: creative
spec:
    scaleTargetRef:
      apiVersion: apps/v1
      kind: Deployment
      name: poc-k8s-vpa-hpa-.Release.name
    minReplicas: 1
    maxReplicas: 10
    metrics:
      - type: Object
        object:
          metric:
            name: messages_pushed_per_second
          describedObject:
            kind: Namespace
            name: creative
            apiVersion: v1
          target:
            type: Value
            value: 2

prometheus-adapter custom metric configuration

prometheus-adapter is the engine responsible for fetching the metric available on Prometheus and making it available to k8s custom api metrics. We can then use it as a criterion for autoscaling.

The following code shows pushing metrics to Prometheus, with the average of total_messages_pushed over the past 5 minutes:

apiVersion: v1
data:
    config.yaml: |
      rules:
      - seriesQuery: 'total_messages_pushed'
        resources:
          overrides:
              namespace: {resource: "namespace"}
        name:
          matches: "^total_(.*)"
          as: "${1}_per_second"
        metricsQuery: "rate(total_messages_pushed{<<.LabelMatchers>>}[5m])"

Once again, all we had to do to evaluate the POC was to call /work several times from different terminals to see the autoscaling taking action, using the following command.

for id in {1..1000}; do curl -X POST 'ENVIRONMENT_URL/work?q=example'; done;

Then we invoked kubectl to get the autoscaling data, using the following command:

kubectl describe horizontalpodautoscaler --context qa01nym2 -n creative poc-k8s-vpa-hpa

Based on the number of messages pushed to RabbitMQ (messages_pushed_per_second), the k8s pods were successfully scaled up to 10, and then down to 1 as we stopped the calls.

As our internal k8s experts add these engines to our staging and production environments, we’ll be able to apply the k8s autoscaling mechanism to our applications, especially the event-driven ones I’ve described in this blog post. This technological advance will empower us to:

• Maintain a pool of resources to allow autoscaling across multiple apps, rather than hardcoding a set number of resources per application.
• Achieve a moving tide throughput. Pods scale up or down on demand, with resources allocated accordingly.
• Reduce and optimize our team’s resource fingerprint.

Ultimately, by taking advantage of the enhanced benefits of k8s containerization — and in particular, a responsive back end that can be autoscaled up or down and efficiently maintained using k8s orchestration tools, this migration gains for Xandr not only the increased ability to optimize infrastructure budgets by better focusing on demand, but the potential to move forward with innovation on a larger scale. In a space evolving as rapidly as ad tech, we’re poised to roll with whatever the future brings.

Going the extra mile with our k8s setup was originally published in Xandr-Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Making the decision to come out is a deeply personal choice and journey. It is a process, and one in which no one person follows the same path in how they decide to share that aspect of themselves. In recognition of the Trans Day of Visibility, I wanted to share some of the thoughts and experiences I had while coming out and living openly as a trans person at Xandr.

Transitioning is a multifaceted process that touches every aspect of your life, from family to health to social and professional relationships. While there was a lot of introspection, discovery, blunders, comedic moments, and other nuanced relationships I experienced along the way, I will focus this story on my identity in the workplace (although, I’ll add the caveat that it is all ultimately connected).

When I first knew I was going to transition, the greatest fear I had was that I would have to choose between living authentically or having a successful career. There is a common practice amongst a lot of us in the queer community of bringing our “straight” selves to work and leaving our authentic selves at home. It’s easy to understand the fear too. I personally know people who were kicked out of their homes or told by their bosses to leave their jobs after making the decision to step into the vulnerable spotlight of authenticity.

After working at Xandr for about a year, I was not scared of being let go. I had observed the culture of the organization well enough to know that they would not terminate me for existing as a trans person. But I was still anxious that it would affect the personal and professional relationships I had built with teammates during my time there. I remember so many times across my life when I would hear a coworker’s unprompted opinion on trans people, and these memories clung heavily on my mind. There was a fear that people may not want to work with me even if they had to. But the reality is, taking a step into the unknown of being myself at work is the most amazing thing I have done in my career.

I do want to call out that the conversation with my boss was not the scariest coming out conversation I’ve had in my journey. I would actually rate it towards the bottom in terms of people I was afraid to have the conversation with. Something non-queer people may not realize is that coming out is a skill, and it gets easier every time you do it. My manager at Xandr was not even the first manager I had come out to, just the first one I came out to with the intention of going public with the full team. If you are at the beginning of your journey of presenting your authentic self to the world, I promise coming out gets easier with each iteration. Until one day you’re so out that you don’t even have to talk about it with people! (Quick hint: being concise, direct, and to the point yields far better results than trying to half-commit to communicating the idea of being queer to someone. Adding in a lot of fluff and half-statements usually just leaves them confused.)

Before transitioning, I maintained a strictly professional policy at work, where I would mostly keep my personal life out of the conversation and stick to the safe topics. However, existing as a trans person isn’t a safe topic. It’s not something you can just hide from 9–5, and then take off your straight mask. Existing as a trans person is visible. It’s vulnerable. Accepting this fact and learning to make space for the emotional aspects of myself in the workplace was a foundational step in finding my new groove.

Professional vulnerability is a topic we don’t often talk about, but I think it’s at the heart of our experiences with one another. Professional vulnerability is letting your whole self exist in the workplace. The relationships with my team, my boss, and my colleagues have exponentially improved since I allowed myself to talk to them in a very professional but authentic way. Furthermore, coming out as a queer person at work has afforded me the opportunity to be an advocate and ambassador in many more ways than I could have previously imagined. One of the most impactful opportunities I’ve had during my time at Xandr was hosting an open conversation in our work Slack with a list of questions I had chosen that colleagues could ask about my experience as a trans woman. Breaking the barrier of discomfort around interacting with a trans person is the most effective teaching I can offer in my position.

Stories like mine are why Trans Day of Visibility is so important for so many other queer people in the workforce. I would not be where I am today without the thousands of magnificent trans people who were visible before me. I am so honored to be in a place where I can exist visibly and authentically to the world. We must continue to build an environment of trust, professionalism, and vulnerability so that our fellow queer colleagues, family, and friends can come to work as their whole selves.

Here are some things you can act on now to help your LGBTQIA+ colleagues feel comfortable in your workplace:

· Lift your trans and queer employees up, and make them visible

· Invest in building an active employee group, with allies and sponsors from leadership teams

· Get involved in queer tech conferences

· Offer comprehensive medical coverage for your trans employees informed by the actual experiences and needs of trans employees

· Be open to, receptive to, and excited about feedback from your queer coworkers

· Bring your whole self to the workplace to promote the same in others

· Share your pronouns in your email signature and as a formality when meeting someone for the first time

Visible and Trans at Xandr was originally published in Xandr-Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Having a full-time job can be stressful, but adding family planning to the mix can have some of us working overtime.

In our early 20s, most of us are in a self-discovery phase, adjusting to the transition from full-time student to full-time worker. As we near our late 20s and early 30s, conversations around career advancement start to arise. And for many of us, career planning is coupled with conversations at home around family planning.

Starting a family doesn’t look the same for everyone. For some, it can pose quite a challenge, and that challenge can be compounded if you’re trying to advance your career at the same time. People get pregnant and have families all the time, and increasingly they can be open about their family concerns in the workplace. However, fertility treatments and miscarriages continue to be taboo for discussion.

Women’s History Month feels like the perfect time for me to open up about my struggles with family planning and infertility challenges in the workplace. 2018–2019 was a tough year for me personally. During that year, I finally gave up on having a child naturally on my own and turned to IVF (in-vitro fertilization) for help.

During this time, I was also starting to transition from an executive assistant role at Xandr to a new role in project management. My new job came with a lot of new expectations, and I wanted to show up with my best foot forward, impressing my new teammates and manager. However, this became more and more challenging. Because IVF requires a lot of doctor’s appointments and involved quite a few unexpected surprises, it was harder and harder to commit to meetings, and to establish goals for my new career path.

Infertility treatments involve daily injections, surgeries, and lots of bloodwork. For some, these treatments can span 3–4 weeks, and for others years. Sometimes I wouldn’t know when I would have to come in for an appointment until 24 hours before. The unpredictability made it hard to say yes to any new opportunities that came my way.

My confidence in succeeding at work began to slowly fall. It was hard for me to share what I was going through. This was such an intimate private topic in my personal life — how was I going to share this with my new manager? I wanted to have the same opportunities as everyone else on my team, but the idea of sharing what I was going through made me fearful of losing the chance for a promotion, or to be considered to lead a new and exciting project.

Once I was able to come clean to my manager about what I was experiencing in my personal life, he was able to educate himself about the process. It became much easier to show up at work and feel supported and understood without sacrificing professional opportunities.

How can we do better in the workplace?

Policies that directly address infertility can make a big impact on supporting families with these challenges. It’s hard to be open about what you’re going through when most company policies around parenthood focus on the success of having a child, rather than the struggle. Xandr recently crafted a policy around miscarriages that made it easier for me to let my current boss know about my pregnancy loss when it happened, since I knew there was an understood process for supporting workers who experience a loss.

I would love to see more manager trainings, education, and policies around infertility, so anyone who’s affected has an easier time being open with their managers, rather than feeling they’re going to be punished in the long term by having to take a step back on work responsibilities while they undergo treatment.

I feel thankful to work for a company that continues to improve and adopt policies to help women feel supported in the workplace. However, not everyone is fortunate enough to experience this kind of support. Women should not have to choose between growing a family and growing their careers. More workplaces need to adopt policies to make us feel supported, no matter what our family planning process looks like.

Coping with Fertility Challenges in the Workplace was originally published in Xandr-Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Note: Xandr is involved with various industry TV research groups (ARF, CIMM, MRC, TVDI) and we are often asked for our uses and needs with TV data. This blog piece is derived from a perspective document that we shared with one of those industry groups — TVDI, the TV Data Initiative.

How many people watched TV last night, and what did they watch? “Did they see my ad?” asks the advertiser who has invested a million dollars on a national TV campaign. The answers to these questions are more uncertain now than in the past. The measurement of TV audiences in the United States is at a crossroads, with the longstanding Nielsen panel facing challenges from various quarters, and other measurement companies offering alternatives, mostly via set top box and/or smart TV data.

The causes of this changing environment are:

• Evolving consumer behavior, with streaming now being a significant part of many people’s viewing, on various devices. This has given people more choices and made measurement more difficult.
• Availability of data from streaming sources and set top box data that give insights into households’ use of TV.
• An increased focus on data-driven advertising, that is disrupting both the traditional advertising pod and the standard measurement of age/gender demographics.

All of this matters to Xandr because we enable buyers and sellers to plan and transact on audience-based, data-driven linear TV deals via our buy-side and sell-side advanced TV platforms, Invest TV and Monetize TV. Data is the fuel that powers these capabilities, and it is a critical element: dollars spent on TV advertising must be valued in a credible way, and both buyers and sellers should trust the data and the measurement of ad performance. The term “currency data” is therefore often used, reflecting the importance of the data in the $70 Billion dollar business of U.S. TV advertising. This need for trust applies not only to an individual campaign flight but also in a more macro sense — the overall value of the TV advertising market needs to be measured fairly, and in a way that is inclusive of all viewers across the country, regardless of how they watch TV.

Of course, there is no audience measurement solution that is 100% accurate and inclusive. In a free market there will always be different consumer choices, and the data associated with some of those choices may not be made available for audience measurement. A smart TV manufacturer may not wish to share its data with the industry, and even if it does, not all consumers will opt-in to data sharing. For those that do, knowing what’s on the screen doesn’t tell us who (if anyone) is watching that screen or paying attention. Data about the household and persons in the home may also be incomplete or inaccurate, meaning that “deterministic targeting” via addressable may not be as precise as hoped. We need to accept that every deterministic data point has a probability of being right or wrong. Understanding this and shining a light on the likely accuracy of classification data for targeting is an essential part of assessing whether an ad campaign has achieved its potential.

Panel measurements can provide answers to some of the gaps that arise with big data sources. Any household, regardless of technology, can potentially be part of a measurement panel, persons viewing can be tracked in these homes, and their demographics accurately identified. But the scale of measurement panels is constrained by cost, gaining cooperation can be problematic, and viewing on some devices or in some locations may be missed.

Xandr’s perspective on data, present and future, is pragmatic but aspirational: we have to work with existing sources for business to continue, but we are committed to working with the industry to make TV measurement better and to offer alternatives to our clients. Key elements that we care about when considering TV measurement data:

1. Agreement from buyers and sellers: Xandr is committed to helping our clients grow their business. We won’t invest in data unless there is demand from our clients or a clear potential future demand that makes investment worthwhile. Any investment in potential currency data needs to be financially realistic: there is often a long runway to significant adoption of new data and unless new data sets are priced appropriately based on their usage, we will not be able to justify the expense. Data value is proportional to use.
2. Privacy: An obvious consideration. Our advanced TV platforms do not directly use any PII, and we will not use data unless we are confident that all privacy requirements around the data have been met.
3. Granularity: Our platform provides sophisticated algorithms such as reach optimization, that require household or person level data. While program average commercial minute audiences (often referred to as C3 or C7 ratings, depending on whether the ads are viewed within three or seven days of broadcast) are still used for measuring TV ad exposures, second-by-second data is becoming a requirement now as the industry looks at more precise measures of ad exposure.
4. Accuracy: Bigger is not always better. The accuracy of any measurement has two main elements — sampling error, related to the sample size of the measurement, and non-sampling error, also known as bias. Traditionally, TV measurement has been affected more by sampling error than bias due to the relatively small size of TV measurement panels. Bias was typically agreed to be low as the panels were well designed and maintained. They were (and are) subject to continuous and rigorous scrutiny, both by the data supplier and the users of the data, as well as independent auditors. With the advent of big data sources — set top box and smart TV data — small sample sizes are no longer an issue, but the second element of accuracy — bias — can be a significant problem. A sample of 7 million smart TV’s does not have significant sampling error if considered as a sample of the U.S., but it will likely have significant biases and omissions in representing the viewing of all Americans. Standard demographic weighting will typically not correct for all these issues. Some media owners will be relatively over-reported and some under-reported, causing friction and dissonance.
5. Connectivity: Viewing data must be connected to audience target data for it to be actionable. This connection needs to be as friction-less as possible, and viable economically. For cross-platform uses, connection to digital data, including connected TV, is also important.
6. Completeness: Xandr’s advanced TV platforms, Invest TV and Monetize TV, represent TV inventory that is viewed by 300 million Americans in 120 million homes. TV measurement data should represent all these people and reflect the diversity of viewers and viewing habits.
7. Transparency: Any measurement data supplier should be open to independent auditing and provide transparent descriptions of methods and data sources. For companies who wish to provide currency measurement there should be a commitment to achieve MRC Accreditation.

Currently, media owners and agencies are assessing measurement alternatives and announcing new partnerships with vendors on an almost daily basis. Meanwhile Nielsen is overhauling its TV measurement to create Nielsen One, which aims to combine its small but representative panel with big data sources. With so many alternatives, it’s unclear exactly where the industry is headed but it’s clear that change is coming.

Who’s Watching? Xandr’s Perspective on TV Audience Measurement was originally published in Xandr-Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.