The Art of Adaptation
Given our inability to predict market conditions for the upcoming year, our ability to adapt swiftly becomes critical for survival.

Tactile has, for a long time, been defined as a developer of great story-driven, puzzle games. Whilst this held true for us for over a decade, and in particular since the launch of Lily’s Garden in 2019, we have in more recent years been observing big shifts in the casual mobile gaming market… which is becoming more and more hybrid-casual.

For us, this meant rethinking our strategy in terms of product. We wanted to challenge ourselves: first, to get better at launching games faster, and second, to shift our focus from story back to gameplay and to challenge ourselves with developing new core game mechanics.

This meant big changes for the business – both in terms of product focus and in terms of our workflows and processes. We have gotten really good at managing big productions, such as Lily’s Garden, which runs as a well oiled machine with weekly releases. Now we had to adjust to running smaller game productions with completely undefined processes.

As our culture is rooted in 3 core pillars – lean processes, agile workflows, and flat hierarchy – staying loyal to these has become more important than ever. Here’s why 👇

Our Culture Pillars

🔥Flat hierarchy – Our commitment as a lean company is to the work and the person, and not to the restrictions of a job title. It is hard for us to predict what we might need in a year’s time, so we instead commit to the people we work with and to growing their areas of expertise. We do so by enabling short decision paths and direct access to leadership, with high ownership at team level.

🔥Increasing outputs (agile workflows) – We want to get everyone as close as we can to giving max value. The only way to do that is for everyone to be aware of identifying processes that don’t make sense (the so-called ‘wastes’). We do so by fostering an open environment, where everyone is encouraged to share – ideas, observations, and most importantly, feedback – and that’s right at the heart of our culture. Specialists get to influence direction, not just implementation.

🔥 Identifying and removing non-value adding activities (lean processes) – We don’t want to spend time and resources that don’t add value to our production processes (and create ‘waste’). We make games, so a process doesn’t end when new content is delivered – it ends when it gets successfully released and our players get to experience it.

Let’s dive further into the 7 wastes* that our lean thinking aims to remove from our work processes.

The 7 Wastes of Lean

#1 TRANSPORT

💡One way to imagine transport waste is when tasks get reassigned and restarted from scratch, or when individual priorities get rearranged.

In the context of Tactile, this means finding ways to ensure everyone can successfully complete the tasks they are working on.

We want to make sure that tasks don’t get reshuffled or restarted too often and that, if someone starts something, they have the tools and support needed to finish it. Then we look into how we can better set each individual or task up for success in the future.

#2 INVENTORY

💡Inventory relates to the lean organization’s ability to avoid having many tasks in the backlog and setting too many priorities.

In our context, this means that if we start working on a feature, we need to be able to release it to the players. We want to avoid logistics and administration along the way, which ultimately does not add value for the player.

The point is that we don’t want great ideas and important tasks to sit in a backlog – we want them to see the light of day, because in a short time, they might no longer be relevant.

#3 MOTION

💡 Motion relates to finding ways to have everything that is needed to complete a task in one place.

As the lean organization was born in a factory (Toyota), motion waste originally referred to workers having to move around the factory a lot to be able to do the same thing over and over again (i.e., put tires on a car).

It turns out that in reality, multitasking doesn’t really work. At the same time, when tasks switch hands, it often takes focus away. At Tactile, we want to minimize motion waste by having people focus on one thing at a time and doing that really well (i.e., in QA we try to minimize testers switching between different games and features too often).

#4 WAITING

💡Waiting refers to having to get thumbs up to be able to continue with your work.

In our context, this means that we do not want to create feedback gates. Instead, we want to enable feedback loops. We do not have a middle management layer validating and controlling everyone’s work, which reduces many bottlenecks.

Leadership might set the direction, but the teams decide on how to get there. We expect Tactilers to pull feedback and not leadership to push it. We don’t always work with strict deadlines, so we have to make sure that an individual’s work is not blocked by anyone or anything else. If you experience delays and serious waiting times, we need to talk about it.

#5 OVER-PRODUCTION

💡We do not produce a large amount of in-game content in advance. For us, value is not achieved when content is created, but when our players actually get to experience it. So when a new feature or story day is done, it immediately gets released.

Having said that, throughout all of our production processes, we want to make data-driven decisions. This gives us a way to continuously check if what we’re doing still makes sense. Just because we can do something doesn’t mean we should.

Yes, producing a large amount of content ahead of time means that you can have a more relaxed production pipeline, but if the market suddenly changes, you have to make that content all over again. This then leads to over-production.

#6 OVER-PROCESSING

💡At Tactile, we try to reduce the number of processes and meetings that we have.

For some, sitting in meetings and solving problems has value, but that is not necessarily the case for everyone.

If we identify that we are doing something that doesn’t add value or doesn’t make sense (like sitting in meetings), then we shouldn’t be doing it. Or we should at least put it up for discussion, to see what can be done differently. We also don’t do internal communication via emails or reports. We want people to talk to each other in person as much as possible.

#7 DEFECTS

💡We do quality checks all the time and at every single step.

For example, our programmers focus on clean coding principles and practices. They also get paired up with QA testers from the very start of the development of a new feature. It is crucial for QA to be present already at the ideation phase, as it helps flag any potential issues early on and prevents us from repeating the same mistakes over and over again.

It’s not about fixing bugs, but about avoiding them. The quality of new releases should not only be tested at the very end of their development cycle.

Lean Management Practices

Besides reducing wasteful processes, we also follow these two lean management practices:

POKA YOKE (or mistake proofing)

💡Avoid unexpected surprises!

This concept comes from the idea that we should never blame the user for things that are not working properly. For us, this refers to fool-proofing our internal tools and tech.

Are the tools easy to use and to understand? Whoever is making them should also think about how users could get them wrong. This is why, within our teams, we encourage everyone to give constructive criticism and to speak up when they see that something can be improved.

GEMBA WALK (‘The Real Place’)

💡Go and see, check, and talk.

We solve problems and search for solutions by talking to each other. A lot.

This is not about micromanagement, but about having a discussion in the moment we identify something that doesn’t work. To stay lean and to keep moving fast, we need to be able to talk to each other in real time.

Reflection

One of the key reflections of one of the lean leaders at Toyota (the principles of Lean originate from the Toyota car factory in Japan) is that despite them realistically not being able to reduce all waste from their processes, this is not stopping them from setting ambitious goals (0 waste). As technology develops, so do processes and so does our understanding of how we can work better and more efficiently.

We’re not at the perfect place yet, and we might never get there, but we continue working hard on ensuring we’re staying true to the core pillars of our culture and how we wish to operate as a workplace. This is to give the best possible experience to both our Tactilers and to our community of players all over the world.

It’s Time for Talent – with Daniella Feiglin

Hi, my name is Daniella, it’s nice to virtually meet you! 👋

I joined Tactile in August 2025 as a Product Manager. I work with development teams and stakeholders to take concepts from a general idea to complete, live features. I also keep track of our data and market trends to help identify what we should focus on next.

🚀 Before Tactile

I’ve been in the mobile games industry for about a decade. I started as a Game Designer at a startup, then moved to a larger company where I worked as a Market Researcher before transitioning into Product Management. No formal degree – just a lot of learning on the job and a genuine passion for games.

💜 Joining Tactile

I relocated to Copenhagen and was surprised by how quickly I was able to feel connected – everyone is genuinely nice and welcoming. I get to work with talented teammates from many different countries, which has really broadened my understanding of the industry.

💪 Having an impact

My absolute favourite thing in my work is the feeling that something I did made a good impact (whether it’s game metrics, processes, or helping the team).

My time here has been very dynamic: I started on Lily’s Garden, then got a chance to work on a new game prototype, and just recently joined the Simon’s Cat Match team. A lot of that is because opportunities come up where I can be helpful, and at Tactile I get to influence where and what I work on. I’m also fully trusted with advanced product decisions – that level of autonomy is rare.

📚 The keys to success

• Make connections – networking got me my first opportunity in games.
• The skillset required of anyone in the industry today is rapidly leveling up. You have to stay current on AI workflows and the tools your peers are using.
• Play a lot of games, both your own and others, especially if your role is on the business side. To be a great PM in games, you need a deep understanding of both your own product and the market it lives in.

Written by:
Martina ‘Documentina’ Welander

Written by:
Martina ‘Documentina’ Welander

Tactile’s Technical Writer and the creator of Robotina

Like most games companies, Tactile is in possession of a 🐉Smaug-worthy treasure trove of documentation. These days, a lot of it is even in One Structured Wiki To Rule Them All rather than our CTO’s brain and that one post-it note from 2019.

A lot – hurrah for us! – but far from all. 

There is no stopping knowledge from establishing wild frontier communities in commit messages, ticket descriptions, chats, and scattered READMEs. And, no matter how fabulous or complete the documentation is, you still have to find it, and read it (eek!), and process it for your specific needs, and make sure that you’ve got the whole picture. 

It’s Big Brain Stuff, and you were already doing Big Brain Stuff today.

As the person who writes the documentation, I don’t blame my colleagues for just asking someone instead.

Well, what if that someone was a robot and you could chat to it in Slack?

Robotina – the little side project that grew

Robotina exists because I walked past someone’s desk at the exact moment they said “I wish [favorite AI platform] would let me search our wiki” (true story).

I opened VS Code, created a folder named `docindex`, and added some embedded wiki documents to a MeiliSearch index. The 📚Docstack was born, and 🤖Robotina appeared soon after – lo and behold, I had created a little baby RAG (Retrieval-Augmented Generation) pipeline before I knew what that meant.

Many months later, our robo colleague is doing a pretty decent job:

How it works

Robotina sends chat messages to her brain: the Docstack.

The Docstack is a custom app that (among other things) ingests, analyzes, chunks, embeds, and indexes content from sources such as our wiki, public chats, tickets, and even parts of codebases. The Dockstack data goblins (yes, really – life is too serious) do most of the heavy lifting to ensure that Robotina has access to a nice, clean, unified index of embedded content to search.

Ingest and chunk!

Each goblin is responsible for breaking a piece of content into smaller chunks. Ideally, a chunk should be able to stand alone – it should explain one concept or answer one question, such as “What is feature meta data?” or “Explain the A/B test group membership calculation”. 

Luckily, human beings also like structured, scannable content with meaningful subheadings. If humans liked your docs, you’re already ahead –  the robot will probably like it too.

Embed and index!

The magical math part of the Docstack (and of most RAG pipelines) is embedding vectors. We send each chunk of content to an embedding service (which is backed by a specialized embedding model), and it returns a long list of floating point numbers (the vector).

I like to think of vectors as a translation; this is your little chunk about feature configuration versioning written in the language of Math:

[
        -0.006929283495992422,
        -0.005336422007530928,
        -4.547132266452536e-05,
        -0.024047505110502243,
	  ...
]

See how they look like a list of coordinates? Visually, an embedding is like a ✨cluster of stars✨, and the index as the universe that contains them all. 

Each chunk and its associated embedding vector go into a search index, ready to be discovered. In this vast universe of content-as-math-as-stars, some star clusters overlap more than others (HINT: THIS IS FORESHADOWING!)

Magical math

What’s so cool about that? When Robotina executes a search, it uses that same embedding service to generate a vector of your question – a temporary cluster of stars. Then, rather than doing a plain text search, it looks for similar embeddings – clusters of stars that occupy the same space.

A piece of content about booking vacation overlaps a lot with phrases like ‘holiday’ or ‘time off’, or ‘PTO’ (Paid Time Off) – even if those words are not explicitly mentioned.

This is the cool part. 

‘PTO’ does not exist in our wiki; it is an American word (initialism, technically). BUT, a search powered by embedding vectors will still return the “How to book vacation” page as the first hit when you search for “how to book PTO”. The language model knows that PTO, holiday, and vacation occupy the same linguistic space, and the embedding vectors reflect that. Stars literally align.

Math, man. I hated it when I was 12, but now it’s kind of cool.

Summarize!

Finally, Robotina (powered by a prompt that has gone through months and months of refinement) summarizes the search results that it receives and presents you with an answer. Effortless. 💅

Oh, but there’s more!

Embedding vectors are not infallible – they are cool, but in a huge index, there will be overlaps that make sense in Math but not in Human, particularly if the content is a bit ‘flabby’ (not tightly focused) or multiple domains use the same words. Nonsense happens.

The Docstack does things to ensure that Robotina receives relevant results from her brain. Here is a lil’ snapshot of techniques, all of which are still being refined.

Clarify, boost, filter, classify, domain-match, oh my

A question like “how do I configure feature X” is a little vague – are you a developer asking how to configure the backend of feature X, or a dashboard user, or something else? 

• Compares the phrasing of your question to classify your intent – are you looking for  documentation (“How does…”, “Explain how…”) or are you looking for methodology (“How do we…”, “What is our process for…”)?
• Compares your question to an embedding of domain terms to see if your question matches backend or LiveOps or narrative content – did you say ‘endpoint’? Request body? Probably a developer.
• Boosts, deboosts, and suppresses data sources and results with particular titles or paths based on the matching intent and domain.

As an additional safeguard, the Robotina system prompt is designed to ask for clarification and aggressively cite sources to reduce the risk of nonsense.

Glossaries and domain graphs

Unless you fine-tune it or train your own, a language model does not have access to the internal language of your company. Glossaries and domain graphs help Robotina understand that scheduled feature has a very specific meaning, and that waistcoat is synonymous with guitar pick (not really, but you know what I mean).

Doctective and discrepancies

On the content health side of things, Robotina’s sibling Doctective 🔍compares incoming content to existing content and uses AI to perform consistency checks. Have you already documented boop-boop-bleep? Do an embedding search! Does the incoming content contradict the existing content, or is there a ‘weird’ match? Compare the results! Refine your content!

Robotina, technical writing, and me

Although Robotina has grown into much more than a side-project and I currently write more prompts and code than docs, I still consider myself a technical writer. Documentation needs to exist before it can be leveraged by a robot, and someone needs to write it (or edit it, if it’s auto-generated by a code analysis pipeline – another promising Robotina sibling).

Ultimately, content structure and clarity determines the quality of your RAG pipeline output, and you can’t boost or filter your way out of bad writing. 

Content is still king. Robotina and her gang are just tools to get the right content into the right hands at the right time with as little nonsense mixed in as possible.