Projects

Proactive Customer Communications

• Problem: Most Software As A Service (SaaS) businesses operate in a reactive position, with customers creating cases and a support team responding to those. Occasionally however, as part of a SaaS offering, there are situations where the company needs to proactively reach out to customers. Examples include to inform them of an issue affecting their usage of the service or to request actions of them to avoid directly manipulating their private data.
• Solution: I developed a process for our customer facing teams to follow that allows for drafting of and sending a communications package for such events. This included getting appropriate stakeholder input and approval on the communications content and usage of a standard medium for sending. Process catered for 24×7 message deliverability in response to any event, with appropriate approvals and actions built in.
• Results: Aiven can now inform customers proactively as appropriate in reaction to certain events, providing a richer, more informed customer experience.

Cross Team Reporting Analysis

• Problem: As a company focused around our own products, we needed a quantitative way to track the internal escalations and cross‑team requests. A key path (for our SaaS offering) was that of bugs reported to engineering per product.
• Solution: I guided a project team in developing monthly reports that are delivered organisation‑wide and covering details of escalation rates, issues reported, and cases raised, broken down by segment, product, and solution. These reports provided a way to score and propose top‑asks: the key requests that we believed would reduce escalation rates and improve the product for both internal and external users. These top‑asks could, in turn, be tracked through reduced counts in the next month’s reports.
• Results: The company is now generating a monthly report containing metrics to track a crucial aspect of a critical internal workflow and our team was now part of a full‑circle feedback cycle in the development and furthering of Elastic products.

Individual Contributor Dashboard

• Problem: As a management team, we needed a way to check how somebody is going and where they are investing their time. In particular, something that could be referred to during 1:1 meetings, reviews and as a regular check.
• Solution: I built a dashboard in SiSense analytics service that shows the contributions on a per‑engineer basis (either individually or in any group), that could be filtered by various metrics.
• Results: Our management team now had a tool to get quantitative measurements of an individuals work to help with understanding how they are utilising their time and what they are working on.

High Severity Case Handover Process

• Problem: With high severity support cases requiring a 24×7 response, there is often a need to hand over a support case between different Support team members around the world, as they enter/exit their working hours. When these handovers occur, there is a change that information can be lost, resulting in the customer having to start from scratch with their issue, repeating information already provided to Support and redoing troubleshooting steps that were already done. This is potentially a waste of time and frustrating to the customer, delaying reaching a resolution to their issue.
• Solution: A process was required to ensure that relevant information was preserved at hand over points to ensure a continuous engagement towards an issue resolution. I gathered details from the Support Management team what was the expected handling of cases running 24×7. I conducted research on other industries and existing practices where shift-workers operated in critical situations that required hand-overs between staff.
• Results: I developed a warm hand-over procedure for cases requiring 24×7 handling to ensure no gap in support, clear case ownership transfer, continuity of care with no interruption from the customer’s standpoint. The procedure ensured everyone involved had clear expectations and had the information they needed to help. The process design elicited an exchange of information, responsibility, and actions. It included using an acrostic to help define the details of the procedure and for memorable and cherished use in the team.

Customer Data Handling Policy

• Problem: Companies are generally bounded by legal frameworks around the world like GDPR and business security certifications such as SOC1/2, which dictate strict data handling rules that must be abided by. These rules need to be interpreted, and a policy defined that teams could follow to ensure they correctly handle customer data by these various rules and regulations.
• Solution: I worked closely with the Infosec and Legal teams to create documentation for teams on these policies. This documentation helped explain in clear words and within the context of the team’s work what we must do to appropriately handle any customer data in their duties.
• Results: Elastic now has a clear policy, approved by Infosec and Legal, that has been adopted by all engineering teams who handle customer data.

Standard Quarterly Conversation Template

• Problem: As a management team, we wanted collectively to ensure that the feedback process for engineers was fair and common across different regions.
• Solution: I gathered the existing feedback templates in use by managers and the standard template provided by Human Resources; estab‑ lished the commonality across all of these (through mind‑mapping), and developed a template for quarterly feedback that incorporated familiar concepts from each. The template provided a way to present actionable ideas for the recipient by using quantifiable metrics. Pri‑ marily, goal setting focused on small, discrete objectives and metrics built on pre‑defined reports that gave a view into casework, customer feedback and contributions within the company. The reporting and visualisation are built on top of our products.
• Results: Our team had a modular, standard template for use in quarterly conversations that met company criteria for feedback and pro‑ vided straightforward, actionable advice for engineers clearly, consistently and fairly.

Internal Escalation Path

• Problem: Customers with a SaaS subscription typically contact Support through the published channels as a first step in getting help. However, they may reach out to other teams within the organisation (such as their Sales Representative, Customer Success Manager or Solutions Architect) when they feel the engagement with Support has gone awry or is otherwise not working out. These other teams therefore need a pathway to escalate these asks back to support to be investigated and any steps necessary to course-correct, done.
• Solution: I engaged with representatives of these other teams to understand their interactions with customers. Through these discussions, I created an escalation path to Support for other teams, that provided tracking of the request and a commitment to an initial response timing, as well as tracking usage of the escalation path for future analysis.
• Results: Other teams had confidence that escalations would be addressed appropriately by Support and reduced risk of customer dissatisfaction from a bad support experience that wasn’t addressed.

Case Translation Tool

• Problem: Support had contractual language obligations to customers in certain countries, and we required a way to translate between languages that also met our legal and security requirements for customer content provided in cases.
• Solution: I researched and selected a vendor who provided a product that met our requirements for translations. I worked with Elastic legal and security teams to review the vendor’s product to ensure it met our legal and security requirements. I then engaged with our internal CRM developer team to integrate the product into our internal support portal.
• Results: Elastic now has an approved tool for translating cases between different languages.

Onboarding Documentation

• Problem: Our team had grown to a point where we could no longer rely on individuals mentoring the new starters in an ad-hoc fashion. We needed an established on-boarding program.
• Solution: I created an “I am Elastic Support” page which became the one-stop place to go for new and old engineers to reference our policy and procedures. It inspired work that later became a series of pages that defined a six-week ramp period for new engineers, which then became the foundation of a more formal onboarding experience that is currently in place.
• Results: Support now has a formal on-boarding process with detailed documentation to guide new starters. Mentor and mentee now have a clear and guided path to on-boarding.

go-hass-agent: A Linux agent for Home Assistant

A Home Assistant, native app for desktop/laptop devices. Written in Go. Gathers and reports many measurements from a desktop/laptop as sensors in Home Assistant. Can be used to:

• Change lighting depending on what active/running apps are on your laptop/desktop. For example, you could set your lights dim or activate a scene when you are gaming.
• With your laptop plugged into a smart plug, turn the smart plug on/off based on the battery charge to force a full charge/discharge cycle of the battery. This can extend its life over leaving it constantly charged.
• Like on mobile devices, create automations based on the location of your laptop running this app.
• Receive notifications from Home Assistant on your desktop/laptop.

autocorrector: Spelling autocorrector for Linux desktops

In a moment of self-realisation, I one day realised I made many mistakes in typing. On most mobiles, a lot of these mistakes are autocorrected for you. On Linux, my daily desktop driver, there was no such capability. To fill this gap and get a similar experience to mobile devices, I created autocorrector, which listens to the key presses, interprets when a word is typed and checks and corrects it for you automatically if it is a typo.

Autocorrector makes use of an underlying library I wrote to interface with the Linux event subsystem (specifically with keyboards). Initially, I wanted to understand how what you type on the keyboards ends up as a character on your screen, so I wrote a library to listen for keyboard input and interpret the actual key press, utilising the de-facto kernel interface for this, libevdev.

Pingbeat: For tracking ping times

pingbeat sends ICMP pings to a list of targets and stores the round trip time (RTT) in Elasticsearch (or elsewhere). Written in Go, it uses elastic/beats/libbeat to talk to Elasticsearch and other outputs.