Skip to content

Culture

This section defines who we are, how we work, and what we expect from each other.

The Appcircle Standard

Five behaviors define how we operate.

Status Keep people informed without being asked. Update your tickets. Post progress in the right channel. Make your work visible. Visibility keeps the team aligned and lets blockers surface before they become problems.

Follow-up Own your work end-to-end — not just the implementation, but the outcome. Track it. Confirm it landed. Don't assume someone else is watching.

Escalation If something is too big, too ambiguous, or past your authority, say so early and bring context with you. The sooner it surfaces, the easier it is for the team to address.

Delegation You don't have to do everything yourself. Define the work clearly, hand it off, then track it. Your job is to own the outcome — not to be the only pair of hands on it.

Quality Quality comes before time and stress. Work is done when it's done right, not when it's done fast. "We rushed it" is not an excuse for sloppy output. If the timeline doesn't allow for quality, raise that early (see Escalation) rather than shipping something you know isn't right.

These are soft skills, and they matter. Practicing them consistently is what makes collaboration work here.

Red Lines

Zero Tolerance

Any of the following results in immediate termination — no warnings, no process:

  • Data or IP breach — sharing company or customer data without authorization
  • Harassment or discrimination — toward a colleague, customer, or anyone else
  • Fraud or dishonesty — falsifying records, reports, or expenses
  • Deliberate concealment — knowingly hiding a problem to avoid accountability, after the fact

Making a mistake is not a red line. Choosing to hide one is.

Remote Work

We are a remote-first team. This section defines how we stay aligned, productive, and connected without a shared office.

Principles

Async first. The default is to write things down — in Linear, Slack, or a doc. Meetings are the exception, not the default. Before scheduling a call, ask: could this be a message?

Outcomes over hours. We measure results, not presence. Own your work, hit your commitments, and communicate when something slips.

Stay in sync with your team. Flexibility exists, but it has a limit. The more your hours overlap with your team's, the easier collaboration gets. Drifting into a completely different schedule creates friction for everyone — don't let it happen quietly.

Transparency by default. Remote work breaks down when people go quiet. Share progress, surface blockers early, and document decisions. If no one can see what you're doing, it's the same as not doing it.

Working Hours

  • Work 8 hours per day.
  • Attend scheduled meetings during the day.
  • If you need to step away, you can plan around it — as long as it doesn't block async work for others.
  • Keep your Slack status up to date at all times. If you go offline, set when you'll be back.
  • If you're on annual leave, post in the #leave-notification channel. That's the first place people look when they can't reach you.

Meetings

  • Camera is off by default for daily standups.
  • Camera is encouraged for happy hours and when a new team member joins — these moments are worth showing up for.
  • Meetings should have an agenda. If there's no agenda, question whether the meeting needs to happen.
  • Keep meetings short. If a decision can be made async, make it async.
  • After a meeting with decisions or action items, write a brief summary in the relevant channel or doc.

Daily Standup

Standups are short by design.

Format: - 1 minute per person, maximum. Yesterday / today / blockers. - Linear tickets are updated before the standup — not during. The standup is not a ticket review session. - The lead runs it. It starts and ends on time.

After the standup: - If you have no questions, leave. - An open AMA session follows for those who stay. - Leads are available in this window — and in this window only for non-urgent questions.

During the rest of the day: - Don't interrupt the lead or a teammate for non-urgent questions outside the AMA window. Collect them for tomorrow unless it's genuinely time-sensitive.

Why this matters: Every unplanned interruption breaks a focused work block — for you and the person you interrupted. The AMA window batches interruptions into one slot. Knowledge that would otherwise stay siloed gets shared in a structured window.

Communication Tools

Tool Use it for
Slack Day-to-day communication, quick questions, status updates
Linear Tasks, bugs, feature requests, project tracking
Internal Doc / SharePoint Long-form decisions, processes, reference material
Microsoft Teams Video calls, 1:1s, team syncs

Don't use Slack for decisions that need to be findable later. Put those in a doc or Linear.

Staying Connected

Remote work can get lonely. We don't want that.

  • Join team channels and engage beyond just work threads.
  • Show up to company events — they exist to keep the team human.
  • If you're feeling isolated or disconnected, tell your manager. We'd rather know early.

Communication

How we communicate — inside the team and with customers.

Blame-Free Culture

When something goes wrong, the first priority is to fix it — not to find someone to blame.

Blame-free culture is not about avoiding accountability. It is about creating an environment where people feel safe reporting problems early, which is the only way problems actually get solved.

When people fear blame, they hide mistakes. Small problems become big ones. Root causes stay buried. By the time something surfaces, the cost is already much higher than it needed to be.

When people feel safe, the opposite happens: issues surface early, the team responds together, and the system improves. Accountability still exists — it just comes after the fix, not before it.

How this works in practice:

  • Report problems as soon as you see them. Early reporting is always better than late reporting.
  • When something goes wrong, focus on what happened and why — not on who.
  • If you made a mistake, say so. It will be handled as a system or process issue, not a personal failure.
  • After a problem is resolved, the team may take action to prevent recurrence. That process is impersonal and constructive — it is not a blame session.

Making a mistake is human. Hiding one is a choice — and the only thing that actually works against you here.

Recognition

Good work should be acknowledged — not just assumed.

When a team member ships something meaningful, handles a tough situation well, or goes beyond what was expected, managers are responsible for recognizing it. Recognition is not a bonus. It is part of how a team stays motivated and connected.

How we do it:

  • Call it out in a relevant Slack channel — publicly, by name, with specific context. "Great job" is less meaningful than "Ahmet shipped the SSO integration ahead of schedule under a tight deadline — well done."
  • Timely recognition matters more than formal recognition. A quick message the same week means more than a mention months later.
  • Recognition is not reserved for big launches. Consistency on hard problems, clean handovers, helping a teammate through a blocker — these count too.

If you are a lead or manager and your team is doing good work, tell them. Tell the team. A few sentences in Slack takes two minutes and has a lasting effect on how people feel about their work.

Sharing Files

We do not attach files to email, Slack, or MS Teams messages.

Instead, upload the file to OneDrive and share the link.

  • Keeps a single source of truth. The file stays editable and current; nobody ends up working from a stale copy pulled out of a chat thread.
  • Access stays controlled and revocable. A link can be scoped and pulled back; an attachment, once sent, is gone.
  • Keeps channels light and searchable, and avoids scattering company data across message histories.

This applies to internal sharing and to files sent to customers: share a link, not the file itself.

Customer Communication

Each customer has their own SLA. Check the agreement before responding.

Do:

  • Use specific timeframes. "By Friday" or "within 2 business days" — not "soon" or "ASAP."
  • Use standard terminology. Appcircle, platform, module, Root Organization, Testing Distribution Portal. Don't invent new terms or use different ones for the same thing.
  • Acknowledge before solving. Recognize the customer's frustration first, then focus on the solution. "I understand this has taken longer than expected. We're currently at [status] and will get back to you by [date]."
  • Number your questions. If you need multiple pieces of information, send them in one message, numbered.
  • Confirm before committing. Check with the team before giving a deadline or making a promise. If uncertain: "I'll check with the team and share a clear update by [date]."
  • Own it and follow through. Don't leave a conversation open-ended. If there's a delay, proactively update the customer — don't wait for them to follow up.
  • Keep messages structured. Short paragraphs, clear next steps, easy to scan.
  • Clarify ownership in multi-stakeholder threads. State explicitly who is doing what.

Don't:

  • Use vague language: "soon," "ASAP," "we're checking," "as soon as possible."
  • Share personal reasons for delays: illness, being busy, "someone else was handling it." The customer doesn't need to know — and it doesn't help them.
  • Over-commit. No deadlines or promises without team sign-off.
  • Leave communication unresolved. Don't expect the customer to chase you.
  • Share internal information: screenshots of internal systems, internal discussions, or unconfirmed plans.
  • Minimize the customer's complaint. Avoid "this isn't actually a bug," "this is expected behavior," or "the system works this way."

Handling Blockers

If you're stuck, try to work through it on your own for 1–2 hours. After that, ask.

Staying blocked silently is not acceptable. A blocker you don't surface becomes a missed deadline someone else didn't see coming.

How to raise a blocker:

  1. Post in the relevant channel.
  2. Describe: what you tried, what's happening, and what you need.
  3. Tag the right person — your manager or the subject-matter expert.

Asking for help is not a weakness. Staying stuck to avoid looking like you need help is.

Deadline Ownership

You own your deadlines.

Before giving a date, understand the work. If you don't know yet, say so — "I'll confirm by end of day" is better than a number you'll miss.

Before committing to a date:

  • Break the work down. Estimate each piece.
  • Account for what isn't obvious: dependencies, reviews, testing, deploy time.
  • If you're unsure, check with the team before answering.

When urgent work affects your timeline:

Deadlines shift when unplanned work lands mid-sprint. If an urgent task is assigned to you while a project deadline is already in place, that deadline may need to move — and that is expected. For example: a project due June 20 shifts to June 27 when a week of urgent work lands in between. Project owners are responsible for flagging this to their manager as soon as the impact is clear. Managers need this visibility to plan around it. Don't absorb the disruption silently and then miss the date.

If a deadline is at risk:

Say so early. Not on the last day — the moment you know something might slip.

Include: - What's blocking you - What a realistic new date looks like - What you need (if anything)

A late warning is not a warning. It's just late news.

Escalation

When a problem is beyond your scope or authority, escalate — don't sit on it.

Escalation path:

  1. Direct manager
  2. Their manager or relevant lead
  3. Leadership, if it's critical

When to escalate:

  • You've been blocked for more than a day
  • The impact has grown beyond your team
  • A customer is involved and you're unsure how to handle it
  • Something feels wrong and you can't explain why

How to escalate well:

Come with context, not just a problem. Before you escalate, write down: - What happened - What you've already tried - What decision or support you need

Don't escalate in panic. Escalate with information.

Bring Solutions, Not Just Problems

When you take a problem to your manager, bring proposed solutions with it. Don't just hand over the problem and ask them to figure it out.

"This broke, can you look into it?" is not how we work. Instead:

  • Lay out the options you see.
  • For each, give the pros and cons.
  • State which one you'd choose and why: "I'd do X, what do you think?"

This turns the conversation into a decision instead of a new task on your manager's plate. You did the thinking; they make the call with you. The same applies to anyone you bring a problem to, not just your direct manager.

Brand

Anything that carries the Appcircle name in public - a landing page, a slide deck, a one-pager, a social post, a document shared with a customer - represents the company visually. Consistency there is not a design preference; it is how the brand stays recognizable.

Visual Assets

The Press Kit is the single source for Appcircle brand assets: logos (vertical, horizontal, and product-specific for Build, Testing Distribution, Publish, and Enterprise App Store) and the brand color palette, in SVG and PNG.

Use Press Kit assets as they are. Don't recolor, stretch, crop, redraw, or rebuild a logo, and don't pull one out of an old deck or a screenshot. Download the current file from the Press Kit.

If what you need isn't in the Press Kit, get approval first. A new icon, an illustration, a font, a third-party logo, a color outside the palette - ask Marketing before you use it, and wait for the answer. Fixing an off-brand asset after it is published costs more than the question does.

Third-party assets need a license check. Icon sets and stock images are not free by default. Confirm the license permits commercial use before the asset goes anywhere public.

Spelling is part of the brand. It is Appcircle - capital A, one word. Not "appcircle", "App circle", or "App Circle".

If you are building something customer-facing and you're not sure whether it is on-brand, share it in the relevant channel before publishing.

Leave & Benefits

Leave entitlements for Türkiye-based team members. For how to request or report leave, see Emergency Leave and Working Hours.

Annual Leave (PTO)

  • 10 working days of paid time off per year.
  • Accrual: you become eligible after your first 6 months, accruing in 5-day increments (not all 10 days are available from day one).
  • Recommended split: 5 days in summer, 5 days in winter. This is guidance, not a hard rule.
  • Annual leave is taken with your team manager's approval.
  • Use it or lose it. Annual leave must be planned and used within the year. Unused days expire and do not carry over to the next year. Tracking and planning your remaining days is your own responsibility.

Before You Take Leave

Before requesting or starting leave, take care of these:

  • Arrange coverage. Identify who will cover your responsibilities while you're away.
  • Set your status. At the start of your leave, set your Slack/MS Teams status to on-leave and mark your return date.
  • Avoid overlap. Make sure your leave dates don't clash with your teammates'.
  • Plan ahead. Plan your leave request at least 1 month in advance.
  • Get approval first. Don't finalize any plans before getting your manager's approval on the dates. Remember: your manager's approval is the deciding factor in any leave decision.

On-Leave Communication

Two things to set before your leave starts, so people know you're out and when you'll be back.

1. Email auto-reply. Turn on an out-of-office auto-reply for the full duration of your leave. Use this template:

Subject: Out of Office

Hello,

Thank you for your email. I am currently on leave and will not be
checking my inbox. I will return on <return date> and will respond to
your message then.

For anything urgent that cannot wait, please contact <colleague name>
at <colleague email>.

Thank you for your understanding.

Best regards,
<your name>

Fill in your actual return date, the colleague covering for you, and their email before enabling it.

2. Slack / MS Teams status. Set your status to on-leave with the 🌴 emoji, and always include your return date in the status text so people don't have to ask.

  • Status text: On leave, back on <return date>
  • Set the status to clear automatically on your return date.

Sick Leave

  • 5 days per year, paid.
  • Requires an official medical report (rapor).

Public Holidays

  • Official public holidays are paid.
  • They are not deducted from your annual leave entitlement.

Birthday Leave

  • 1 day off for your birthday.
  • It can only be used on your birthday itself - it cannot be taken on a different day or carried over.

Wellness Leave

  • Female contractors are entitled to 1 day per month of wellness leave, for women's health and well-being.
  • This is a single-day leave only - it is not maternity or parental leave.

Overtime

  • No overtime payment. Work is measured by outcomes, not hours (see Remote Work).

Operations

Day-to-day procedures: how we handle leave, handovers, issue tracking, and internal documentation.

Blame-Free Postmortem

When something goes wrong, the goal is to understand the system — not to find someone to blame.

Reporting a mistake — even a big one — will never be held against you. What matters is that it surfaces early. If people fear punishment, problems get hidden, minimized, or reported late. That makes everything worse.

The question is never "who did this?" — it's "how did our system allow this to happen?"

A postmortem is written after every customer-impacting incident. It is a learning tool, not a punishment.

Language is impersonal. Write "the migration was skipped during deploy" — not "X skipped the migration." The person is never the root cause; the system is.

Every postmortem follows this template:

Section What to write
Summary One paragraph. What happened and what was the impact.
Impact How many tenants affected, for how long.
Timeline Chronological events — detection, response, resolution.
Root Cause The underlying system failure, not the surface symptom.
What went well Things that limited the damage or helped recovery.
What went badly Things that made it worse or delayed the response.
Actions Concrete next steps, each with an owner and a due date.

Root cause: use 5 Whys. Don't stop at the first technical answer. Ask "why" five times until you reach the systemic or process failure underneath.

Postmortems are public — posted in Linear or the wiki, visible to the whole team. They are not stored away. An action without an owner and a deadline does not count. Actions are tracked like normal work and followed up until closed.

Incident reports go on iDoc. Every customer-impacting incident gets a postmortem and a published incident report on iDoc under the relevant section. A postmortem in a Slack thread or in someone's head is not a postmortem.

Over time this builds a searchable record: what broke, why, and what changed as a result. When the same class of problem resurfaces — and it will — the record is there.

Security exception

If the incident involves a security breach, sensitive technical details may be restricted to a small group. The lessons learned are still shared with the full team.

The distinction that matters

Blame-free postmortems apply to mistakes and incidents — things that happened unintentionally. Deliberately concealing a known problem is a different thing entirely and remains a red line.

Incident Response / On-Call

Production incidents require a different reflex from normal work: speed, clear role separation, and controlled customer communication. In our multi-tenant and self-hosted setup, a single incident can affect many customers at once.

Priorities during an incident — in order:

  1. Mitigate — stop the bleeding. Customers don't wait while you debug.
  2. Communicate — notify the right people, including customers per the SLA.
  3. Root cause — investigate after the situation is stabilized.

Severity levels:

Level Definition Response
S1 Full outage or multiple tenants impacted Immediate, all hands
S2 Partial impact, degraded service Within 30 minutes
S3 Minor impact, workaround exists Within 2 hours

Roles during an incident:

Every incident has a single Incident Commander. The commander owns communication and coordination — they do not do technical work during the incident. Engineers handle the technical response. Roles do not mix.

  • Commander opens the incident channel, keeps it updated, and decides when to escalate.
  • Commander owns customer communication: what to say, when, and in what tone.
  • Engineers report status to the commander, not directly to customers.

On-call rotation:

On-call is distributed fairly across the team. After an on-call shift that involved a significant incident, rest or compensation time is documented and honored.

If you're overwhelmed

Escalate immediately. There is no expectation that you carry it alone.

Emergency Leave

If you have an emergency and can't make it to work:

  1. Notify your direct manager as soon as possible — a message is enough to start.
  2. Submit a formal leave request the same business day, or the next morning if the emergency happens after hours.
  3. If you're mid-task on something critical, drop a quick note in the relevant channel so the team isn't blocked.
  4. If possible, post in #leave-notification so the team knows you're out.

No need to over-explain. Just keep your manager in the loop.

Job Handover

When someone is leaving or transitioning roles, a proper handover is required. The timeline is set by your manager based on role complexity.

A complete handover includes:

  • All active tasks documented and reassigned
  • Relevant credentials and access transferred securely through proper channels
  • A walkthrough session with the incoming person (where applicable)
  • Key context written down — not kept in your head
  • RACI matrix updated to reflect ownership and accountability changes

The outgoing person owns the handover. The manager ensures it's complete before the last day.

There is no "I'll send docs later." The handover is done before you leave.

Issue Tracking

We use Linear. Every issue must be logged — not kept in Slack threads or someone's memory.

When opening an issue:

Field What to do
Title Be specific. "Bug" is not a title.
Priority Set it honestly. Not everything is urgent.
Description Context, steps to reproduce, expected vs. actual behavior.
Assignee Assign if you know who owns it. Otherwise, leave for triage.

Priority levels:

Level Meaning
Urgent Blocking someone right now
High Must be resolved this sprint
Medium Important but not on fire
Low Nice to have

If you find something broken and there's no issue for it — open one. Don't assume someone else will.

Engineering Discipline

Writing code is one part of the job. A task is done when:

  • Status is updated. Your Linear ticket reflects where you actually are. "Done" means done and verified — not "I pushed the branch."
  • Story points are set. Every ticket has an estimate before work starts.
  • TDD is written. If the work warrants a technical design document, it should be ready approximately one sprint before implementation begins. Writing a TDD months in advance is not expected — analysis done too early can become stale before the work even starts.
  • Ticket exists. If the work isn't in Linear, it doesn't exist for the team.

A merged PR with no ticket update is not done. Update the ticket.

Small Tasks

If a task takes less than 30 minutes, handle it in the next available slot - don't queue it behind long-running work.

Small tasks accumulate. A 10-minute fix that waits three days becomes a blocker and a frustration for someone else.

If you're in a focused block on something critical, log it in Linear and return to it immediately after.

Time Tracking

We use Clockify for personal time tracking.

This is for you — not oversight. The goal: after a month, you should be able to answer — "I spent X hours on feature work, Y on support, Z on meetings." If you can't, you have no visibility into your own work.

  • Log as you go, not in a weekly bulk session.
  • Review your own data monthly.

Mandatory Internal Documents

RACI Matrix

Every project must have a RACI matrix before work starts. No exceptions.

A RACI defines:

Letter Role Meaning
R Responsible Does the work
A Accountable Owns the outcome — the one who answers if it goes wrong
C Consulted Provides input before decisions
I Informed Kept in the loop after decisions

Rules: - There can only be one A per task. Shared accountability is no accountability. - If roles shift mid-project, update the RACI immediately. - If a project doesn't have a RACI, stop and create one.

The RACI is a living document, not a one-time checkbox.

AI

AI is part of how we work, but using it well comes with rules. This section covers how we use AI tools, whose account is for what, and what we owe a piece of AI output before it leaves our hands.

Ownership & Review

AI is a tool in our way of working, but the output it produces is yours. The responsibility for anything you generate with an AI tool rests entirely with you, the person who shipped it.

Nothing leaves your hands without a human review first. This applies to every kind of output, not just code:

  • Documents and specs
  • Messages (to customers, to the team, anywhere)
  • Code and configuration
  • Anything else produced with AI assistance

You can't blame the tool. If you share it, you own it - its accuracy, its tone, and its consequences. Read it, verify it, and make it yours before it goes out.

Personal vs Company AI

Keep personal and company AI separate, in both directions.

  • Don't use personal AI tools or accounts for company work. Company work goes through company-provided AI tools and accounts, not your personal subscriptions.
  • Don't use the company AI account for personal purposes. It's provisioned for work; its usage and data belong to the company.

Refining AI Output

Don't ship raw AI text. What an AI produces is a first draft, not a final one. Rewrite it in your own words - simplify it, cut the filler, and match our tone. Text pasted verbatim from an AI is easy to spot, and it isn't yours until you've reworked it.

Security

Security is everyone's responsibility. These are the baseline expectations for how we handle company devices, software, credentials, and data. A breach of company or customer data is a red line; the rules here exist to keep us well clear of one.

Acceptable Use

  • Company devices are for company work. Keep personal use to a minimum, and off anything that could put company data or the device at risk.
  • No unlicensed or unapproved software. Don't install pirated, cracked, or unlicensed software. If you need a tool, request it through the proper channel rather than sourcing it yourself.
  • Don't mix personal and company accounts. Use company accounts for company work (see Personal vs Company AI for the same rule applied to AI tools).

Device Security

  • Enable full-disk encryption on every device that touches company data.
  • Lock your screen when you step away, and set it to lock automatically.
  • Keep your OS and software up to date. Security patches are not optional.
  • Don't leave devices unattended in public spaces.

Security Principles

  • Least privilege. Request only the access you need, and give up access you no longer use.
  • Be alert to phishing. Verify unexpected requests for credentials, money, or data through a second channel before acting.
  • Report anything suspicious immediately. A lost device, a leaked credential, a phishing click - surface it early. Reporting a security concern is never held against you (see Blame-Free Culture).
  • Don't share company or customer data without authorization, in any tool or channel.

Password Management

All Appcircle-related credentials — passwords, API keys, certificates, SSH keys, and any other secrets — must be stored in the company password manager.

Storing or sharing work credentials anywhere else (Slack, email, notes apps, local files, spreadsheets) is not allowed.

This applies to every team member, without exception. If a credential exists and is not in the password manager, move it there.

Setup instructions: Password Manager

People

Performance, disciplinary process, and company events.

Performance Evaluation

Evaluations happen annually, but plans are tracked every quarter.

How it works

  1. Goal setting — At the start of the year, you and your manager agree on your goals.
  2. Quarterly check-ins — Every quarter, your manager reviews progress with you. No surprises at review time.
  3. Annual review — A formal assessment combining manager evaluation and self-assessment.

For managers

Your rating is tied to your team's performance. A manager whose team struggles cannot receive the highest rating — because enabling the team to succeed is the job.

This is intentional. It keeps accountability at the right level.

Transparency

  • If you disagree with a review outcome, raise it. There is a process for that.
  • Review criteria are shared in advance — not revealed after the fact.
  • Compensation implications are tied to the annual review.

Performance Criteria

These are the criteria used to evaluate individual performance during reviews.

Criterion What we look at
Works to Full Potential Consistently delivers at the level their role and skills allow. Not coasting.
Quality of Work Output is accurate, well-considered, and meets the expected standard.
Work Consistency Reliable day to day — not strong one week, absent the next.
Communication Clear, timely, and appropriate across written and spoken channels.
Independent Work Can drive tasks forward without constant direction or follow-up.
Takes Initiative Spots problems and acts on them without waiting to be asked.
Group Work Contributes effectively in team settings; supports others' success.
Productivity Gets things done within reasonable time and scope.
Creativity Brings fresh thinking to problems; doesn't default to the obvious answer.
Honesty Straightforward about progress, blockers, and mistakes.
Integrity Does the right thing even when no one is watching.
Coworker Relations Builds trust with teammates; handles conflict constructively.
Client Relations Professional, responsive, and solution-focused with customers.
Technical Skills Maintains and grows the depth of knowledge the role requires.
Dependability Follows through on commitments; can be counted on.
Punctuality Respects deadlines and scheduled meetings.
Attendance Present and available as expected; absences handled properly.

Warnings & Disciplinary Process

We prefer direct conversations before anything formal. If something's off, your manager should tell you — and you should be able to hear it.

When a pattern persists or something serious happens:

Step 1 — Verbal warning A direct, clear conversation. The issue is named specifically. No written record at this stage.

Step 2 — Written warning If the behavior continues. This goes on record.

Step 3 — Termination If the behavior doesn't change after a written warning.

Warnings are issued by the direct manager.

Job Titles on Social Media

Your job title as it appears on public profiles - Social Media (e.g. LinkedIn) - is a form of representing Appcircle. It should reflect your actual role, not a title you'd prefer to hold.

  • New team members do not set an Appcircle title on social media on their own. Use the title your manager confirms.
  • Changing your title later requires written approval from your manager first (a Slack or email confirmation is enough). Update the profile only after you have it.
  • The title should match your role internally. If a promotion or role change warrants a new title, your manager confirms it - then you update it.

This isn't about control. Public titles shape how customers, candidates, and partners read the team, so they need to stay accurate and consistent.

Company Events

Attendance is expected unless you have a valid reason.

If you can't attend:

  • Let your manager know in advance.
  • Don't just not show up. That's not how we operate here.

Events exist to build the team — not to check a box. Show up with that mindset.

Some events will require travel or a specific time commitment. Details will be communicated well in advance.