Trint - Lessons Learned

In November 2014 I co-founded Trint with Dan Schultz and Jeffrey Kofman. Monday, March the 6th 2017 was my last day as employee, CTO and Director of Trint.

In many ways Trint was a commercial embodiment of Hyperaudio - a project funded by the Knight Foundation and the Mozilla Ignite Initiative - you can read more about that in the blog post “The Road to Trint”. Dan and I brought the technology and team with us, whom up to that point had worked on the Hyperaud.io platform, library and application of that code, which you can find within various Al Jazeera Interactives, culminating in the prize winning Palestine Remix.

Before I move on to my next adventure, I wanted to write a little about my key learnings as Project Manager/CTO and how we went from prototype to paid service in fewer than 18 months.

In Team we Trust

I was extremely lucky to be heading-up a uniquely talented development team at Trint. Initially it was made up of Mark Panaghiston (web media specialist and author of jPlayer) and Laurian Gridinoc (his many skills go beyond a quick description) - suffice to say once we’d added Piotr Fedorczyk (front end developer and UX specialist) we pretty much had all we needed to build out the initial beta.

Mark and I go back a long way as part of Happyworm - a web-development agency we founded back in 2001. I met Piotr in Florence at a ‘UX Camp’ in 2011 and Laurian and I (together with Dan Schultz) were OpenNews fellows in 2012.

The team pretty much came fully-formed. I’d worked with everyone on the team on multiple projects and we all knew each other pretty well. Importantly, there was an atmosphere of mutual respect that continues to this day. Not that anybody’s ego was too precious that we couldn’t level with each other in plain terms, you understand!

While working together in the past my role had varied - but as the rest of the team were so well versed in their particular skillset, it felt natural to work alongside them as a project manager and to delegate to their areas of expertise. My job – as I saw it – was to guide, support and to fend off potential distractions. I’d had the fortune to work with great managers in the past and was eager to emulate their success in these areas.

Trust is the glue of life. It's the most essential ingredient in effective communication. It's the foundational principle that holds all relationships. - Stephen Covey

We had a leadership coach for a few months and I always looked forward to our catch-ups. One thing I remember discussing with them was the importance of giving people ownership and responsibility; that it was OK to give guidance and make suggestions, however allowing people to make what might turn out to be the wrong choice, was far better than being prescriptive.

It wasn’t until I stumbled upon a job advertisement for a manager at Medium.com that I realised that the style of management I was practicing was known as ‘Servant Leadership’ and it had been around for a good while. Since then, I’ve been introduced to the Open Organization Leaders Manual which I’m pretty much recommending everyone reads!

Keeping the Main Thing the Main Thing

One thing we agreed on early on, was to play to our strengths and not re-invent the wheel. Our strengths lay in web-media development - more specifically: transcript-driven-web-media development.

When it came to the architecture of our system we felt strongly that there was no need to write authentication systems, file uploaders, transcoders and anything else that we could buy off the shelf as a service. Not that we wouldn’t write our own at some point, just that we would start by concentrating on the bit that was unique to the project and drew from all our skills and experience. That bit was the Trint Editor - a hybrid text/audio editor that took a machine-transcribed audio and video and promised to magically retain those word timings even after manual editing.

This worked out well, the biggest pain point was customising the third party systems - but we could live with that discontinuity for the fabled MVP.

Like I say, you’d maybe want to replace the third party systems later on, so it's worth trying to keep that option open, but it’s freeing to delegate all these functions to people who are specialists in that particular thing - you don’t have to worry about maintenance or usually scaling (as these type of services are usually already dealing with millions of requests).

Just Enough Process ^TM

So what sort of process do you put in place for a ragged group of developers like us? The answer for me was: the bare minimum! Since working on Hyperaud.io together Slack had emerged as the default group chat for developers and other parts of the business alike, we picked up on this and it facilitated a large part of our communication.

Slack, in effect, was our office - and in those early days we seldom left the office! Things are different now and probably for the better, but we regularly used to chat on Slack late into the night, posting links on #clickbait or just hanging out on #random or discussing the technical challenges of work on #techtalk.

All of us having slightly different active times, it meant I had to be pretty much available from 8am until 12am. Since we all got on, it didn’t seem like a chore. Of course we added all the fun integrations such as Giphy and primed Slackbot with suitable amusing messages...

But wait, this section is meant to be about process! OK, so the point I’m trying to make is if you have a highly communicative group, process seems to occur organically in response to needs. We’d soon hooked up GitHub and Trello to Slack, then later Zendesk and Stripe. We needed admin functions and so we created bots to deal with admin commands, thanks to some experimentation from Paty Abreu Mañon and Laurian. There was no master-plan. It was all happening organically inside Slack!

A quick note about creating bots to deal with admin requests (instead of, say, traditional back-office applications) - there are a number of advantages:

• The User Interface is just a series of chat commands which means it’s quicker to build and adapt than a Graphical User Interface.
• No authentication required, just put it in a private channel if you want to restrict usage.
• Comes with a built in audit trail so you can see what actions have been performed, by whom and when.
• Learn from example by scrolling up! No user manual required!
• People can easily help when you’re struggling - it’s group chat!

The point about the admin bot — we called ours Teddy (long story) — was that it was just something that emerged as people experimented with new integrations, it’s not something we planned in advance. The fact that somebody whose principal job was marketing (Paty) felt empowered to play about with bots says a lot for our culture at the time and I feel grateful that we able to foster that culture of experimentation.

Team participation works both ways — and this may seem obvious to many, but — do make sure that you get input on your product from your developers. Also creating rough prototypes to communicate ideas is a great use of time. Trint sharing, Interactive Transcript export and Quick Captions all came from the development team and started as prototypes. Needless to say HiPPO attacks are to be avoided at all costs.

Once we’d got past the MVP point and onto shipping a beta that people would actually pay for (!!!) we decided to add a bit more process. We took some advice from a CTO that had done all this before and put into place a daily dev stand-up, we used a bot called Howdy to collect responses on what we were working on and added TeamSpeak for that low latency push-to-talk voice communication. These three evolutions of our process were enough to see us ship our paid beta on time, with a tolerable amount of bugs and crucially took us to first revenue.

Excel is Your Friend (Wait, what?)

Since we were more Kanban than full-on Scrum, we didn’t really use Gantt charts as such, although I evaluated various applications. In the end I decided to use the Excel-like-clone - Google Sheets. I’d traditionally steered away from tools like this but I soon came to embrace Sheets as a blank canvas in upon which I could pretty much represent anything. There was a bit of a learning curve, sure, but there was something disconcertingly satisfying about filling in those little cells and plotting the occasional chart.

When we first started to see revenue I religiously entered every customer and their purchases into a Sheet, even though this was being tracked elsewhere I wanted to spot patterns, user types and the like and actually found filling in the spreadsheet oddly relaxing. In the end I gave up, but not before I had created a Sheet 1518 x IM columns! I look back at this as a kind of Stockholm Syndrome.

Seriously though, you can bend Excel to most wills. I know both CTOs and CEOs that swear by it. For those interested there’s a great presentation from Joel Spolsky titled “You Suck at Excel!”.

Don’t be Afraid to Start from Scratch (But get buy-in)

Back in 2014 when we were evaluating the state of current web technology, we made a call to avoid using the contenteditable attribute due to inconsistent browser support. (The contenteditable attribute when applied to any HTML element turns it into a type of mini text editor.)

To avoid using contenteditable we ended up writing our own editor from first principles and it’s testament to Mark Panaghiston’s sheer doggedness that we got so far, but at a certain point it became obvious that it wasn’t going to be tenable, not least because our aims had become somewhat more grand and we were now attempting to create a fully-fledged audio-text-editor.

I had a hunch that despite its shortcomings we should re-write the editor using contenteditable. I made some really crappy demos (I’m great at crappy demos) to see if it might be feasible and I remember spending some concerted effort convincing the rest of the development team that it was the thing to do. Nobody likes to throw away code and many hours of development time, so psychologically it’s very difficult to accept that you should start from scratch. This was going to be deeply disruptive to our roadmap, so I wanted us all to be agreed. Note: there was no guarantee that this approach would work.

Next, we had to let the rest of the company know that we were going to be several months ‘late’. Always a bitter pill to swallow, but one we did. In the end it appeared to be the right decision, unbeknown to us we were dealing with a lot of the issues that Facebook were dealing with when writing Draft.js - if only Draft.js had emerged a few months earlier!

Measure Everything (You Don’t Know Shit)

There’s a type of paradox that manifests itself early on in a lean startup’s development: you want to validate your assumptions, but you don’t yet have any users to get validation from. Our approach was to conduct user testing - wary of our biases, we made sure that we employed a professional to do this. We got several key learnings from this approach and I think those early usability tests definitely had an influence on what we built next.

However the data was limited and it was very qualitative, whereas we really wanted some quantitative data to complete the picture. You need both!

Interestingly, due to time pressure when we refactored the editor, we left out a number of key features that we’d included in the previous version and when we eventually shipped the beta we found out that what we had was good enough to start gaining customers and start providing us with key quantitative insights.

As we built things we made sure to take time to build very detailed tracking of user behaviour and we have analytics guru Irina Mugford to thank for driving that. The idea being to better understand what users were using, combining that with qualitative data we were gaining from customer support and user testing we began to get a picture of what people used and wanted from a product like ours.

Support - You Need it! (Be Fanatical)

Often support is perceived as a thankless task, but it can be extremely rewarding. Knowing that people are using something we made makes me very happy and if they are having issues with it, I want to know!

At Trint we tried to have everyone involved in support to some degree - it’s a delicate balance obviously, as you want to make sure that developers are not detrimentally distracted by it, but at the same time it’s a fantastic opportunity for all in the company to better understand the product. We were extremely fortunate to have Euan Ramsay as Support Manager. Crucially, Euan knew just when to escalate a support issue to the wider team.

Scaling support is always going to be a challenge - knowledge bases, process and procedure all need to be established so that you can distribute that function - always difficult when you are flat-out concentrated on dealing with tickets. My suggestions were to create a series of flowcharts with links that led to more detailed information or process. Often the same process will be required in many situations and in order to avoid duplication, it makes sense to have all those procedures in one place but loosely referenced. Google Drawings allow links to other Google documents and may well be a good way of linking known issues with solutions.

Something-Driven-Development

It’s worth mentioning that formal unit testing did not really become a thing until after we’d shipped the beta. We certainly were not doing Test Driven Development (TDD). I know a lot of people that strongly advocate writing the tests before you write any code and I think that strategy can pay dividends, it’s just that we felt that we didn’t have the time to do that from the start, it was more an aspiration - an ideal we wanted to move towards. Maybe that’s a false economy. One thing is for sure, it was certainly on my radar to have better automated tests and we eventually got there - we just weren’t “test driven” from the start.

Something that evolved as part of Piotr’s initiative and experience was a type of Styleguide Driven Development - the broad principle was to create elements of the UI in a style-guide before using them within the application itself. This gave us a sandbox to try out interactions, provided a solid point of reference for developers and ensured we didn’t create the same thing twice (it’s amazing how all those components add up)!

Feature Flag Driven Development is my favourite DD. Pretty much what it sounds like, it involved implementing features behind flags, which users or admin (depending) could turn on or off. FFDD had several advantages - we could:

• Test features with a subset of users
• Easily demo new features and dogfood* them ourselves
• Cleanly separate UI design from UI implementation
• Quickly make certain features part of a specific payment plan

_{*From "eating your own dogfood" the process of actually using your own product!}

Our style-guide was based on the excellent open source Catalog from Interactive Things

Recruiting

I’m new to recruiting but have read a fair amount about the process. I knew the age-old adages (hire slowly and fire quickly), but I didn’t necessarily subscribe to them.

I firmly believe that a diverse team is a better team and did my best to hire for diversity, I don’t believe in developer tests at interviews, conversely I don’t think you can put that much store in people’s GitHub accounts.

I also believe we were lucky enough to make some very good hires in Norman Khine and Alberto Centelles - our London-based developers.

All of that said, I think there was room for improvement in the process, it was all a little loose. I think that’s something I’d get together with Human Resources to sort out as a priority. Assuming you had Human Resources resource. There are laws around interviewing and compensation and it’s definitely something worth taking seriously.

Default to Open

I may have mentioned Slack a couple of times in this post. I like Slack, but deeper than that I like the medium of text chat. Prior to Slack I was a big fan of IRC.

For me Slack has a couple of advantages over email, video calls and even face to face communication. All of these forms have their place, but chat is special because it facilitates both synchronous and asynchronous modes of conversation, that is to say you can choose whether to communicate in real-time or not. Of course you’ve also got a reference for all those conversations you had in the past. If you have several years of discussions it’s super interesting to see what you were talking about all those months ago!

We used Slack extensively partly because we were a dispersed team and my personal mission was to get people to have conversations in public, even if you were sitting next to the person and in the same office. I realise the second caveat of that mission is a big ask, it means fundamentally changing the way you communicate.

Perhaps the only good thing about an open plan office is that you get to overhear other people’s conversations and see people interact - this can be extremely valuable in giving people a more holistic perspective of what’s going on in a company. If you’re a partly dispersed group you need to act as if you’re all dispersed, otherwise you risk the unravelling of the benefits of a tightly communicative company.

I pushed the idea that there could never be too much information - with Slack and other similar chat applications you can mute channels entirely or have them alert you only when you are directly mentioned. I really don’t see any reason to leave a channel, if it’s a “social” channel such as (say) #music or #random, it’s useful to be able to dip in to get an idea of the non-work aspects of your team. This is especially crucial in a dispersed team where there is no actual shared water-cooler!

It’s also nice to give back to the open source world and not be too paranoid about revealing your technology (it’s the people that make your company special). When you use so much open source technology it makes sense from both a cultural and business perspective to give something back to the community. Developers are generally happier because they can blog or talk about their work, sometimes at conferences and by releasing elements of your code as open source you can also get the wider community to contribute both code and ideas - it’s also great marketing!

So What’s Next?

Well I’ll always be co-founder of Trint, that’s not going to change. Being a CTO of a company from conception through to revenue has been amazing experience and one I’m grateful for. I plan to keep in close touch with the team and that’s working out well, but really I just want to go back to my roots and work on projects that embrace open source - both the consumption and production thereof.

I don’t mind being on site occasionally, but I really love working remotely. I’m also becoming more involved in the local development community here in Italy.

Needless to say if you are looking for a web-media-technologist with project/product management skills, please ping me. I’m available for consultancy, contracts, full and part-time gigs, but predominantly remote.