We’re closing in on the end of the fiscal year, which means many Microsoft engineers will be writing Connects. Connects allow you to document your past impact, reflect on what could have gone better, and plan for your future success and personal growth. Connects form the basis for productive career discussions with your manager. Many engineers rightly focus on the “looking back” section, but wrongly write too much.
The “looking back” section of a Connect is the one your manager uses to reflect on your results and prepare for annual people discussions. It’s an important section, but like a resume, longer isn’t necessarily better.
Resumes should tell a concise, easily scanned and referenced story about your accomplishments and how you achieved them. Provide too much detail, and a resume loses its narrative and hides your results—too much noise drowns out the signal. The same is true when describing your impact in a Connect. Need more detail on how to provide less detail, yet represent yourself better? Scan ahead.
What’s the point?
Whenever you write something, you should consider your audience and how you want them to use the information. For a Connect, your immediate audience is management. You’d like them to use the Connect to provide you with feedback and represent you well in people discussions. The Connect is your chance to frame that feedback and discussion.
You could write a novel or a disconnected froth of facts and expect your manager to condense it into a flattering form, but that’s putting great faith in your manager. If your manager has many employees, and all those stories must be relayed up the management chain among so many others, perhaps you’d like to assert more control over the narrative.
Writing a clear, concise, bulleted list of accomplishments and how you achieved them will enable your management to easily describe and reference your impact and hard work, thus giving you the credit you richly deserve.
Read more about communications in You talking to me? Basic communication.
Just the facts
What does a clear, concise, bulleted list of accomplishments look like? How do you retain just enough detail to tell the story, but not so much that you drown it in noise? Follow this simple template for each accomplishment:
- [Clearly measurable impact] by [work you’ve done yourself and/or with others].
You put the impact first. Many folks write about the work first, but that buries the lead—work is nice, but impact matters. That impact should be measurable. Sometimes the measure is binary—you can do something you couldn’t do before—but often it’s percentage changed, revenue generated, time or cost saved, or monthly active users (MAU) gained.
How you accomplished the impact comes second. You could have done it yourself, adapted it from others, contributed to others, or a combination. Regardless, you achieved the result, and the impact is what counts.
If you have a great quote from a customer or partner that emphasizes the positive impact or approach you took, add the quote as a sub-bullet and attribute it appropriately. Supporting quotes add power and authenticity to your claims.
It can be tricky to summarize your achievements in a set of bullets, particularly in a manner that ties back to what your group and customers value. Consider sharing your draft bullets with your manager in advance and collaborating on getting the message tight and effective.
Give you an example
Let’s go over a couple of examples.
Recently one of my group’s engineers, Abdul, helped the Xbox team improve the automated testing of its XDK development kit. Testing dev kits, like the XDK, is notoriously unreliable because you need two connected machines to run the tests: an Xbox and a VM running Visual Studio with the latest XDK. Abdul’s work required coordination across multiple groups, and it resulted in XDK test failures dropping from 20 percent to 2 percent and all-up volume of kit failures dropping 90 percent.
While that’s a nice description, it’s too much text. Abdul’s lead would have to pick out the key points for comment and relay them up the management chain—extra work that welcomes inaccuracies and misinterpretation, especially in a pressurized people discussion. Instead, here’s a statement for Abdul that can be easily referenced and communicated, which follows the simple template.
- Reduced all-up volume of kit failures by 90% and XDK test failures from 20% to 2% by working across the Xbox, test automation, build, and lab teams to improve the multi-machine test system and apply it to XDK testing.
o “Ever since that fix went in, the volume of Kits failures all-up in our system has dropped over 90%. We’ve got a tough road ahead of us for improving official build reliability; the journey is made easier when you’re working with dependable partners.” – Andrew, Build PM
Another of my group’s engineers, Melissa, created a system to archive VSTS build environments and recreate them years later to service a release. Using her system, released components that must be serviced for years, like those in Windows builds, can be debugged, edited, rebuilt, and serviced in the original configuration (build machine, VSTS Tasks, settings, and dependencies). Her work required collaboration across multiple groups and enables thousands of separable Windows components to be built in VSTS outside the lengthy traditional Windows builds. Here’s a statement for Melissa that follows the template.
- Enabled 3000+ Windows components to be serviced in VSTS by collaborating with Developer Services and Windows Servicing and Delivery to archive build agent VMs, VSTS Tasks, build definitions and settings, and build dependencies, then validating that later rebuilds can be serviced through Windows Update.
These examples were used with permission. I’m not including full names because this is a public blog.
Why? Why do you persist?
“But what if I don’t know the impact?” As unconscionable as it might seem, many engineers do their work without considering the impact it will have, aside from getting their manager or PM off their case. If you don’t know, ask your peers, manager, or PM what scenario, improvement, or other result your work contributes toward, as well as the impact anticipated or achieved. Be curious and ask.
For example, another engineer in my group, Karesz, frequently spent time keeping Xbox’s check-in validation system healthy. He asked me about the impact, and we examined it. Why do we keep the check-in validation system healthy? Because Xbox engineers depend on it. Why do they depend on it? Because it keeps the Xbox working branches clean. Why do Xbox engineers care about clean working branches? Because clean working branches enable Xbox to preview builds daily and release builds monthly. Ah ha! Here’s a statement for Karesz that follows the template.
- Enabled Xbox to preview builds daily and release monthly by resolving issues and keeping Xbox’s check-in validation and continuous integration pipeline running smoothly every day.
In all these examples, multiple people were involved deeply in achieving the great results, and they should all proudly proclaim their impact, not just Abdul, Melissa, and Karesz. Innovation goes hand in hand with collaboration.
To gain awareness of the impact opportunities around you, read Opportunity in a gorilla suit.
Can you see the real me?
When you look back on your accomplishments this fiscal year, consider the impact you’ve had and how you achieved it. Make it easy for your manager to comment on your accomplishments by listing them in a simple form that’s easy to recall and reference, particularly when he or she is discussing your results with others. Start with the clearly measurable impact you had, followed by how you achieved it through your own work and by working with others.
By using a simple template, you reduce the amount of typing it takes to document your work, give yourself credit for the impact you’ve had, take pride in the manner you attained it, and make it easy for your manager to recognize it and share it. Less typing, more clarity, and greater recognition—it’s a winning combination.