I Got My Coworkers To Teach Me To Code, Then Rewrote My Job Description

One tech employee shares how he successfully enlisted his colleagues to help him advance his career.

I Got My Coworkers To Teach Me To Code, Then Rewrote My Job Description
[Photo: StockSnap/Pixabay]

I hate repetition. I’ve never been content to have my workdays filled up with all the same tasks. But my impatience with repetitive work has actually proved to be a pretty valuable attribute in my professional life. Here’s how I’ve tapped into it in order to change my career–and successfully enlisted my coworkers to help me do that.


Step 1: Spotting A Problem

I first joined Buffer to work on the social media platform’s customer advocacy team. After a few months, I began to notice trends in the type of support emails we’d receive. Our team was encouraged to share these trends with the product and engineering teams. If it was urgent, our engineers would tackle the issue quickly, but I noticed that they’d add non-urgent requests to a list of tasks that was rarely revisited.

Many of them were things the engineers would have been glad to resolve but simply couldn’t in their limited time. Watching this list pile up got me more curious about the engineering team’s work. I occurred to me that if I’d had even a basic understanding of Buffer’s codebase, I might be able to help figure out some solutions to the trends I was seeing–which, after all, directly affected the customers it was my job to look out for.

The problem, of course, was that I had no coding experience.

Related: You Can Do More Of What You Like At Work And Less Of What You Hate

Step 2: Figuring Out What’s Needed To Solve It

I brought all this up in my weekly one-on-one meeting with my manager, and I mentioned my desire to understand how our code works. This way I could contribute a little more directly to resolving the issue I’d noticed. To do that, I suggested starting some beginner PHP tutorials so I could get a handle on Buffer’s functionality.


Two days later, my team lead told me that he’d spoken with one of our engineering managers about me. The engineering manager was thrilled to hear someone on the advocacy team was showing an interest in engineering, and she offered to help me develop the skills I’d need to help work on the issue at hand. Within a week, she’d set me up to be mentored by one of Buffer’s most experienced engineers so I could get some hands-on experience with our code.

Step 3: Putting In The Work

Winning my own manager’s approval and support from the engineering team felt great, but I knew I’d have to work hard to prove it was worthwhile. After all, from the company’s standpoint, the real end goal of this professional development was to help sort out the support-email issue. So I spent my evenings and weekends combing through our code and trying to understand exactly how Buffer was put together.

I quickly set a goal: to deploy one change to our product within my first three months of learning how to code. But thanks to the advice and guidance I got from the other engineers, I picked things up much more quickly than if I’d been teaching myself solo. By the end of three months, I’d far exceeded my expectations–and had deployed 10 changes.

In the meantime, my teammates over on the advocacy team helped keep me afloat, since they knew it was a challenge to balance my current role with the new skills I was working to pick up. Without their support, too, I don’t think I could’ve made such swift headway.

Related: How To Create Your Own Opportunities At Work


Step 4: Making It Official

Now I officially work on the engineering team. After six months of hard work, I was making a noticeable impact our team’s workflows. It was at this point that some of my teammates encouraged me to pursue changing my role officially so I could devote a regular chunk of my workday on engineering tasks, instead of just doing that in my spare time–which was starting to burn me out.

I hesitated at first. But hearing that from my coworkers was validating. I realized that my work had reached a level where other engineers and my own team leads felt comfortable assigning engineering tasks to me. What’s more, many people assumed that my role already consisted of engineering tasks due to the number of changes I’d deployed to our platform. So I decided to go for it.

I sent a lengthy email to my manager, asking for an adjustment to my role. I felt incredibly uneasy about ruffling any feathers–but that didn’t happen. My team lead couldn’t have been more supportive. We agreed to reserve 20% of my workweek for engineering work, keeping most of my existing responsibilities in place as a customer advocate.

Now I was officially working on engineering projects.

Step 5: Finding A Balance

In the months that followed, the scale of the projects I was working on steadily increased. It’s been almost a year since, and I still spend 20% of my time on engineering, and 20% of my salary is benchmarked against Buffer’s salary formula for engineers. The balance works really well.


To date, I’ve completed nearly 100 projects on the engineering team, from small product tweaks to full overhauls of existing functionality and processes–and best of all, none of them feel repetitive.

My biggest takeaway here? Changing your work doesn’t have to be something you lobby for all at once or all on your own. If you show some willingness to put in the work and ask for help from your team–especially when it’s to solve a problem that affects everybody–you’re much more likely to get to “yes.”

Mick Mahady is a customer advocate and software engineer at Buffer.