When growing any product or service, it’s to constantly gather feedback from your user base. And I mean constantly, else you risk losing focus from your real clients’ needs and priorities.
To drive this point home, I figured that the best course of action was to collect some valuable insight from a third-party. Joseph Harris, who works at Eucalyptus was kind enough to take the time and offer just that.
Note: some of the content below is paraphrased.
I’ve already mentioned that Joseph represents Eucalyptus, a fairly-young company that started in 2018. While the company itself hasn’t even turned three years of age, it’s definitely going places. At the time of writing, they’re growing at a blistering impressive pace which would make most other companies envious.
I’ll start with the juicy bits first. They’re a Telehealth platform that builds brands on top of their shared tech stack. This drives costs down and makes reusing the same engineering work across different spaces possible. Their success has also garnered the support of the largest VC firms in Australia and a total of 4 brands under their belt, as well as a customer pool of over 100.000 clients.
It would be a safe bet to say that learning from their experience might give a good return on investment for whoever wants to listen.
When Joseph joined Eucalyptus, they started and got by with just one engineering team of 5 people. He got the chance to see the company grow right from the beginning, which makes his point of view incredibly relevant for this discussion.
Even then, experimenting with a great deal of things and practices was a part of their company backbone, which I can only applaud, playing around with productivity-enhancing things and methodologies like “business-metric-focused iterative engineering work” (If you’re just starting in IT, this might sound like a mouthful, but never be intimidated by technical jargon like this!).
In fact, you’re already probably working under such an organizational structure without even realizing it, especially if your team uses Agile and "Sprints" as a form of team workload / time coordination for your project.
When asked about the technical side of things, Joseph broke it down beautifully.
Their engineers are split into 3 primary teams:
- The first one is the "growth engineering team". They’re focused on carefully studying various usage metrics and aligning the product(s) with the market requirements, which is just fancy-talk for always looking ahead to what your clients might need in the near and mid future in order to pinpoint and adapt to market changes quickly and efficiently.
- The other 2 are platform engineering teams that do the actual implementing.
One of the strengths of Eucalyptus, according to Joseph, is that they totally embraced feature flags.
For the uninitiated, a feature flag is the development software process used to enable or disable certain functionalities without actually pushing new code to production (the live instance of your app or website that casual people can access).
Sounds simple, right? That’s because it is. But it’s also genius and falls under the KISS coding principle (an acronym for "keep it simple, stupid").
Embracing feature flags allows you to have much more flexibility and improved response times for a whole plethora of different situations without much risk of falling down the rabbit hole of over-engineering solutions. Which definitely gives Eucalyptus an edge in the marketplace over other companies.
Joseph goes on to say that they use Feature Flags for 3 main reasons:
- Experimentation, of course! A/B testing is one of the most tried-and-proven methods to see if your changes are well-received by your client base. They combine this with analytics taken through Segment to Redshift to analyze results. This is an outstandingly good way to make sense of large amounts of tracking data so that you determine changes in-platform after pushing new code.
- Progressive rollouts, which they mainly use for releasing high impact / high-risk changes to different chunks of their user base at a time. In this way, they mitigate damage in case bugs or various other issues creep their way onto production. If everything goes well, then they propagate the changes to everyone else.
- Kill switches for various things. Kill switches are immensely useful to quickly turn off a feature that might be behaving badly. They use kill switches in conjunction with the progressive rollout for maximum deployment control, as you can easily disable a new feature with the flip of a switch (pun intended!) if the new code doesn’t behave as you’d expect.
One of the main benefits of using ConfigCat’s feature flag service, Joseph continues, was the automatic flag caching, which drastically decreases the number of requests and recaching done on frequently visited pages.
“The frontends are built with React and Vue, and ConfigCat has been providing all the necessary tools to implement feature flags in the frontends of the applications.” - Joseph
What’s interesting, Joseph adds, is that:
“We have now had multiple instances where conversion rates have dropped for something, and it was soon after we released a change, but because we had a FF in there with ConfigCat we were able to see that both the control and variation experiences were dropping, so it was driven by a macro change and not the fault of the code we rolled out. In fact, that code had a relative improvement of 30%, that we would have reverted without the FF and data that it allowed us to collect”.
What this means is that their first instinct (and everybody else’s in that situation, for that matter), was to wrongfully correlate the recent changes with the drop in conversion rates, which would’ve been a step back for the company and its operations. This implies that they would have thrown away good code along with precious development time, as well as any potential rewards that would’ve resulted from it.
If this article peaked your interest, feel free to:
- Check out more about Eucalyptus by following this link.
- Learn more about Feature Flags and the services that ConfigCat offers by clicking here.
- Feel free to check ConfigCat’s other blog posts for more heart-to-heart coverage!
- For the more tech-savvy among you, you might enjoy checking out the ConfigCat Docs for a more technical take on things.