Case Study: TINT

With clients as diverse as Wimbledon, Krispy Kreme, and Bad Girls Club, TINT is reimagining how companies present their social media content. From their charming offices in San Francisco’s Mission district, we talked with CTO Nikhil Aitharaju about how the content-marketing platform got started, the evolution of social media, and getting their agile sea legs.

Thanks for talking with us today. How would you describe TINT?

TINT is a content marketing platform that helps brands aggregate user-generated content from different sources—including social media sites like Facebook, Twitter, and Instagram, or community sources like Slack and review trackers—and showcase them on on their marketing channels like their site, email newsletters, and store displays.

A great example is Krispy Kreme. They have a lot of content on Facebook and Instagram, with people posting images of their donuts. Instead of updating the website everyday manually, they pull in this content automatically through TINT and make their website look more engaging. This leads to an increase in the amount of time users spend on the website, more engagement, and eventually more leads and sales.

That’s fascinating. Is someone at Krispy Kreme moderating the content? How fast is that process?

It’s pretty quick. It’s self-serve; you can sign up for free, and then immediately you can choose which ones you want to moderate. If you don’t want spammy content going on the screen, you can pick and choose the UGC that will be displayed. So if there are complaints or negative posts, you can keep them off your TINT displays.

That’s just one use case. Another is employee engagement in offices. We use Slack, and we integrate Slack with TINT. We can pull in content from Slack channels, like fun, winning channels, then showcase them on TV screens. We have a few TV screens outside in our dining area where we pull in content that employees created on Slack. We have a self-improvement channel, where people post about what they’re working on for that month to improve themselves. They upload images, and we’re able to showcase it on the TVs.

It’s cool that you’re doing this. How did TINT come to be? You’ve been around for a little while now, and the social media landscape has changed a fair amount in the last four years.

We started off as a bookmarking website, similar to Pinterest. It was during the time Pinterest was taking off. We kind of latched onto that idea, and then built a Pinterest clone for bookmarking your favorites websites and articles.

We had a chicken-and-egg problem, where we wanted to people to create content of their own before consuming content through our website. In order to overcome this problem, we added Facebook and Twitter link imports. Whatever links that you’re sharing on these networks would get automatically pulled in to your board on our website, increasing the amount of content being shared.

There’s an agency in LA called Collective that was implementing a website for Toni Braxton. They wanted their website to be engaging, and they thought our solution would be helpful since they didn’t have to keep updating their site manually—they could just pull in content from their fans. That’s how TINT evolved. We didn’t come up with the idea right away; we started off with something else, saw an opportunity and a demand, and that evolved to become TINT.

Is scaling your biggest headache?

In terms of the company in general, scaling the culture definitely takes a lot of effort, and it drains us sometimes. This will evolve as we continue to grow. For now, I think scaling the company on the culture side has definitely been more of a challenge.

How would you describe the software development methodology you use?

I would say agile. We implement all the key agile ceremonies like iteration planning meeting, iteration retrospectives, daily standups, etc. We also pair on some key projects.

“I think scaling the company on the culture side has definitely been more of a challenge.”

How did you make that switch? Did you just wake up and decide to be agile one day?

There were some transition periods. Initially we did product planning as a team. Last year, all of us would sit together and do it. That wasn’t scaleable, though, so we divided into three different teams. That didn’t work right away: people had their own deadlines and processes, and it wasn’t going well. I came up with a proposal to try agile, so we would actually do iteration planning, product planning, and sit together and assign points to stories, so that it’d be more accountable. And that way, we’d only be focused on a two-week period instead of a three-month period. It slowly evolved, and we learned from our mistakes.

We’ve been trying this out for the last two months. Not pairing—we were doing that already—but the whole process around agile planning is something that I introduced. I think so far we’ve been planning well ahead of the time instead of planning for the next week. We’re more prepared; every team is aligned about when things are going to be out. We still have challenges in estimating—we’re trying to get better at it.

There will always be frustrations! Hopefully Tracker isn’t causing too many of them.

When we first started a year back, we were all kind of hesitant because we didn’t know how Pivotal Tracker was going to help us, except for writing stories and tracking them. We weren’t really using Tracker at first; we had it just for the sake of having it. We wanted some sort of a tracking app. Then we realized that it is a powerful tool when you use it the right way. I don’t think we’re even doing a good job with it, and there’s a lot of room for improvement, but it’s still helping us. We have a clearer view of where we’re going; everything more sense now than it did before.

What were you guys using before Tracker?

Trello.

Interesting, and why did you switch? Does part of the company still use Trello?

Right now we have very disparate systems to track within departments. Initially when we started, we had Trello boards, and we made to-do lists of tasks we were working on. Then slowly, as we added more people, it became harder to view what they were doing and more difficult to keep up with. So we moved from Trello to Tracker, because one of our employees who joined liked the system and pushed us to use it.

We adopted it, and right now I think we have learned and evolved. We didn’t know how the tool worked initially, because we didn’t know the whole agile process.

It can be frustrating if agile is a new concept to grok. How do you point stories? Do you point as a group?

The reason we’re not fully agile yet is because we don’t work off of a single backlog; we have every group working on their own mini backlog from the backlog.

We usually have the stakeholders work on stories before our biweekly iteration planning meeting. We assign points as a group during our IPM.

So it’s a discussion around the points that they give you?

Exactly. We also assign points in the IPM. Before, we didn’t have any of this, we had only project assignments and then people would go back to their desks and write stories. But we changed it, and asked them to write stories before they come to the IPM.

What benefits does Tracker bring to you?

The ability to easily integrate Tracker with our existing tools is a huge benefit. For example, we add story IDs in our commit messages, and the GitHub hook automatically changes the status of the story. This saves us a lot of time.

“In terms of Tracker’s true benefits, I think we’re just reaping those benefits right now. What made us stay with it so far was the ease of use. At least story-wise, I think it was pretty easy to understand, and good integrations made it easy to use.”

Who else do you integrate with?

We have a Desk-to-Tracker integration that can help the Support team to triage the issues on Tracker itself instead of using two different tools. We also have an internal Wufoo form for bugs reporting that is integrated with Tracker via Zapier. We have a Pivotal-to-Slack integration to notify us when a feature is accepted/rejected. We figured out that this workflow is best for us and it’s been working out really well so far.

We had a lot of systems tied to Pivotal. In terms of Tracker’s true benefits, I think we’re just reaping those benefits right now. What’s made us stay with it so far was the ease of use. At least story-wise, I think it was pretty easy to understand, and good integrations made it easy to use. Those two distinct benefits stood out to us. And once we’d integrated Tracker into our daily workflow, it was difficult to switch.

Are most of your engineers on board with Tracker, or do you think a few would like something else?

I don’t think anyone has any issues with using Tracker. Some of them find Tracker to be a little opinionated in some ways, like not being able to assign points to certain tasks. I do see where they are coming from. For example, when you’re trying to work on infrastructure-related tasks, not being able to assign points to those tasks can make someone feel like they are not adding value.

On the flip side, I do understand that the philosophy behind not estimating bugs/chores isn’t that bug fixing doesn’t deliver business value, but that introducing a defect into the app and then fixing it does not represent true forward momentum. I think it’s a very thin line, and the only way you’ll learn is if you experiment with one way or the other instead of having debates around this topic.

“The real benefits of Tracker come into play when you truly work in an agile environment—assigning points during your IPM, organizing your backlog, and working off of your backlog.”

If anything, it’s that people want recognition for the work they’ve done.

Exactly. Right now, we’re still in the adoption phase of agile. I think the next step would be honing in on the velocity. One of my own goals for this quarter is to measure the volatility of our velocity. The whole team is willing to attend an agile training session to hone in and work in a truly agile format, so I’m trying to see if I can provide any sort of training opportunities to help the team to adopt that mindset.

Photo credits: Amrit Singh

Yeah, that’s a great idea, get everybody on the same page. If someone is new to Tracker, and they were asking you for words of advice on how to get started, what would you say?

I think the first question I would ask them is if their team is following the agile methodology? If not, Tracker won’t really be helpful and will only serve as a tracking tool for your features. We made that mistake early on. The real benefits of Tracker come into play when you truly work in an agile environment—assigning points during your IPM, organizing your backlog, and working off of your backlog. It’s also gamification—you feel good when you complete your tasks and get your points, which raises motivation.

To summarize: adopt the agile workflow before you start using Tracker.

Is there any reason for a software development team not to be agile?

No, there’s not a single reason.

There are many different variables that make up software teams, but no matter the size or industry, we share a lot of the same challenges. And while Tracker is only a small part of the equation, we’ve begun collecting these stories with the hope that we can all learn from them. See the other case studies here. Want to share your story with us? Get in touch.