Interviewees: Satoru Hanada, Manager, Development Section, Development Department, and Tomoya Oshima, SIC Team, matsuri technologies, Inc.
Key takeaways
- Cut response lead time to 1/7 in two months (6.0 days → 0.8 days)
- The key was a decision to "record first, automate later"
- Three factors behind the success: backing from the product owner, a one-team culture, and the sense of urgency created by a key person's transfer
- Improvements: Notion-centered knowledge management × an AI stack built around the Datadog MCP
- The lesson: unglamorous first steps are what drive major organizational change
In this series, "Building Strong Engineering Organizations: Lessons from Resilient Companies," we feature companies taking a pioneering approach to the common challenges of incident response, such as knowledge siloed in individuals and detection that depends on manual effort. Our goal is to share reproducible, practical insights with readers who are taking on transformation, through the logic behind key decisions and the reality of organizational change.
Our first installment features matsuri technologies, Inc., which develops and operates a lean-staffed lodging and short-term rental platform. Built around its m2m series, the technology company supports both its own lodging business and external customer acquisition platforms (such as Sumyca and Ichijikikoku.com), and has kept growing its business for nine years.
Its engineering organization cut the lead time for handling inquiries from 6.0 days to 0.8 days, roughly 1/7, in just two months.
The key wasn't the latest AI tools or a newly formed dedicated SRE team. It was a fundamental decision: "record first, automate later." Based on interviews with Hanada, who leads development at matsuri technologies, and Oshima, who leads the SIC team, this article traces the logic behind that decision and how the organization changed.
From individual expertise to organizational systems: matsuri technologies on the eve of change
Before getting into the success story, let's first look at the nature of matsuri technologies' business and the challenges it faced.
Its suite of products, which has been running for nine years, integrates asynchronously with OTAs such as Airbnb. Because the business is run with minimal staff, a system malfunction is never just a bug: it can mean "a guest can't get into their room tonight." A single malfunction directly affects service delivery and customer satisfaction, which brings real weight and tension. On top of that, matsuri technologies' products are used every day not only by external customers but also by its own business divisions. It's a unique structure in which engineers' users span both outside and inside the company.
Given this business context, the engineering organization faced two major challenges.
Challenge 1: Knowledge siloed in individuals
matsuri technologies' development structure originally started with a "one person, one product" ownership model. "As the business grew, we realized that if things stayed this way, nobody could ever take time off, and it just wasn't sustainable. That's how we gradually moved to a team structure," says Hanada, who leads the TS team.
After the shift to teams, knowledge and documentation steadily improved, but not to a level that could be called sufficient. The reason they could still handle things without major trouble was the high skill level of individual engineers.
"In practice, there were quite a few cases on the ground where, especially for older systems, you couldn't figure things out without checking with a specific team member," notes Oshima, who leads the SIC team.
Knowledge silos affect an organization's stability. At a company like matsuri technologies, where service and technology are tightly intertwined, the impact is immeasurable.
Challenge 2: Detection that depended on people
The other structural challenge was that detection depended on people. As mentioned, the product developers and the business divisions that use the products are in the same company, and the first report of an outage often came from a business division via Slack. That proximity enables a fast initial response, but the flip side was a vulnerability: "If the business division doesn't notice, we can't detect it."
"Maybe there are outages happening somewhere that we on the development team haven't noticed." (Hanada)
Hanada says that this kind of anxiety constantly hung over the team.
The turning point came when Hanada, a key person, was transferred to another team. The realization that "the business won't keep running like this" created a strong sense of ownership across the entire organization.
Three factors that drove the transformation
Faced with challenges like matsuri technologies', many organizations try to start with "AI-driven automation." But matsuri technologies chose the opposite: going back to basics and "putting a system for recording in place."
Oshima, who joined the company in 2026, had a simple motivation.
"When an inquiry came in, it often started with 'What is this?' We couldn't figure out how to handle it without checking with the previous owner or a key person. I felt that was a problem, so the starting point was, 'At the very least, let's properly record what we did!'" (Oshima)
Starting from that idea, the effort began with collecting information in a set format.
That "natural choice" was also supported by the company's culture. Whether in the physical office or the virtual one, there had long been a "one table" culture of gathering immediately when someone was stuck. This time, they applied it to incident response as well.
Organizational backing was another key element in making an unprecedented initiative stick. The product owner's stance mattered most.
Normally, business pressure pushes product owners to say, "Everyone, keep moving your own work forward in parallel." But that's not what happened at matsuri technologies.
"Our product owner told us that when it came to investigating and responding to outages, it was fine if one person ended up just observing. For the hard ones, they really wanted the whole team to tackle them together. Some product owners would still ask everyone to keep their own tasks moving, so I think this was a huge boost for us." (Oshima)
This is what's known as swarming: the whole team working together on the highest-priority task.
Organizational backing from the product owner, a one-team company culture, and the sense of urgency created by a key person's transfer. These three factors came together, turning the unglamorous effort of "starting with recording" into a major movement that changed the team and the organization.
Building an operational foundation that solves the problem: knowledge management and the AI stack
To address these challenges, the team pursued two broad lines of work: managing knowledge and documentation, and AI tools and automation.
Notion-centered knowledge management and operations
Investigation results that had previously been scattered across Slack, Google Docs, Notion, and elsewhere were consolidated into a single database. "The first thing we did was create a state where, for any given issue, you knew you could look at this page to find the investigation results," Oshima explains. Every inquiry was logged in Notion, with the summary, actions taken, and investigation history managed in one place.
The measures to make it stick were concrete, too. They used Notion's template feature to prepare a standard format, prompting people to fill in required fields and keeping the format consistent, so the accumulated data took on a standardized shape. For collecting inquiry information, some teams adopted autonomous AI agents such as Claude Cowork early on, and have reached the point where "collecting inquiries from Slack and storing them in Notion is automated. No human is involved."
The underlying design philosophy is: "When the same inquiry comes in, we want to be able to refer to past cases and respond right away." Oshima adds, "Eventually, it would be great if AI could use this information to handle things on its own."
The AI and automation stack
What changed outage detection, which had relied on inquiries from the business divisions, was an AI pipeline for outage detection and response.
matsuri technologies had already been using the monitoring tool Datadog, the autonomous AI agent Devin, and the AI coding assistants Claude Code and Codex individually. The arrival of the Datadog MCP made it possible to integrate them and use them as an outage detection pipeline.
The Datadog MCP is a bridge that passes logs and error information in Datadog to AI and other tools. Here's how the AI pipeline built on it works.
First, Devin, an autonomous AI agent, automatically checks Datadog error logs on a regular schedule. When it detects an anomaly, it can automatically file an issue in GitHub (where development tasks are recorded). By also building a mechanism that returns AI-generated fix proposals, the team assembled an end-to-end pipeline that goes from detection to a proposed fix without human intervention.
That said, automated detection hasn't yet been rolled out to all products, and the team appears to be continuing to experiment ahead of a full rollout.
For investigations when incidents occur, the team uses Claude Code and Codex, and is moving toward speeding up root-cause narrowing by passing logs and APM data directly to AI via the Datadog MCP.
Ideas for these practices reportedly emerge naturally from a "consultation session" held every day at 3 p.m. There's a system for sharing recently tried tools and lessons learned, so the cycle of bringing new tools into daily work runs as a matter of routine.
Lead time from 6.0 days to 0.8 days: what disappeared was the "wait time" before work began
The median lead time for handling inquiries (from ticket creation to completion) was 6.0 days in February 2026, right after the team introduced task tracking and swarming. By March it had dropped to 1.0 day, and by April to 0.8 days. That's a dramatic improvement to roughly 1/7 in just two months.
Hanada analyzes the mechanism behind the numbers as follows.
"Before, things would stretch out, with a mindset of 'Let's just file the ticket for now and get to it later.' Now the thinking is, 'A ticket's been filed, so let's get it done.' I think that's the big change." (Hanada)
When Hanada went back through past data on handling time (from start to completion), he made the following discovery.
"Actually, the handling time from start to completion hasn't changed much, in either the mean or the median, before and after. What characterized the past was a wide spread in handling time, and this improvement eliminated that variance. We no longer have tasks piling up because it's unclear who's responsible, and work now moves forward at a steady rhythm." (Hanada)
The median handling time itself was about one day, both before and now. In other words, it wasn't that technical processing speed changed dramatically; it was the wait time between ticket creation and the start of work that improved.
And another push from the product owner was key to the dramatic jump in March.
"The product owner suggested, 'When an inquiry comes in, start on it and think it through, even if it's just for a short time like 30 minutes.' If you can solve it, great; if not, ask someone who knows. I think that message of not taking too much on yourself led to the big change in March." (Oshima)
The diligent ticket logging in February made the types and trends of inquiries visible, and the "30-minute suggestion" built on top of that.
The shift in mindset Hanada describes, "A ticket's been filed, so let's get it done," doesn't seem to have emerged on its own.
- Every inquiry became visible as a task in Notion
- The swarming culture let the team mobilize instantly
- The product owner's 30-minute suggestion lowered the barrier to starting a task
Only when these came together did a culture of immediate response, from ticket creation straight to action, begin to take shape.
Oshima notes that a sense of psychological safety, that "you don't have to carry it alone," has taken root, and new members can now join in on responses early. Being able to refer to past cases stored in Notion is accelerating how quickly new hires become productive, and the qualitative changes have been significant as well.
Three next steps: rolling it out further and deepening external partnerships
matsuri technologies cut its response lead time to 1/7 in two months, but its sights are already set on the next stage.
The first is rolling the transformation out to other teams.
This initiative was piloted by the SIC team (property and customer acquisition), and the plan is to extend it to the TS team (cleaning and check-in), which works mainly asynchronously. Adapting the approach to account for the differences between teams will be the next challenge.
The second is establishing criteria for severity assessment.
Because the team works so closely with the business divisions, it needs a careful approach that respects the characteristics and diversity of each product, rather than creating a one-size-fits-all standard. Hanada commented as follows.
"We don't have a consistent way of evaluating along both axes, severity and impact. With products at different stages of their lifecycles, should we force a common standard, or is there common ground? I think some of that will gradually become clear as we develop and grow the business." (Hanada)
In other words, Hanada sees the right criteria not as something designed on paper, but as something that will emerge naturally from day-to-day practice and the growth of the business.
The third is deepening integration with external services.
Integrations with external services such as OTAs are an area the company can't fully control, but matsuri technologies doesn't see that as a "problem."
"Rather than dismissing outages in external services as someone else's problem, we think it's important to take the stance of helping each other improve. If we share issues we've noticed with the other party, knowledge builds up on their side too, and joint automated detection moves forward. Instead of pushing the blame for outages onto others, we need a stance that encourages the maturity of the industry as a whole." (Hanada)
SIGQ insight: lessons from this case on building systems for recording and automation
What the matsuri technologies case reveals is a universal structure: only by first putting a "system for recording" in place can you actually measure the effect of automation.
In a survey SIGQ conducted of 250 VPoEs, EMs, and SRE leaders, 32.4% of organizations that had undertaken incident response reform said it "did not improve." With so many organizations getting started yet failing to see results, a case like matsuri technologies', which proceeded in the order of "record → automate," offers rich lessons for the entire industry.
The next areas of focus Hanada raised were:
- Teams don't share a common understanding of incident severity
- They want to automate the classification of error logs and severity assessment
These two points are challenges shared by many operating companies.
These two points are exactly what organizations like matsuri technologies, having built a foundation of "recording," face next. We at SIGQ designed Incident Lake out of the same concern.
Incident Lake, provided by SIGQ, uses AI trained on past response history to automatically assess severity and surface solutions from similar cases for ongoing incidents in real time. Combined with investigation history stored in tools like Notion, it's designed to automatically connect the "records" that matsuri technologies has built to "the next initial response."
To readers who share the same concerns: what matsuri technologies' journey teaches us is that transformation doesn't start with cutting-edge tools, but with the unglamorous first step of "recording things first." A single Notion template, adopting a swarming culture, a product owner's "30 minutes is fine" encouragement: these are all actions you can try in your own organization starting today. Your organization, too, has its own "first step."
Interview and writing: Takashi Kamoda, BtoB no Shokunin Inc.