Encircle

Website

www.getencircle.com

SUMMARY

A collaborative web (React) and mobile solution for restoration contractors to document their insurance work.

EXPERIENCE

I had been working for Boom Digital Media building a Facebook game using Angular2, TypeScript, and Node.js. I learned a fair amount about modern web development by the time I finished, and an opportunity came knocking from some old friends who worked in the Velocity Garage at Communitech with me while I was working on Lumos Analytics. I knew they were brilliant people that I could learn a lot from, and since I was already doing web development, and not really game development, I decided to take the leap doing a software development job outside the game industry for the first time in my career and joined the team at Encircle in 2018.

Encircle is a field documentation tool used by restoration contractors to document their mitigation and rebuild work in a policyholder's home. It allows users to capture photos, videos, and notes while they do their work. They can also generate reports containing the documentation they've captured, which they can send to the policyholder or the insurance company. The goal of Encircle is to reduce the lifecycle of insurance claims and help restorers get paid.

As a Software Developer

One of the reasons I joined Encircle was to become a better developer, and that did not disappoint. At Ganz when I coded Frocket as the sole developer, I was not in the development department (I was in design), so I was told their devs would review my code. That never happened. At Boom when I coded GemQuest as the sole developer, I was also told there would be code reviews. It never happened. While the freedom to code fast was nice, the learning opportunities were minimal and there wasn't a way to really confirm I was using best practices. At Encircle every single code commit is reviewed by multiple developers, no matter who you are or what you are working on. Even if some emergency code is deployed, it still gets audited after the fact. This review process has educated me in so many ways; best practices, philosiphies, new tricks, and of course logic improvements. While at first this collaborative coding style can be intimidating or embarassing, once you drop your ego and embrace healthy discussion, it becomes an invaluable process.

In addition to code reviews, Encircle also has automated unit tests and enforces a fairly strict linter on all of their code. This catches many simple mistakes, alleviating code reviewers, and also greatly helps promote a common coding style. So no matter which area of code you're working on, it will typically look like it was written the same way, even though several programmers may have touched it over the years. In the game industry I had come to accept that people write code differently and you just need to move along and "get shit done". This was a breath of fresh air.

I started off developing features for Encircle's web platform, which introduced me to React, an alternative framework to Angular2 which I had previously been using. React was much simpler to learn than Angular since it didn't involve special syntax to use common concepts like loops. The way it allows you to segregate your HTML and JavaScript/TypeScript logic is more elegant in my opinion. I was a full-stack developer, so I was also coding any necessary server, database, and permission code that accompanied the client-side features I was building.

I was eventually moved to native mobile development for Android, at the time coding in Java. This was my first real experience developing native mobile code since Unity had done all the heavy lifting for me in the past. I was quite impressed with Android Studio as an IDE, as well as the state of Java compared to when I first used it back in my earliest computer science classes.

A significant portion of my time as a developer at Encircle was spent creating new endpoints for the Public API. I have developed a few APIs in the past, but this was my introduction to Swagger and OpenAPI, which I've grown quite fond of. As of writing this, Encircle doesn't have a guide to walk integrators through our API, but the technical documentation alone does a good enough job to get most integrators through it. Encircle didn't have any technical product managers at this time, so I was often assisting the product management team with any discussions and questions from integrators.

As a Technical Product Manager

In early 2021 I made a lateral shift in the company to join the product team as their first Technical Product Manager. In this role I am responsible for managing and prioritizing the development roadmap for internal tools such as Encircle's custom form builder, the public API, and integrations we build into our own product. It isn't so different from being a game designer; I write feature briefs that are referenced by the design and development teams during implementation. I join scrums to ensure the feature is being implemented properly and to answer any questions that arise during development. I work with a project manager to define and prioritize tasks. And I work with our product marketing team to ensure they're aware of our release schedule and to help plan how the feature will be delivered to customers (ie. beta, feature flag, etc). I still act as a code reviewer for the development team and I occasionally commit small code changes (usually for my own gain).

My first order of business as a product manager was reviewing the public API, where I noted gaps that prevented certain data from being useful to integrators. We spent some time closing these gaps, improving support for webhooks, and then reaching out to existing integrators to help them take advantage of the new additions. Thanks to these improvements I was able to build a Zapier app for Encircle, which is a huge win for smaller customers who want automated workflows but have no technical personell. I also expanded our analytics and logging abilities for the API, which has been helpful in understanding how integrators are using the API. I have ongoing initiatives to expand the API and continue to build relationships with integrators.

Much of my time as a product manager has been dedicated to researching and planning larger integrations that we build into our own product. Customers understand we live in a connected world where open ecosystems can relieve many pain points they face regularly. Reducing duplicate data entry and increasing data accuracy might seem like a small win, but it's been a very fulfulling experience seeing customer reactions when automations start running for them, or when they no longer need to switch between apps to get data to and from their tools.

Overall I've quite enjoyed the shift away from programming and instead spending time understanding our customers and how we can serve them better. I still encounter many interesting problems to solve, but it's on "paper" instead of code, and I get the satisfaction of experiencing customer delight when we release features.