Overview
During my time working on Microsoft Feed, I contributed to product engineering across web and mobile experiences, feature development, engagement measurement, system integration and production reliability.
My work included implementing product features, improving the way content engagement was measured, investigating performance issues, supporting production systems and collaborating with partner teams.
This case study is about what that work involved beyond writing the feature itself: testing it, measuring it, making it accessible, keeping it reliable and supporting it after release.
Background and context
Microsoft Feed brings relevant work content, such as documents and posts from the people around you, into a single feed that appears inside other Microsoft experiences on the web and on mobile. A feed like this is shared ground. The feed team builds the experience, but it runs inside apps owned by other teams, draws on content and signals owned by others again, and depends on analysis from data teams to know whether a change helped.
I worked on this as a Software Engineer from April 2021 to September 2023, as one member of an engineering team. The features below were team efforts; where I describe my own contribution, I say so.
The problem, and why it mattered
A feed is only useful if people find what is in it worth their attention. That raises three practical questions that shaped most of my work:
- Is there something worth interacting with? Features such as reactions and social signals give people more reasons to engage with content, and give the feed more information about what matters to them.
- Can we tell whether people are actually engaging? Without reliable measurement, it is hard to know whether a change to the feed helped, hurt or did nothing.
- Does it hold up in production? The feed has to be fast, accessible and dependable in every app that hosts it, including after a feature has shipped.
My role and contribution
My work fell into five areas, covered in the sections below:
- implementing and rolling out product features, including SharePoint News Reactions;
- implementing dwell-time tracking and improving the reliability and privacy of feed telemetry;
- performance work, including compression experiments;
- accessibility fixes, testing and code review;
- production support through on-call and incident investigation, and helping teammates through onboarding, pairing and documentation.
Product direction, overall architecture and the final rollout decisions were shared with my team and partner teams.
Feature engineering and product delivery
SharePoint News Reactions
I worked on bringing reactions to SharePoint news posts in the feed, so people could respond to news directly where they saw it. Most of the work was not in the reaction button itself. It involved understanding the product requirements, agreeing behaviour with the partner teams who own the content and the host apps, testing the feature on each client, and supporting it through a staged rollout to production and the iterations that followed.
Along the way, I helped replace an older implementation that recorded the reaction a person had chosen as part of a telemetry event name. Event names should not carry a user's choices, so the replacement kept that detail out of telemetry logs.
Social signals in the feed
I also helped bring social signals into the feed: SharePoint posts that people around a user had liked or commented on. This meant onboarding those signals into the indexed content store the feed draws from, which required learning an indexing system that was new to me and adding new indexes so the feed could use the signals when selecting content.
Shipping carefully
For both features, I wrote test documents for the people validating them, tested shipped scenarios myself, and followed the features through staged rollouts. Finding an issue before release is cheaper for everyone than finding it in production.
Engagement measurement
Why measuring engagement is hard
A simple way to measure engagement is to count what was shown. But "shown" is not the same as "seen". An item can be rendered below the visible area, scrolled past in a moment, or still on screen when the user switches to another app. To measure engagement meaningfully, the feed needs to know when an item is actually visible and for how long.
Dwell-time tracking
I implemented dwell-time tracking, which measures how long content stays visible to the user. The approach was based on visibility rather than rendering: time counts while an item is in view. Getting this right meant handling two kinds of lifecycle:
- Item lifecycle. Items enter and leave the viewport as people scroll, and a timer must start and stop with them.
- App lifecycle. The app can move to the background, the user can navigate away, or the session can end. Measurement has to pause, resume or finish correctly in each case, rather than counting time nobody spent looking.
I worked with partner teams on how the measurement should behave in the web and mobile experiences, since each client had its own implementation.
Making measurement trustworthy
Two lessons from this work stayed with me:
- Plan for experiments early. Making key parts of the behaviour configurable from the start made it possible to run controlled experiments and adjust without new releases.
- Compare like with like. An experiment is only informative if the treatment group differs from the control group in the one thing being tested. Each client also had to be analysed separately, because the clients did not behave identically.
I also learned to produce experiment scorecards so we could review features such as dwell time ourselves, and then helped teammates produce their own.
Telemetry reliability
Measurement is only as good as the data that arrives. With a colleague, I worked on a fix for mobile telemetry where user actions were collected and sent in timed batches. On Android, actions could be lost if the user navigated away from the feed before the batch was sent. Sending user actions one at a time, in order, removed that dependency on the timer, and the change was rolled out.
Documenting invisible changes
Changes to measurement have no UI to look at. I wrote up the dwell-time analysis, the user-action fix and a back-off algorithm, explaining the problem, the approach and the trade-offs, so that stakeholders and other teams could understand and review them.
Performance and system reliability
Compression
I took part in feed performance work around compression:
- Response compression. I helped roll out compression of feed responses. A controlled experiment showed faster response durations for users who had it, and the change was rolled out to everyone based on that result.
- Request compression. I also ran an experiment on compressing requests. The results were hard to interpret because the experiment groups were unevenly distributed. Together with a colleague, I concluded that the experiment would not give a reliable answer and that the team should rely on a different approach (persisted queries) instead. Bringing the investigation to a clear conclusion was worth more than leaving it open.
Production support
I joined the on-call rotation for the group's services and the team's own support rotation. This meant responding to alerts and incidents, monitoring reliability, communicating status, and contributing to root-cause analysis so that fixes addressed causes rather than symptoms. I also kept an eye on nightly builds to keep the pipeline green and brought in the right people when a longer-term fix was needed.
Accessibility and engineering quality
On mobile, the keyboard focus on the feed's primary button was not clearly visible. People who navigate with an external keyboard, including people with motor impairments, need to see where they are. Building on colleagues' earlier work on external keyboard focus, I fixed the issue so the focus indicator became visible.
More broadly, I tried to make quality part of everyday work. I was an active reviewer of pull requests and design documents, paying attention to the details that are easy to miss, and I tested shipped experiences rather than assuming they worked.
Collaboration and knowledge sharing
Most of this work crossed team boundaries: host-app teams, content owners, data and analysis teams, and other feed engineers. Alongside that, I:
- supported an intern through a feature implementation, including debugging, brainstorming and reviews, and explained the flighting process, test documentation and rollout planning;
- paired with teammates to unblock each other;
- shared what I learned, through write-ups and team documentation, so others did not have to rediscover it.
Outcomes
- Shipped: SharePoint News Reactions, rolled out to production.
- Shipped: response compression, after a controlled experiment.
- Shipped: the fix that sends mobile user actions one at a time, and the removal of a user's reaction choice from telemetry event names.
- Implemented and rolled out in stages: dwell-time tracking.
- Concluded: the request-compression experiment, with a recommendation to use a different approach.
- Ongoing contributions: on-call and incident support, code and design reviews, documentation and onboarding.
Lessons and reflection
- Measurement is part of the product. If a team cannot trust its engagement data, it cannot make good decisions about the feed.
- Design experiments before you need them. Configurability and comparable groups decide whether an experiment can answer its question.
- An inconclusive result still needs a conclusion. Saying clearly that an experiment cannot answer the question frees the team to try something else.
- Shipping is the middle, not the end. Rollout, support, accessibility fixes and incident work are where a feature proves itself.
What I would do earlier next time
- Agree the analysis plan for each client before implementing a measurement change, rather than discovering differences later.
- Make accessibility checks part of the definition of done for every new scenario, rather than a review near release.