How Teams Interact: Engineering + Product Implementation

Engineering

Learn from our challenges and triumphs as our talented engineering team offers insights for discussion and sharing.

How Teams Interact: Engineering + Product Implementation

Engineering

LiveRamp has a New York engineering team now (exciting!) and with all of the growth the company is experiencing, it’s a great time to discuss interacting with the team. One of the most common ways to interact with any engineering team is via a ticketing system. At LiveRamp we use a combination of ticketing systems across teams and across request types. Here in New York, we currently use Waffle.io – a great tool that seamlessly integrates into GitHub and features the ability to tag, track, and comment on tickets easily.

When To Ticket

The Product Implementation (PI) Team is encouraged to create and close tickets according to the level of complexity and time available. This workflow benefits the customer, the engineering team, and the LiveRamp team at large. Customers experience faster turnarounds and the team at large benefits from technical points of contact (POCs) who are more knowledgeable of the inner workings of our systems, which in turn frees up more time for the engineering team to focus efforts elsewhere.

So how does PI know when to ticket and when to write a Product Requirements Document (PRD)? Great question. A ticket is generally created when an issue or feature request requires small, quick changes. PRDs are generally created for larger, longer-term changes that require a bit of design work. In both cases, the goal should be that the end-user (internal and/or external) benefits from a new & improved solution. The solution should also improve efficiency and save the team time.

When Not To Ticket

As we discuss tickets vs. PRDs, it’s important to also consider when not to ticket. The overall goals of ticketing are generally to (1) create something new, (2) investigate something interesting, and/or (3) fix something that is broken that doesn’t have an existing, efficient solution. (There are many other schools of thought here but let’s just go with this blanket statement for now.) What is supposed to happen, then, if something works efficiently but can’t easily be applied as a solution? I think one of the best answers to this question revolves around documentation.

Here’s a real example that our team faced back in January. We have an internal file syncing tool that makes it easy to transfer files between S3 buckets and Google Cloud Storage. Previously our engineering team would handle any requests that came in requiring the use of this tool. As requests increased, it became increasingly important for the PI team to use this tool. The problem, however, was that there was no clear documentation around how to use the tool as a non-engineer. With a few quick discussions and a post on our internal wiki, we were able to get the necessary documentation created and into the hands of our PI team further strengthening the team’s function as an extension of engineering.

In conclusion, technical cross-team communications are crucial in any technology-heavy company. Investing in a ticketing workflow and rallying behind strong documentation are just two approaches that can have enormous positive effects on overall team collaboration.