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.

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:

Post in the relevant channel.
Describe: what you tried, what's happening, and what you need.
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:

Direct manager
Their manager or relevant lead
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.