You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: _posts/2025-12-29-a-decade-at-github.md
+7-3Lines changed: 7 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,7 +31,11 @@ One of my mentors taught me a technique that changed everything. Instead of jump
31
31
32
32
This question was gold. While most of our tickets were about GitHub's API and integrations, this simple prompt revealed *how* people were actually using the platform and *where* the interface mattered most to them. That context helped me course-correct my replies and connect customers with the right resources and people.
33
33
34
-
The difference between a great question and a regular one? Context. Great questions are specific and get to the heart of what matters to your audience. As I moved from support to program management to partner engineering to product engineering, my questions evolved—adapting to different audiences (customers, stakeholders, partners, cross-functional teams) while becoming more refined as I gained context about what each role needed.
34
+
The difference between a great question and a regular one? Context!
35
+
36
+
**Great questions are specific and get to the heart of what matters to your audience.**
37
+
38
+
As I moved from support to program management to partner engineering to product engineering, my questions evolved—adapting to different audiences (customers, stakeholders, partners, cross-functional teams) while becoming more refined as I gained context about what each role needed.
35
39
36
40
## 2. Finding a mentor early on can make or break the experience
37
41
@@ -41,7 +45,7 @@ I asked my manager how to approach him, and over the next 3½ years, we worked t
41
45
42
46
What made Ivan exceptional wasn't just his technical depth. He identified my superpower early: finding the right people to tackle a problem and building shared understanding across teams. He sponsored me by giving me an opportunity to present at an internal summit on the integrator experience, speaking alongside leaders from engineering, product, and design. That moment let me formalize what I did, how I did it, and why it mattered. It expanded my trajectory from support engineer to product engineer.
43
47
44
-
Later, when GitHub Actions launched, I became the internal ombudsperson for the feature, leveling up my team and empowering customers. Watching my own progression made me realize something critical: mentorship creates a debt you pay forward. I started seeking out people without mentors, trying to offer what Ivan had given me.
48
+
Later, when GitHub Actions launched, I became the internal [ombudsperson](https://en.wikipedia.org/wiki/Ombudsman) for the feature, leveling up my team and empowering customers. Watching my own progression made me realize something critical: mentorship creates a debt you pay forward. I started seeking out people without mentors, trying to offer what Ivan had given me.
45
49
46
50
Years later, after several internal pivots, Ivan and I still check in every few months. We work in the same engineering organization now. I still look up to him, and I'm certain I wouldn't be the same person without his guidance.
47
51
@@ -59,7 +63,7 @@ This practice evolved across my roles. Today, in the age of AI tools, I use Copi
59
63
60
64
## 4. Don't just teach your team—find others who use the same technologies and equip them too
61
65
62
-
When I became the ombudsperson for [GitHub Actions](https://github.com/features/actions), I published our internal support documentation in a location where product engineers could see what we were working on and what questions we were getting. Other teams working with integrators and customers building on GitHub Actions could use it too.
66
+
When I became one of the internal [ombudspersons](https://en.wikipedia.org/wiki/Ombudsman) for [GitHub Actions](https://github.com/features/actions), I published our internal support documentation in a location where product engineers could see what we were working on and what questions we were getting. Other teams working with integrators and customers building on GitHub Actions could use it too.
63
67
64
68
This was a turning point. I realized I enjoyed being in the weeds—and sometimes climbing up to see the forest. That forest-level view came from pausing to reflect: What's the core issue or lesson here? Who else could benefit from what I've learned?
0 commit comments