Introduction

Hello, I'm Taiju from the product development team in Autify's engineering department. In this article, I'd like to share my thoughts on Autify's engineering culture in 2025 - what it looks like now, how it has evolved, and what issues have led us to where we are today. Please note that I am just one engineer working on the front lines and was not in a position to lead the transformation of our engineering culture. In writing this article, I interviewed our VP of Engineering, Thomas Santonja, who was one of the key people behind the change.

‍

The Early Days of Autify

Like many tech startups, Autify started with just a few engineers. In the beginning, we were completely focused on addressing the burning needs in front of us and building features like there's no tomorrow. At the time, we only had one product - Autify NoCode Web - and a single engineering team.

When Autify's second product and second team, NoCode Mobile, launched, I moved to that team as the second engineer. I've been involved with NoCode Mobile from the very beginning, and when I joined, the core structure had been almost entirely built by the first engineer alone, and the basic features were mostly complete.

We had two-week sprints, but instead of working as a team toward a single goal, each engineer specialized in a part of the product. Even for technical decisions, we typically wrote proposals individually and shared them asynchronously, which meant we rarely had synchronous meetings. For more than three years after launch, Autify's engineering culture was largely shaped by bottom-up trial and error.

The Issues That Surfaced After Three Years

A few years later, the number of engineers at Autify grew and we were regularly delivering new features and bug fixes. We had about 20 engineers at that time. However, we also had problems; there were early signs of silos forming.

No one knew the design intent or how certain systems worked

Let me share a real experience I had at Autify. In any organization, people eventually move on. One of our backend engineers, who had led a major infrastructure overhaul at NoCode Mobile, left Autify. Of course, there was a proper handover, and the engineer left a lot of documentation so the remaining engineers were able to continue running the system.

Several years went by. There was an AWS Lambda function that didn't look like it was being used, so we deleted it. This caused part of the system to stop working, so we quickly reverted the change. None of us knew the intent behind this Lambda function or how it worked. Only after deleting it did we realize it was a critical component. Unfortunately, the function wasn't mentioned in the documentation. Everything is code, so it's possible to understand it by analyzing it, but the fact that none of us understood a part of an active system was pretty scary.

In retrospect, the overhaul was quick and completed in a short period of time. On the other hand, there was not enough focus on information sharing and design reviews, and the work progressed rapidly based on the decisions of one or two engineers.

A Gap Between Expectations and Reality

Another problem was that the engineering department wasn't fully meeting stakeholder expectations. Promised features were often delayed, and even when they were released, they didn't always meet expected requirements. For example, an internal design change was delivered more than two quarters late and still wasn't fully functional.

Rebuilding the Engineering Culture

When our current VPoE, Thomas, joined Autify, he spent time interviewing all stakeholders to identify key issues. I also had a one-on-one meeting with him and shared the issues I noticed from a front-line engineer's perspective. Based on the findings, several areas were reformed from the top down, focusing on the implementation of Scrum. Now, I'll explain how these changes have shaped the engineering culture we have at Autify today.

Estimate, Sprint, and Demo

The biggest change, in my opinion, is that the engineering process is now defined across teams, and development follows that process. How the details are implemented is up to each team, but we all share the same overarching framework.

Feature development starts with defining and discussing large units called features (feature refinement). These are then broken down into user stories and ticketed. Before work begins on a ticket, the team must make estimates (ticket refinement), and the estimated user stories are placed in sprint plans. After each sprint, the value delivered to the customer is showcased to stakeholders in a demo session. This pipeline is the backbone of how we create value at Autify.

‍

‍

What's important is that the entire team, including product managers and engineering managers, have a discussion for each feature and user story. This always happens before the actual work starts. Sometimes stakeholders such as designers and support join the discussion. At this point, we identify as many uncertainties in our plan as possible, fill in missing details, and correct inaccuracies. Estimates are essential not only for planning but also for identifying oversights and misunderstandings among developers. For example, it's not uncommon for one developer to think a story will take 2 points, while another thinks it will take 5. Discussing how each developer came to these conclusions helps the team align and reduce ambiguity. Also, by setting a single goal per sprint and working toward delivering a demo, our team became more unified. Compared to when we used to work on our own assigned tasks, I feel we have a stronger team bond.

Since each feature now goes through discussion and consensus before implementation, important design decisions are no longer made in isolation -at least not within the same team. This new process helps us consistently meet our milestone goals for each sprint, which acts as a safeguard against delays.

As a side note, Autify engineers' compensation is not only based on product revenue, but also on how effectively the engineering team has delivered value to our customers - on time and with quality. Since revenue isn't something engineers can directly control, this ensures a fairer evaluation for engineers.

Architecture Decision Records

Another recommended practice at Autify is the use of Architecture Decision Records (ADR). This is a framework for gathering broad feedback on key architectural decisions. It outlines the problem, the background, possible solutions, and their pros and cons. Creating an ADR isn't mandatory for every feature, but for major decisions, we are encouraged to create an ADR and get input from many people. Autify has an Architecture Committee, and when you create an ADR and request a review, experienced engineers - including staff engineers - provide feedback on the design. In addition, ADRs are stored in a central company-wide database that all of us can access. All Autify engineers, not just the Architecture Committee, are encouraged to review ADRs from other teams and provide feedback based on their expertise. While it's often difficult to look beyond our own sprints, reading technical discussions from other teams is both interesting and educational.

Value Proposition

Along with the cultural shift, a term we hear more often at Autify is the value proposition. This refers to the potential business impact of a particular engineering effort. Whether it's refactoring or new development, every suggestion and discussion is ultimately judged through the lens of value proposition. This means that no matter what we do, we're expected to think about how much impact our work will have, preferably with a specific numerical value. This mindset felt restrictive at first, but now most of us have gotten used to applying it. During refinement, engineers can also ask the business side to explain the value of certain requirements.

This concept of value proposition has become the basis for prioritizing how we use our limited engineering resources.

Our Current Process

Finally, I'd like to show how everything I've explained so far fits into our overall development process. Below is a diagram used internally at Autify to illustrate our overall workflow.

‍

Step refers to the process from feature conception to completion. Artifacts are the deliverables produced at each step. RACI (Responsible, Accountable, Consulted, Informed) shows who's involved and what their role is. The green and blue areas indicate steps where engineers are involved. Not every step is always performed - it's up to each team how they apply the process - but this is the general company-wide flow. Technical discussions for ADRs typically occur between feature refinement and ticket refinement. Value proposition is the guiding concept throughout Autify's product development, and it applies not only to engineers but to the entire process - from ideation to ticket refinement.

Summary

• Undefined, bottom-up processes began to create silos.
• Delays in strategic feature delivery became common.
• A top-down framework was defined and implemented to address these issues and reduce silos.

Timeline

• March 2019: Autify NoCode Web closed beta launch
• September 2019: Autify NoCode Web official launch
• January 2021: Autify NoCode Mobile beta launch
• October 2021: Autify NoCode Mobile official launch
• September 2022: Thomas Santonja appointed VPoE
• November 2022: NoCode Mobile Sprint 1
• November 2022: First ADR created

Links

• How Autify Models the Future of Japanese Companies as Global Players - An interview with Thomas Santonja by TokyoDev

‍