I’m a Software Engineer at Square , and I was promoted to a Level 6 (team leader) Individual Contributor (IC) two years ago.
I didn’t have a chance to reflect on my learnings, but a colleague recently reached out regarding my promotion packet. He was working on his application and wanted to see mine as an example and get some pointers.
I’m publicizing the advice I shared with him in hopes that others who are also applying for IC promotions can find it helpful.
Here are 4 tips I learned from my promotion application.
1. Prioritize collaboration over personal achievement
It took me two tries to get the L6 promotion.
One of the reasons my first application was rejected was because I showcased an incident where I independently “saved the day”. I helped my team meet a Monday deadline by working over the weekend to fix a problem I discovered late Friday evening.
This came as a surprise to me because I felt like I was demonstrating competence, determination, and ability to carry the team.
However, the promotion committee argued that I was enabling poor work-life balance by setting a precedent for others to also work overtime. This was a project underestimation issue, and I shouldn’t have carried the consequences independently.
Given that L6 is a team leader, it was important I operated at a higher level of awareness and leadership. Instead of acting alone, I should have discussed with the team so the deliverables and target dates could be adjusted and not disrupt anyone’s work-life balance.
To prepare for my next promotion packet, I put collaboration work before independent contributions and sought opportunities to lead and raise others.
2. Collect testimonials from everyone you work with
The promotion packet had a peer feedback section but was limited to engineers at the level you’re applying to. In my case, L6 engineers. This section was tough for me to complete because I hadn’t worked with many L6s. Not being able to ask most of my colleagues for feedback made me feel like I was at a disadvantage.
After struggling with this, I eventually came to the realization nothing was stopping me from including quotes & testimonials from others outside of the peer feedback section.
I started reaching out to everyone I worked closely with: L5 engineers, product managers, designers, and engineer managers. And I asked them for a testimonial on their experience working with me. My promotion packet was scattered with quotes from my peers in varying roles, adding lots of colors and boasting collaboration.
As an added benefit, personally reaching out for feedback allowed me to have more control over the process. The official feedback was collected by my manager through a Google Forms survey, and sometimes, it resulted in unengaging or irrelevant feedback. Reaching out directly created opportunities to follow up for details & examples.
3. Share your Hype Doc when soliciting feedback
People don’t often remember your contributions.
This is understandable given I struggled to remember my own as I put together my promotion packet. And when peer reviewers don’t remember, they dread writing your feedback because it takes them a lot of work to revisit old documents and conversations. As a result, they might end up submitting low-quality feedback near the deadline.
To make it easy for anyone providing me feedback, I published my Hype Doc internally—a document of my accomplishments to track my growth. I made it into a website and hosted it on GitHub Pages, but a scrappy Google Doc with bullet points will suffice. The point of having it hosted online is to reduce friction for the reviewer to remember, learn, and talk about your work. Try to write less, make it skimmable, and prefer showing over explaining (via links and screenshots). I linked my Hype Doc everywhere, even in my Slack & GitHub statuses.
Making my contributions easily accessible helped me get insightful and relevant feedback in a timely manner.
4. Develop documentation habits
I struggled to find high-quality examples when trying to find links to demonstrate my work.
Collaboration often happened on temporary and unlinkable mediums like instant messaging or meetings. And the links I found had no description and required work to understand when linking them was supposed to make it easier. Worse case, they made me look difficult to work with.
I felt I missed a lot of opportunities at the cost of a minute to document them.
This frustration inspired me to adopt better habits that help me document my work with little effort:
Improve transparency & discoverability
I started moving discussions from private to public platforms.
When appropriate, I moved conversations away from direct messaging, email, and meetings. Instead, I started encouraging conversations on JIRA tickets, GitHub issues/discussions, and Google Group threads.
As a result, my conversations and contributions became preserved, discoverable, and linkable.
Improve readability
I started to broaden my target audience in my writing and paid extra attention to spelling, grammar, and formatting. Whenever possible, I would add links, screenshots, and context.
To write more inclusively, I adopted a great tip to think of the tools used by non-English speakers and people with disabilities: Are your sentences simple enough for Google Translate? Can your spelling and punctuation be dictated by a screen reader?
I also generally avoid slang or niche references (e.g. jokes) as they can confuse outside participants.
These practices helped my writing become more accessible and easier to read. And as a bonus, my contributions looked credible and started to get referenced by others.
Improve skimmability
I started to adopt templates and structure to my writing to make them easier to skim.
For general writing, I adopted the Pyramid Principle —a writing structure to start with the point, followed by 3 reasonings.
For commit messages, I adopted Conventional Commits —a simple template for commit messages so they can be easily skimmed and parsed by programs.
For pull requests, I fill out sections “Problem”, “Changes”, and optionally “Other info”.
As a result, the documentation I wrote was not only faster to read but also faster to write because I was filling out a template.
Parting thoughts
My promotion packet was by no means perfect but I’m very proud of how it helped me grow as an IC. These skills helped me communicate better, collaborate more, and expand my reach. After all, the engineering ladder is supposed to reflect your competence as an impactful engineer.
I hope you find these tips helpful to your growth as well.
Good luck on your promotion!
