About

In-house Experience

SIF Health (Technical Director, 3.5 years)

Role Highlights:

• The technical perspective on the board of directors.
• Designing, planning, and deploying the technical infrastructure of the company.
• Running Agile (using SCRUM) using strict practices as the lead developer. Negotiating with the product owner and business lead to determine the focus of the next sprint. Assuring (where possible) that the tech team meets the sprint commitment.
• Developing a fully functional booking and notes platform used by thousands of therapists.
• Setting up and being part of the various company events, such as the National Running Show, BodyFit Expo, RunFit Expo.
• Mentoring and coaching developers.
• Working with cyber-security experts to ensure we meet Cyber Essentials certification with the goal of reaching Cyber Essentials +.

The tech side and business side operated on the idea of "healthy tension" - if we are agreeing on everything then one side is redundant. The tech side operated as a voice of reason versus the wishes and ambitions of the business side and often became a "do we prioritise the stability of the system over the opportunity to reach another 2000 potential users this week".

Attending events such as the National Running Show was certainly out of my comfort zone - my role in such was purposely front-of-house, taking payments and bookings for people visiting the stall to get treatment from various practitioners who helped on the stall. The intention was that whilst being a technical director, it was important to ground myself in the everyday experiences of customers and therapists - by extension, our users could see and meet the people responsible for the platform.

Being on the board of directors was certainly a step up and formality above what I was expecting but was enjoyable and served as a fantastic big-picture review of where we are and where we intend to go. Technical discussion was uncommon, with feedback being because the tech side rarely required a discussion and the goals facing the board were mostly to do with business opportunity.

MMR and ARR was steady but slow, whilst churn-rate was exceptionally low (a good thing). Ultimately though, the industry we were servicing was severely impacted by Covid lockdowns which prevented our income for nearly 1 1/2 years. During more optimistic times, the growth was there, it was just too late. Statistically speaking, if Covid hadn't arrived, we would have had the revenue required to keep us afloat and growing.

Technical Highlights:

• Production, staging, beta ran on Kubernetes. I researched how to setup and run a cluster and how to diagnose and resolve ongoing issues.
• The dev environments ran on Docker, perhaps for obvious reasons.
• Builds and deployments were handled via a custom bash script on a simple instance. The server would poll the git repository for main, staging, and beta branches, would build the Docker image, and email us to let us know if it completes successfully or had issues. Intention was to move it to Google Cloud Build, but there were always more urgent priorities.
• Static code analysis, unit testing was handled during dev and was part of the process prior to code reviews each sprint.
• Migrated the project from Twig/JQuery/CSS to VueJS/Tailwind.
• Upgraded the project from Symfony 3 to 4.4 with minimal issues.*

*The importance of this point is to demonstrate that despite the fast-paced development lifecycle of a startup, and the fact the project was originally built by a web agency, we were able to prevent the codebase accumilating crippling tech debt. This upgrade required porting to a new codebase and strictly using Symfony 4's requirements, and identifying and removing legacy code which otherwise prevented the natural upgrade.

Kubernetes is overkill for what we needed though we had a generous amount of credit from Google and took the opportunity to learn the technology without financially impacting the company. There are times where the system would have gone down if it wasn't for Kubernetes - it auto-recovered from a number of minor blips due to the production environment horizontally scaling. There was the occasional time we needed to manually cordon and drain nodes to allow the cluster to spin up replacements but ultimately we were glad of the decision to go overkill in this case.