Best Practices for Working at Sponic Gardens

Expectations and processes for everyone doing paid work, worktrade, or contract work at Sponic Gardens — staff, contractors, residents-in-trade, and visiting collaborators. Working here requires task efficiency, hard-core organization, consistent & clear communication, and a relentless focus on the member and guest experience.

The Sponic mandate

Sponic Gardens creates natively AI-managed spaces that promote socialization in a healthy, inspiring, and productive manner. The AI works for the members' best interests. Every decision you make about your work should ladder up to that mission.

We are operating towards a goal of:

• An amazing member experience that brings undeniable value to the lives of our members across a variety of axes.
• 100% organization. Every item — physical or digital — has a designated place.
• 100% completion of projects. This won't always happen, but everything should be designed to try to make it happen. Don't partially or 90% finish a project. Don't leave things in an unfinished state without a clear approved plan to finish them.
• Self-service usage by members and guests. Others should be able to operate things without asking how. If a member needs to ask staff how to do a routine thing, that is a design failure to fix, not a one-off to answer.
• Low-labor operation. Labor is the bottleneck. Anything that needs a lot of work after it's done is highly sub-optimal. Prefer the solution that requires less ongoing human attention, even if it costs more up front.
• Enduring value. Most physical structures should last 10–20 years without major maintenance. Electronics and software are designed to be continually enhanced and structured in a way that increases value over time.
• Scalable from day one. Always ask yourself: "will this scale to many members, many properties? If not, figure out what can be made more scalable."

All of these factors influence the design decisions for projects and work.

Member & guest experience

• As much as anything, focus on the member and guest experience. Top priority is keeping every visitor happy before, during, and after their visit.
• One little negative drags down the whole experience. Spend more time on what isn't working than on what is.
• Consistency of experience is critical to our success. If there's an opportunity to give a member or guest a better experience, take it — unless a standard policy says otherwise.
• Focus on developing and improving the overall process, not on a single event. The biggest wins are systemic — they pay off across every future member and guest, often by a very large multiple. Member experience is our first line of defense in understanding how to become a better organization.

AI-first by default

Sponic Gardens is an AI-first company. That is not a slogan — it is a job expectation. Everyone, in every role, is expected to use AI to assist in all capacities of their work, and to actively push the capabilities of AI to the current limits. Operations, hospitality, finance, gardening, member relations, recruiting, scheduling, writing, design, research, engineering — all of it.

• AI-reflexive, not AI-curious. When you hit a problem — a question, a draft, a calculation, a research task, a stuck decision — your default first move is to bring an AI into it. If you're typing the same thing into a search bar more than twice, you should be talking to a model instead.
• Push to the current limit. Don't stop at "the AI can draft this email for me." Push to "the AI is monitoring this inbox, drafting replies, surfacing anomalies, and only escalating to me when it can't decide." Be ambitious about what you delegate.
• Revisit what AI can't do — on a schedule. If a task today cannot be well automated or enhanced with AI, that is a temporary state. Mark it. Revisit every couple of months. Models, tools, and our internal infra all improve quickly; what was impossible last quarter is often trivial this quarter. The biggest mistake is to assume "AI can't do that" once and never re-check.
• Use AI to learn, not to skip learning. When AI does work for you, you are still responsible for understanding the work. Ask the model to explain its reasoning. Read its output critically. Understand the system 2–3 layers below where you're operating. AI accelerates learning — it does not excuse you from it.
• Verify before you ship. AI output is your output once you send it. Hallucinations, stale knowledge, fabricated citations, and confident-sounding errors are real. Apply the same "verify what you're told" standard from the Taking initiative section to anything a model produces.
• Write for the next reader, who might be a model. Every doc, ticket, journal entry, and decision should be written so that an AI picking it up cold can act on it. Use clear headings, define terms, link to context, avoid in-jokes and acronyms-of-the-day. This is the same hygiene that helps a new human teammate — AI just amplifies the cost of skipping it.

Vibe-coding & agentic engineering

Beyond using AI as a copilot, everyone at Sponic is expected to become proficient in vibe-coding tools and agentic engineering processes — to the point where they can carry an idea through the full product lifecycle themselves:

1. Conceptualization — frame the problem, articulate the member or operational outcome, sketch the smallest valuable version.
2. Specification — write a project spec a model and a human can both build from, including goals, non-goals, success metrics, and explicit constraints. (See Project management.)
3. Implementation — drive an agent (Claude Code, Codex, Cursor, or whatever the team has standardized on this quarter) to actually build the thing. Review the diff. Push back when the agent does something dumb. Land the change.
4. Functional testing — write or have the agent write tests, run them, fix what breaks. Don't ship anything you haven't seen run end-to-end at least once.
5. User testing — put it in front of real members or staff, watch what they actually do (not what they say they'd do), iterate. The dogfooding loop at Sponic is short on purpose; use it.

You do not need to have been a software engineer to do this. You do need to be willing to learn how to operate the tools, read code with AI help, understand what's being committed in your name, and keep going when an agent gets stuck. If you're not there yet, that is a proficiency to build, not a permanent exemption. Ask for pairing time. Watch someone else do it. Then do one yourself.

Working with the AI stack

Sponic Gardens is a natively AI-managed space. That has real implications for how you work — beyond what you'd see at a normal organization.

• The intranet (in.sponicgardens.com) is the operational source of truth. Tasks, member profiles, gatherings, devices, image catalog, payouts — all of it lives there. When you find a gap between reality and the intranet, fix the intranet, not just reality.
• Tasks can be run by AI. Every task in /en/tasks/list has an LLM prompt field; clicking Send queues a headless Claude run. If a task is something an AI could plausibly do, write a good prompt and try it before doing it by hand.
• Images flow through the catalog. Any image you generate or upload — for any reason, in any app — must go through the image-gen wrapper, not raw Azure / Gemini / R2 calls. See the canonical guide before generating images.
• Document what you do in a way an AI can read later. Notes in chat get lost. Docs on the intranet, in Drive, in the task system, or in the dev journal survive and inform future decisions (human and agentic).
• Member-facing AI is a member, too. The AI host at an Agentic Gathering, the dossier extractor, the coaching prompts — they work for the members' best interests. When you tune them, ask the same question you'd ask of any staff action: is this in the best interest of the member?

Communication

• Over-communicate, and try to be very clear. Explain to the relevant people what you're doing, why, and when. This lets them give feedback and align their efforts with yours. Spend extra time on this.
• If something on your task list isn't getting done, communicate frequently about why and ask for help.
• Use the right channel. Email, Slack, the inDocs website, AI agents, WhatsApp, and phone calls each have a role. If you don't get answers, escalate channel — don't sit silently on a dropped thread.
• By default, everything of reference value lives on the internet — on the intranet (in.sponicgardens.com) or the public website — well-organized for both humans and AI agents to review.
• If Sponic needs something and it's not in place, minimally communicate the deficiency until it's acknowledged — and preferably start the fix yourself.

Follow-up cadence

When you're responsible for something, you are responsible for driving it to completion regardless of who else has to act. It is your job to make sure the job gets done — or gets officially deprioritized for a good reason. What is not a good reason: "someone else isn't doing something they should be doing."

In general:

• No response in 2 days: resend the email.
• No response in 1 more day: call the person, leave at least two voicemails, and text them.
• Still no response: either continue to aggressively follow up, or escalate to determine the next step.

Don't rely on just email or messaging. Call people. Bother them. Do not wait idly for multiple days when someone else's response would unblock the work.

Task efficiency & organization

• Use a digital task system for everything — the intranet task list at /en/tasks/list. Put due dates on all tasks to prevent them being put off.
• If a due date slips, communicate why and what the plan is:
  • It's fine to miss dates sometimes when priorities shift.
  • It's not fine to miss dates silently and not update the task.
  • Always ask for help before a date slips.
• Every task needs a clear goal and a priority relative to all your other tasks. Why are you working on this? What is the desired end result? If you don't know, talk to your team and reach a shared understanding everyone is comfortable describing.
• A task isn't done until it is actually done — reviewed, accepted, modified, and launched. To be "done" it must have a positive impact on member experience or some other measurable effect. Doing 90% of a task is a net loss: lots of effort, little return.
• Anything you can finish in 15 minutes or less, do today. Don't be a blocker. If you have more than ~12 of these in your queue (more than ~3 hours' worth), tell your lead and ask for help.
• Follow up every day on what you own. If something needs daily follow-up, do daily follow-up. Don't worry about being a bother — worry about not getting things done. You own your tasks even if they have dependencies.
• Don't accept blockers. Never participate in the attitude of "we can't fix it." If it's important, the mindset is: we will fix this. What's the path to a complete fix, starting now?
• Escalate blocked work. If you can't get something done in time and can't find help, ask Rahul. If you don't get stuff done and you don't ask for help, it's your issue.
• If you don't know how to do something, Google it / ask an AI. Don't say "it can't be done" or "I don't know how" without genuinely trying.

Organizing information

• Get highly organized. Only with organization can a venture scale. Always ask: "will this scale to many people? to many properties?" If not, figure out what can be made more scalable.
• Be detail-oriented. For everything you're responsible for, ask: "if a random staff member or member was looking at this, would it make sense to them without explanation?"
• Take notes in AI-friendly tools. We have various ways to do this. AI agents should be able to read all the notes immediately and process them — that's the bar. Not paper, not a local notes app, not a buried WhatsApp message.
• Do not use email to organize information or convey structured proposals. Use email to alert people of items and to update them on changes. Put the content itself somewhere reviewable, versioned, and AI-readable.
• Put all files on the internet — on the intranet or the public website. If you see a doc that isn't organized or isn't on the web, fix it or ask the owner to.
• For internal-facing operational docs, prefer the intranet (in.sponicgardens.com/indocs/) — Reference, SOP, Pitch, Spaces, Dev tasks. That's where institutional knowledge lives long-term.
• Avoid acronyms if there is any ambiguity. If you want to introduce a new acronym for day-to-day efficiency, propose it before you start using it.

Meetings

• Be on time.
• Have project tools and video conferencing set up before the meeting starts.
• Include a clear agenda and goals in the calendar invite — and also email the attendees.
• Put all relevant doc links in the invite so people can review beforehand.
• Make sure people have edit or at least comment access to the docs.
• If the meeting is not happening, take it off the calendar immediately, as soon as you know.
• If there are more than 2 people and it's not in person, include a video link.

Taking initiative

• Take strong initiative. Get stuff done, and get stuff done quickly.
• Ship to members. Launch new initiatives so they can get into members' and guests' hands. It doesn't matter that it isn't completely finished, as long as it's in a state where feedback can be given. The sooner we get feedback, the faster we get to the right result. Done is better than perfect — but make sure people have a chance to review before launch.
• Communicate priorities periodically to your peers and team leads. Let people know what's low on your priority list (and will therefore take a while).
• Don't wait for "approval" unless the work requires significant spending (over €100) or has significant impact on the organization, members, or guests. Communicate what you're planning to do, then start it, finish it, and update along the way.
• Be proactive about ownership. Take ownership of things that need improvement, or be clear about who has ownership. If nothing has an owner and it should, say so. Don't wait for others to tell you to do things — figure out what needs doing.
• Verify what you're told. If you own an area, you can't rely on hearsay. If you don't understand why something is done a certain way, ask. If no one knows why, it might be something that should be reconsidered. Never accept "because it's been done that way before" as a justification. Trust comes after a clear history of verification.
• Don't do things just because someone asks. Always ask yourself: "is this in the best interest of the members, the organization, or the system to serve them?" If you think a request doesn't make sense, articulate why and get feedback before proceeding. If it still doesn't make sense after that, keep raising it. Don't cave on things you believe in. Don't worry about being annoying. Worry about letting bad decisions happen on your watch.
• Opposite also applies: if someone says we shouldn't do something and you think we should, advocate for it the same way.

Metrics

Measure, measure, measure (and track) everything — and push the metrics to the team along with commentary on why they are what they are and what new actions each metric indicates we should take. This is a huge priority. Before deciding not to do metrics on something you're working on, confirm that metrics are not a priority for that thing.

• Schedule recurring meetings to review action proposals from the metrics.
• Metrics should always be about the trend, not a snapshot. How are we doing relative to where we were before? Come up with ideas to test, then draw conclusions.
• Metrics without ideas for what they mean, why they matter, and how to improve them are not useful.
• Metric labels must make the actual numbers 100% clear. "17% repeat usage" is ambiguous. "17% of members who attend one Agentic Gathering attend another within 30 days" is clear.
• Metrics should be collected and analyzed as continuously as possible with the AI, and should lead to optimization actions. It should always be clear what we are optimizing for.

Project management

Projects can be small or large — anything from a new tool launch to a new product launch to a new room build-out. For software projects with the dev team there is a specific dev process. For all non-dev projects, use the following. The structure helps you think through things you might miss.

1. The key prerequisite to a project is defining goals, non-goals, schedule, and success metrics.
2. Create a Project Spec doc whenever you launch a new project.
   • Name your document descriptively and share with the relevant team. Make sure people at Sponic have edit access unless there's a reason not to.
   • Create a project folder at indocs/projects/[project-name] and put all related documents in it.
   • When linking to a document, use the document's name as the link text — not "click here" or a raw URL.
   • When a Google Doc needs to be accessible org-wide, set permissions so anyone with the link can open it.
3. Immediately schedule a review of the project doc. Put it on the calendar before the doc is complete.
4. Once the first draft is done, email a link to everyone relevant and ask for inline comments.
5. Address comments via whatever channel makes sense — email, calls, in-person. Resolve as much as possible before the review meeting.
6. At the review meeting, take notes of all open issues and action items.
7. Revise and resend. Schedule another review if needed.
8. Create tasks with owners and due dates for all activities.
9. Calendar all other project activities according to schedule, including final reviews.
10. Continually drive to 100% completion and roll-out. Elevate any blockers to the review group.
11. Ask for help early if you're at risk of missing the schedule.

Cost considerations

For any project, it is critical that the cost boundaries are understood — especially the top boundary. What is the most this could cost before it is 100% complete? That number should be clearly communicated up front. The cost of getting something 80% complete doesn't really matter — what matters is the all-in cost of reaching done.

Agreements & physical space

Sponic is an agreements-based organization. Everyone is expected to follow the agreements (and work to modify them when beneficial), including reading the relevant documents. Help others understand the agreements, and ensure that everything is operating within them.

Everything has a place

All items on the property should have a designated place, and no items that don't have a designated place should be kept on the property — if they are here, they should have a place. All items and amenities should be discoverable by someone looking for them, and those that might benefit from them should be discoverable by those who aren't even looking.

This same philosophy extends to digital items and information. Locations should be clearly understood by users of the space. To the extent possible, people should be able to find what they need and do what they need without asking. Use labeling or visible storage. Group similar items together, close to the place where they're likely to be needed.

Clean up after yourself, in an organized manner

Don't leave tools or materials strewn about. Make sure everything is safe. If you're finished with the project, put everything back. The project is not finished until everything is cleaned up and tools are placed in their proper organized places.

Logging work hours

If you're on a worktrade, hourly contract, or similar paid engagement, you must report hours on the same day you do the work. Any work done without same-day reporting is compensated at a discounted rate of 25%. This is needed to ensure work is on track in the right direction, can be reviewed before other work is started, and verified as aligned with best practices.

If you don't do this on the same day, work tends to drift in sub-optimal directions to varying degrees. Read this section again — following the process ensures full pay.