How I started talking to customers in my first week at incident.io

I’m one of three new interns at incident.io and despite only having been here for almost two months, I’ve had an amazing experience so far. I was both incredibly nervous and excited in the weeks leading up to my first day as this was my first internship experience and I didn’t really know what to expect.

All I knew was that I wanted to work at incident.io as it’s a company whose product, values and overall vibe is something that I truly admire.

From the moment I joined in April, I never imagined that within just a few weeks, I would be shipping features and directly engaging with our customers. The way I see it, this experience has been more rewarding than I ever would’ve thought. Seeing the excitement and satisfaction customers show when I deliver a new feature or bug fix has been a powerful motivator. This is one of the many drivers that makes me work harder to strive to bring more delight and value to our users.

So how did I achieve this? Let me take you through my first couple of weeks at incident.io and find out.

My first feature

You have probably heard us talk about pace a million times before, but it’s one of the main values that we live by here at incident.io, and it's constantly mentioned both internally and by our customers. However, as an intern, I thought I would spend my first week or so on extensive onboarding before diving into coding.

Boy, was I wrong.

After a few typical onboarding sessions and set-up of my local development environment, I jumped right into writing my first lines of code just two days in. My first feature?

Drum roll please…to make the incident.io logo on the dashboard clickable!

I know, right? It's absolutely groundbreaking stuff. All jokes aside, this was quite surprising, as I just assumed this would be a given within the product. Nonetheless, I dove straight in, got my first exposure to the front-end code, quickly made my first PR, and merged it in. I then watched as my ticket moved from ‘In Review’ to ‘Ready to Comms.’

This was a bit confusing to me at first. But it turns out this was a piece of UI feedback we had received from a prospect in our community channel. So I thought, ‘Oh, someone else will do it, they wouldn’t trust me to do it yet.’ Again, I was wrong. I was asked to reply to the message to inform them of the new change.

This marked my first interaction with a customer and it felt great. Although it was a small, nice-to-have feature that wasn’t difficult to ship, it still felt incredibly rewarding as an engineer to see how my code impacted our users. Especially as an intern, I felt like I was being trusted like any other engineer, which falls into another one of incident.io’s core values: trust by default.

The rewarding cycle

This was only the beginning though. After shipping that clickable logo feature, my engineering buddy, Andy, found a great new feature for me to work on that was more than just a nice-to-have. It was something three customers had requested: scheduling debriefs with Microsoft Outlook, a feature we already offer for Google Calendar.

This was a major task, as many companies use the Microsoft Office package, and it marked one of our first dives into the world of Microsoft integrations. Like before, I jumped right in, aiming to create something valuable for the customers who had requested this feature, but also for any future customers who may use the feature. After making my final changes, I relayed the update to the customers. They expressed their gratitude for the feature and confirmed that it was working as expected.

Once again, it felt great.

And the cycle continued. I shipped more bug fixes and small features requested by other customers before starting my first big project. Customers would express their delight or were surprised at how prompt our support was, and I continued to reap the rewards of each change that I made. It is truly a fulfilling experience, and despite being an intern at incident.io, I feel like a true part of the team. My opinions matter and I’m trusted to own features and communicate directly with customers.

Why is it so important for engineers to speak to customers directly?

As a Product Engineer, understanding our customer’s needs and struggles properly allows us to be more mindful about what we create and why. This direct interaction helps engineers see firsthand the feedback they receive, enabling quick continuous improvement of the product.

As I’ve mentioned, seeing a customer’s delight when we ship a new feature or bug fix is incredibly rewarding. This positive feedback loop not only boosts team morale but also motivates us to maintain high standards and swift responses.

For us interns, this process is invaluable. It offers a great opportunity for us to own our features and feel responsible for them. It allows us to be an integral part of the company, actively impacting the product, and it makes us feel proud about our contributions, no matter how small a feature it may be.

Thanks to everyone in incident.io for the warm welcome, the Post-Incident team for being great to work with and shoutout to Ali who has been begging me to include something nice about him in this blog post. He’s alright, I guess. I look forward to the months to come here!