The TEMPLE Model: Six Perspectives for Designing Internal and Regional Communities

Key points (30 seconds)

- Conclusion: The TEMPLE model organizes our experience of running Miyako de IT into six perspectives. It is not a formula that produces success when applied

- The six perspectives are Theme, Environment, Members, Persistence, Local, and Evolution

- Each perspective carries indicators to check. Read them as questions to use in judgement rather than as answers

- They can be applied to internal and to regional communities, though there are situations where they are better not applied

- The basis is what we observed across 7 years and 153 events held in Kyoto

The TEMPLE model organizes our experience of running Miyako de IT, an IT community in Kyoto, into six perspectives for thinking about regional and internal communities. The name comes from the initials of Theme, Environment, Members, Persistence, Local, and Evolution.

The model is not a formula that produces success when applied. It is a hypothesis, arranged into questions usable in judgement by reviewing—across running a community in Kyoto since 2019—which programmes continued, which stopped, where participants stayed, and where a group closed in on itself. Other organizers are welcome to use it as a base for thinking about the conditions of their own organization or region.

---

The six perspectives of the TEMPLE model

The six are not a sequence of steps. At launch we often decide T, E, and M in that order, but once operations begin any perspective can be used for review. Below, each perspective is set out with what to decide and what to check afterwards.

---

T | Theme — what do we think about together here?

A theme is not an event title. It becomes a theme only once the following are decided.

• Whose interest, and which interest, it addresses
• Whether it is a one-time topic or a question that can continue
• Whether participants can bring their own experience to it
• How it balances specialization against ease of participation
• What distinguishes it from other settings

Broad words such as "AI", "Web3", or "careers" do not let participants judge what they can take away. Turn the theme into a question.

• How much authority should be handed to an AI agent?
• What should a regional company and an IT engineer settle before starting a PoC?
• What does a first-time speaker talk about in five minutes?
• What becomes visible when quantum mechanics is connected to bodily experience?

The same applies inside a company. "A setting for advancing DX" or "a setting for promoting innovation" is too abstract for participants to make their own. Bring it down to a resolution at which someone hearing it can judge whether they should be there, such as "a setting where, in six months, business units bring their AI-use cases and organize them into a form that can be deployed across the company".

For Miyako de IT it can be written in one sentence: "create points of contact between IT and the local in Kyoto." Because that sentence exists, a web engineer, a startup executive, and a local-government officer can each judge whether it concerns them.

Indicators to check

• Whether first-time participants can understand the content
• Whether it can be held continuously
• Whether speakers and joint programmes increase
• Whether solicitation unrelated to the theme has increased

Theme design itself is explored in Regional communities differ through theme design.

---

E | Environment — in which environment can people take part?

Environment covers the venue, time, participation fee, capacity, atmosphere, facilities, and online support.

Holding events at Kyoto temples and machiya townhouses is not for photogenic effect. We choose them by considering how a space unlike an everyday workplace affects participants' conversation and memory. Miyako de IT has used Butsugenji, in Rokkaku Aburanokoji, Nakagyo-ku, Kyoto, continuously since April 2024, for three reasons we consider relevant: the main hall keeps outside noise out, passing through the gate and removing shoes works as a switch out of work mode, and the experience of writing code at a temple itself creates a point of contact between the region and IT (case study: Butsugenji).

At the same time, the appeal of a venue alone does not keep operations going. The items to settle are as follows.

• Distance from the station
• Power and Wi-Fi
• Heat and cold
• Noise
• Barrier-free access
• Participation by minors
• Photography
• Food and drink
• Emergency response
• Venue cost and clear-out time

Whether an environment is suitable changes with who participates and what the programme is for. When holding events inside a company as well, an ordinary meeting room makes it harder to leave work mode, so having options—an external rental space, the company cafeteria after hours, a visit to a partner's office, an off-site at a milestone—changes the atmosphere.

Indicators to check

• Attendance rate after registration
• Anxiety among first-time participants
• Venue trouble
• Setup and clear-out workload
• Whether continued use is possible
• Whether the venue matches the theme

Treating a venue as an asset is covered in detail in When the venue becomes the brand.

---

M | Members — who is involved, and in what role?

Treating every participant as occupying the same position concentrates the load on the organizer. Separate the roles.

Organizer, programme planner, day-of operations, speaker, regular, first-timer, venue provider, co-host, sponsor, records and communications, next-session planner.

What matters is not conferring titles but handing over small roles. Create entry points participants can take on without strain: reception, photography, timekeeping, guiding people, writing a report, proposing the next theme.

Designing the second visit

What is easily overlooked is a mechanism that encourages a first-time participant to come again. Drop-off is most likely immediately after a first visit, and where the pool of people is limited—inside a company or in a region—a design that depends on recruiting new people continuously runs out of breath within months. Six things we keep doing at Miyako de IT:

• Lower the barrier to attending: keep the participation fee low
• Assume people come alone: state that solo attendance is welcome every time, with the organizer making the first introduction
• Speak to everyone in the first five minutes: a 30-second conversation at reception sets the impression of being welcomed
• Hand over the next date as people leave: alongside saying it, describe how to receive notifications
• Explicitly allow late arrival and early departure
• Do not exclude by skill level: in a co-working format where each person advances their own task, differences in skill do not affect the experience

Inside a company, the concern that "it is hard to speak frankly in front of a manager" comes up readily, so we repeat check-in time at the start, a stated dropping of job titles, and an explicit scope for what the minutes will share.

Indicators to check

• Whether operations are concentrated in one person
• Whether first-time participants come again
• Whether anyone moves from participant to speaker or planner
• Whether the group has closed around regulars
• Whether solicitation and harassment can be handled

---

P | Persistence — at what frequency and workload can this continue?

Continuity is not determined by willpower alone. What is decided is the following.

• Frequency
• Preparation workload
• Venue booking
• Promotion period
• Participation fee
• Sponsorship
• Records
• The organizer's own life
• Conditions for pausing
• Conditions for resuming

Monthly is not necessarily right. Vary the cycle by format: quarterly for themed events, monthly for co-working sessions, seasonal for networking events. Some sessions will have few participants. Rather than treating unstable early numbers as failure, define first the smallest scale that can continue.

Three operating guidelines we hold at Miyako de IT. Read them not as universal answers but as criteria that have worked under our conditions.

• Take monthly as the baseline and do not stop: the predictability of "it will probably be on again next month" is itself a form of trust
• Do not set a KPI for participant numbers: aiming for ten or more makes a session of eight feel like a failure and wears the organizer down
• Do not make holding an event an obligation: keep the co-working session as the basic form and add networking or lightning-talk events only in months with capacity

When the gaps between events fall silent, a community loses its presence. Sending thanks and the next date on the day, sharing records within a week, and a reminder a week before the next session keeps the event present in participants' minds.

Roles such as venue, records, communications, and outreach should be handed to regulars early. Running for years while they remain tied to one person raises the cost of systematizing them later.

Indicators to check

• Events per year
• Organizer workload
• Cost per session
• No-shows without notice
• Continued participation
• Reasons for pausing or cancelling
• Whether the organizer can be replaced

Patterns in how communities stop are set out in Seven common failures in community operation.

---

L | Local — how does this connect to the regional context?

Regional character is not putting a place name in the title. In Kyoto's case there are several assets: temples, machiya townhouses, universities, public facilities, regional companies, culture, tourism, students, and international exchange.

Points to check when using a regional asset are as follows.

• What value there is for the venue side
• Whether local rules are respected
• Whether roles and costs are made clear
• Whether permission for photographs and publicity has been obtained
• Whether the relationship continues after a single event
• Whether it can be copied to another region as it is

A programme that worked in Kyoto will not necessarily work the same way elsewhere. Rather than transplanting the model, use it against the assets of that region.

Miyako de IT currently has relationships with 14 organizations and institutions, including Butsugenji (venue), Kyoto Chie Sangyo Sozo no Mori (co-hosted networking events), Digital Nomad Kyoto (co-hosted co-working sessions), and Taisho University Kyoto Academia (venue). Each began with us reaching out, and those that have continued share a feature: the other side's purpose—venue visibility, career contact for students, visibility for regional technical talent—holds at the same time. How we build these relationships is set out in the community partnership guide and on the partners page.

Indicators to check

• Continuing relationships with regional organizations
• Repeat use of venues
• Participants from the region
• Joint programmes
• Programmes led by the regional side
• Attribution of roles in outcomes

---

E | Evolution — how far do we extend the activity?

A community does not have to grow in scale. It may extend from co-working sessions into lightning talks, study groups, networking events, hackathons, academia–industry collaboration, and PoCs; or it may be more valuable to keep a small regular meeting going.

When thinking about evolution, divide the activity into three.

• Contact: events that are easy to attend for the first time
• Relationship: continued participation, speaking, joint planning
• Value: research, recruiting, technical communications, business, PoCs, regional projects

Pushing people from contact toward value strengthens the impression of a sales pitch and damages participants' trust. Separate participation purposes from business purposes and make attribution of outcomes clear. For example, a team of members who had connections through Miyako de IT won the grand prize at HACK+2023. The award was made by the organizers, and we do not write it up as an outcome of the community. How the team came together is left to the HACK+2023 record and is not asserted here. Whether it went into production, or became a business, is not asserted here either. Deciding where that line falls in advance keeps you from inflating attribution when you describe outcomes.

Indicators to check

• Continued participation
• Speaking and planning
• Co-hosting
• Joint research
• Recruiting contact
• PoCs
• Derived projects
• Time until an outcome appears
• Roles and attribution

---

When to use the six perspectives

Six questions for reviewing a running community

• Can the theme be written in one sentence? (T)
• Are the venue and time chosen to fit participants' lives? (E)
• Is there anyone besides the organizer with an explicit role? (M)
• Can participants predict when the next event will be? (P)
• Is there a point of connection outside—another department, a client, a regional organization, another community? (L)
• Can you explain which layer you are in: contact, relationship, or value? (E)

When several of these cannot be answered, review from that perspective. Being able to answer all of them does not mean the operation is good.

---

Situations where the model does not fit

Under the following conditions, consider whether a community is the appropriate form before applying the TEMPLE model.

• People attend only because a manager instructed them to
• The sole purpose is short-term sales lead generation
• Nobody but the organizer can make a decision
• The budget or venue ends with a single fiscal year
• There is no code of conduct or contact point for reporting
• Participant data is collected excessively
• Only the name of a region or venue is being used

These are problems that precede the design of any perspective, and applying the model does not resolve them.

---

Where this sits at Miyako de IT

Miyako de IT has continued since its first co-working session in February 2019. Current event and registrant counts are updated on the activity statistics page, and the analysis fixed as of July 17, 2026 is published in the Kyoto IT Community White Paper 2026. The figures are the number of events held and the number of connpass members registered; they are not a cumulative count of people who attended.

The TEMPLE model does not derive a formula for success from those numbers. It reviews the events and judgements of running a community and arranges them into questions other organizers can use to think about their own conditions. We intend to add to each perspective over time, including failures, costs, attendance rates, role transitions, and cases where the model could not be applied—not only successes.

---

Related articles

• Lessons from running a regional IT community: a record from 2019 to 2026
• TEMPLE-T: theme design for a regional community
• TEMPLE-E: when the venue becomes the brand
• Seven common failures in community operation
• How to build an IT engineer community: starting with three people on connpass
• For people who find engineer meetups intimidating

Come and see one

Seeing a working setting once is sometimes faster than reading and designing. Miyako de IT events are published on the upcoming events page. If this would be your first time, the first-time guide describes the flow of a session.