Atlassian Engineer

Mission: "Unleash the potential of every team." — Atlassian

Leadership Philosophy: "The business of business is improving the state of the world." — Mike Cannon-Brookes

Engineering Ethos: "Be the change you seek." — Atlassian Values

§1 · Quick Start

§1.1 · One-Minute Setup

Activate this skill for Atlassian-style engineering:

# Add to CLAUDE.md
echo "Apply atlassian-engineer: Team Anywhere async culture, DevOps toolchain mastery, 
      agile-at-scale practices, open by default documentation." >> CLAUDE.md

§1.2 · Essential Context

§1.3 · Core Capabilities

1. Team Anywhere Culture — Async-first collaboration, intentional gatherings, timezone-aware teaming
2. DevOps Toolchain Mastery — Jira, Confluence, Bitbucket integrated workflows
3. Agile-at-Scale — Scrum, Kanban, SAFe via Jira Align, portfolio management
4. Open by Default — Documentation-first, transparent decision-making, shared context
5. Platform Extensibility — 5,000+ Marketplace apps, REST APIs, Forge apps

§2 · Atlassian Engineering Culture

§2.1 · The Sydney Genesis (2002)

University of New South Wales Origins Mike Cannon-Brookes and Scott Farquhar met at UNSW and founded Atlassian with a $10,000 credit card debt. Their vision: build affordable, self-serve software for developers.

Key Early Decisions:

• No traditional sales team (product-led growth)
• Self-serve signups with transparent pricing
• Build for developers first, expand outward
• Focus on Jira (issue tracking) as the wedge product

The 1-1-1 Model (Pioneered by Atlassian):

§2.2 · Team Anywhere: Distributed by Design

The Remote-First Revolution: Atlassian's "Team Anywhere" policy, launched in 2020, is now the default operating model:

Key Statistics (2024):

• 92% of employees say the policy helps them do their best work
• 91% cite flexibility as a retention reason
• 10,000+ unique locations where work happens
• 20% increase in offer acceptance rates
• 2x increase in candidates per role

Four Pillars of Team Anywhere:

The 90-Day Rule:

• Work from any supported country for up to 90 days/year without tax implications
• 13 countries with legal entities (US, Australia, UK, Germany, India, Japan, etc.)
• Relocation supported within entity countries

§2.3 · Atlassian Values in Practice

The Five Core Values:

1. Open Company, No Bullshit — Transparency in decisions, feedback, and failure
2. Build with Heart and Balance — Sustainable pace, avoiding burnout
3. Don't #@!% the Customer — Customer obsession in every decision
4. Play as a Team — Cross-functional collaboration over silos
5. Be the Change You Seek — Individual ownership of improvement

Engineering Manifestations:

Value_Application:
  Open_Company:
    - Default Slack channels: public
    - Confluence spaces: open by default
    - Post-mortems: publicly shared
    
  Build_with_Heart:
    - No meeting Wednesdays
    - Focus time protection
    - Workload sustainability metrics
    
  Customer_First:
    - Customer advisory boards
    - Dogfooding all products
    - Support rotation for engineers
    
  Team_Play:
    - Shared OKRs across functions
    - Joint planning sessions
    - Collective ownership of incidents
    
  Be_the_Change:
    - 20% time for innovation
    - Quarterly ShipIt hackathons
    - Internal mobility encouraged

§3 · The DevOps Toolchain

§3.1 · Jira: The Work Management Platform

Market Dominance:

• 65%+ market share in issue tracking
• 62% of agile teams use Jira (State of Agile Report)
• 83% of Fortune 500 companies
• 100M+ monthly active users

Product Suite:

Core Concepts:

Jira_Fundamentals:
  Issue: The basic unit of work (Story, Bug, Task, Epic)
  Project: Collection of issues with shared configuration
  Workflow: Status transitions (To Do → In Progress → Done)
  Board: Visual representation (Scrum or Kanban)
  Sprint: Time-boxed iteration (1-4 weeks)
  Epic: Large body of work spanning multiple sprints

Agile Workflow Example:

Product Backlog → Sprint Planning → Active Sprint → Review → Retro
      ↑                                                    |
      └──────────────── Backlog Refinement ←───────────────┘

§3.2 · Confluence: The Team Workspace

Purpose: Knowledge management, documentation, and team collaboration.

Key Features:

Documentation-First Culture:

# Decision Log Template

## Status: PROPOSED | APPROVED | REJECTED | SUPERSEDED

## Context
What is the issue we're seeing?

## Decision
What are we doing about it?

## Consequences
What becomes easier/harder?

## Alternatives Considered
- Option A: ...
- Option B: ...

§3.3 · Bitbucket: Code Collaboration

Overview: Git-based source control with native Jira integration.

Differentiation:

Bitbucket Pipelines (CI/CD):

# bitbucket-pipelines.yml
image: node:18

pipelines:
  default:
    - step:
        name: Build and Test
        script:
          - npm ci
          - npm run lint
          - npm run test:coverage
          - npm run build
        artifacts:
          - dist/**
    
    - step:
        name: Deploy to Staging
        deployment: staging
        trigger: manual
        script:
          - npm run deploy:staging
    
    - step:
        name: Security Scan
        script:
          - pipe: atlassian/snyk-scan:0.5.0
          - pipe: atlassian/git-secrets-scan:0.5.1

§3.4 · The Integrated DevOps Loop

┌─────────────────────────────────────────────────────────────────┐
│                    PLAN (Jira Software)                         │
│  Backlog → Sprint Planning → Story Estimation → Roadmap         │
└──────────────────────────┬──────────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────────┐
│                    CODE (Bitbucket)                             │
│  Branch → Commit → Pull Request → Code Review → Merge           │
│  ↓ Issue keys in commits auto-link to Jira                      │
└──────────────────────────┬──────────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────────┐
│                    BUILD (Bitbucket Pipelines)                  │
│  Compile → Unit Tests → Integration Tests → Security Scan       │
└──────────────────────────┬──────────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────────┐
│                    DEPLOY (Jira Service Management)             │
│  Change Request → Approval → Deployment → Verification          │
└──────────────────────────┬──────────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────────┐
│                    OPERATE & LEARN                              │
│  Monitoring → Incidents (JSM) → Post-mortems (Confluence)       │
└─────────────────────────────────────────────────────────────────┘

§4 · Agile at Scale

§4.1 · Scrum Framework

Roles:

Ceremonies:

Sprint_Cycle:
  Sprint_Planning: 
    duration: 2-4 hours (2-week sprint)
    output: Sprint backlog, sprint goal
    tool: Jira Sprint creation
    
  Daily_Scrum:
    duration: 15 minutes
    format: What did I do? What will I do? Blockers?
    tool: Jira board, Slack async updates
    
  Sprint_Review:
    duration: 1-2 hours
    focus: Demo working software, gather feedback
    tool: Confluence demo notes
    
  Retrospective:
    duration: 1 hour
    format: What went well? What to improve? Actions?
    tool: Confluence retrospective template

§4.2 · SAFe with Jira Align

Enterprise Agile Framework:

Portfolio Level (Strategic Themes)
    ↓
Program Level (ART - Agile Release Trains)
    ↓
Team Level (Scrum/Kanban Teams)

Jira Align Concepts:

§4.3 · Metrics That Matter

Flow Metrics (Kanban):

Agile Health Metrics:

Sprint_Health:
  Commitment_Reliability: (Committed / Completed) * 100  # Target: 80-90%
  Velocity_Trend: Story points per sprint  # Look for consistency
  Escaped_Defects: Bugs found post-release  # Target: decreasing
  Happiness_Index: Team survey  # Target: > 7/10

§5 · Platform Extensibility

§5.1 · Atlassian Marketplace

Ecosystem Scale:

• 5,000+ apps and integrations
• 50,000+ Marketplace partners
• $1B+ in partner revenue

Top Categories:

§5.2 · Forge App Development

Atlassian's Cloud App Platform:

// manifest.yml
modules:
  jira:issuePanel:
    - key: issue-panel
      function: main
      title: My App
      icon: https://...
  
function:
  - key: main
    handler: index.run

app:
  id: ari:cloud:ecosystem::app/...
  name: my-forge-app

// src/index.jsx
import ForgeUI, { render, IssuePanel, Text } from '@forge/ui';

const App = () => {
  return (
    <IssuePanel>
      <Text>Hello from Atlassian Forge!</Text>
    </IssuePanel>
  );
};

export const run = render(<App />);

§5.3 · REST API Integration

Key APIs:

Example: Jira Issue Creation:

import requests

JIRA_URL = "https://your-domain.atlassian.net"
AUTH = ("email@company.com", "API_TOKEN")

issue_data = {
    "fields": {
        "project": {"key": "PROJ"},
        "summary": "Implement OAuth2 authentication",
        "description": "Add OAuth2 support for API access",
        "issuetype": {"name": "Story"},
        "priority": {"name": "High"},
        "assignee": {"id": "5b10ac8d82e05b22cc7d4ef5"},
        "labels": ["security", "api"],
        "customfield_10016": 8  # Story points
    }
}

response = requests.post(
    f"{JIRA_URL}/rest/api/3/issue",
    json=issue_data,
    auth=AUTH
)
issue_key = response.json()["key"]  # PROJ-123

§6 · Example Scenarios

§6.1 · Project Management: Sprint Planning and Execution

Context: Lead a 2-week sprint for a feature delivery team using Jira Software.

Atlassian-Engineer Approach:

Phase 1: Backlog Refinement (Day -2)

Backlog_Health_Check:
  Ready_Criteria:
    - Clear acceptance criteria
    - Story points estimated
    - Dependencies identified
    - Designs attached
  
  Estimation:
    method: Planning Poker (Story Points: 1,2,3,5,8,13)
    baseline: 1 point = ~1/2 day of work
    velocity: Team averages 40 points/sprint

Phase 2: Sprint Planning (Day 0)

# Sprint 23 Planning

## Sprint Goal
Enable customers to export reports in PDF format

## Capacity
- Team: 5 developers
- Days: 10 (minus 1 day for holiday)
- Total capacity: 45 person-days
- Buffer: 20% (9 days)
- Available: 36 days equivalent

## Committed Stories
| Key | Summary | Points | Owner |
|-----|---------|--------|-------|
| PROJ-145 | PDF export backend API | 8 | Sarah |
| PROJ-146 | PDF template engine | 5 | Mike |
| PROJ-147 | Frontend export button | 3 | Alex |
| PROJ-148 | PDF styling framework | 5 | Sarah |
| PROJ-149 | Export progress indicator | 3 | Mike |
| PROJ-150 | Error handling for exports | 3 | Alex |

**Total: 27 points** (Conservative for first sprint with new tech)

Phase 3: Daily Execution

Daily_Flow:
  Morning:
    - Review Jira board (To Do → In Progress → Review → Done)
    - Update issue status
    - Flag blockers in Slack #dev-updates
    
  Development:
    - Branch naming: PROJ-145-pdf-export-api
    - Commit format: "PROJ-145 Add PDF generation service"
    - PR requires: 2 approvals, green build, no conflicts
    
  Tracking:
    - Burndown chart review in standup
    - Flag issues > 2 days in same status
    - Update remaining estimates daily

Phase 4: Sprint Review

# Sprint 23 Review

## Demo
1. Navigate to Reports page
2. Click "Export as PDF"
3. Show progress indicator
4. Download and display generated PDF

## Feedback Captured
- Customer wants CSV export too (new backlog item)
- PDF formatting needs dark mode support
- Export should include charts

## Metrics
- Committed: 27 points
- Completed: 24 points (89% reliability)
- Escaped defects: 0
- Cycle time avg: 3.2 days

Phase 5: Retrospective

# Retrospective: Sprint 23

## What Went Well 🟢
- PDF generation library worked smoothly
- API design reviews caught issues early
- QA involvement from day 1

## What to Improve 🟡
- Underestimated styling complexity by 2 points
- Need better test data for large reports
- Documentation lagged behind code

## Action Items
1. [ ] Create shared test data fixture (Alex)
2. [ ] Update DoD to include doc update (Team)
3. [ ] Research PDF dark mode options (Sarah)

§6.2 · Documentation: Building a Team Knowledge Base

Context: Set up comprehensive documentation in Confluence for a microservices platform.

Atlassian-Engineer Approach:

Phase 1: Information Architecture

Confluence_Space_Structure:
  📁 Platform_Team_Space:
    
    📁 00-Getting-Started:
      - Onboarding Checklist
      - Local Development Setup
      - Team Charter
      
    📁 10-Architecture:
      - System Overview
      - Service Catalog
      - Data Flow Diagrams
      - Decision Records (ADRs)
      
    📁 20-Runbooks:
      - Deployment Procedures
      - Incident Response
      - Rollback Playbooks
      - Common Issues
      
    📁 30-APIs:
      - API Reference (OpenAPI)
      - Authentication Guide
      - Rate Limiting
      - Changelog
      
    📁 40-Operations:
      - Monitoring Dashboards
      - Alert Runbooks
      - Capacity Planning
      - Security Procedures

Phase 2: Template Standardization

# Runbook Template

## Overview
One-sentence description of this procedure.

## Prerequisites
- [ ] Access to X system
- [ ] Required permissions
- [ ] Tools installed

## Procedure
### Step 1: Title
```bash
# Commands with expected output
kubectl get pods -n production

Step 2: Title

Description and verification.

Rollback

If something goes wrong:

1. Step to revert
2. Verification command

Related

• Link to related runbook
• Link to monitoring dashboard
• Escalation contact

Changelog

**Phase 3: Living Documentation Workflow**
```yaml
Doc_as_Code:
  Creation:
    - New feature → Create design doc in Confluence
    - Architecture decision → Create ADR
    - Incident → Create/update runbook
    
  Review:
    - Technical docs: Peer review required
    - Runbooks: Test procedures before publishing
    - APIs: Auto-generate from OpenAPI specs
    
  Maintenance:
    - Quarterly doc health checks
    - Archive outdated pages
    - Update on-call handoff notes weekly

Phase 4: Integration with Development

# Pre-merge checklist includes documentation
Pull_Request_Template:
  - [ ] Code follows style guide
  - [ ] Tests added/updated
  - [ ] Documentation updated:
    - [ ] API docs (if applicable)
    - [ ] Runbooks (if operational change)
    - [ ] ADR (if architectural decision)
  - [ ] Confluence links added to ticket

§6.3 · CI/CD: Bitbucket Pipelines and Deployment Automation

Context: Design a complete CI/CD pipeline for a Node.js microservice deploying to Kubernetes.

Atlassian-Engineer Approach:

Phase 1: Repository Structure

service-api/
├── src/
├── tests/
│   ├── unit/
│   ├── integration/
│   └── e2e/
├── infrastructure/
│   ├── k8s/
│   │   ├── deployment.yaml
│   │   ├── service.yaml
│   │   └── hpa.yaml
│   └── terraform/
├── bitbucket-pipelines.yml
├── Dockerfile
└── package.json

Phase 2: Pipeline Configuration

# bitbucket-pipelines.yml
image: node:18

definitions:
  caches:
    node: ~/.npm
  
  services:
    docker:
      memory: 2048
  
  steps:
    - &build
      name: Build Application
      caches:
        - node
      script:
        - npm ci
        - npm run build
      artifacts:
        - dist/**
        - node_modules/**
    
    - &test-unit
      name: Unit Tests
      caches:
        - node
      script:
        - npm run test:unit -- --coverage
      artifacts:
        - coverage/**
    
    - &test-integration
      name: Integration Tests
      caches:
        - node
      services:
        - postgres
      script:
        - npm run test:integration
    
    - &security-scan
      name: Security Scan
      script:
        - pipe: atlassian/snyk-scan:0.5.0
          variables:
            SNYK_TOKEN: $SNYK_TOKEN
            LANGUAGE: "npm"
        - pipe: atlassian/git-secrets-scan:0.5.1
    
    - &docker-build
      name: Build Docker Image
      script:
        - export IMAGE_TAG=$BITBUCKET_COMMIT
        - docker build -t $DOCKER_REGISTRY/service-api:$IMAGE_TAG .
        - docker push $DOCKER_REGISTRY/service-api:$IMAGE_TAG

pipelines:
  default:
    - <<: *build
    - <<: *test-unit
    - <<: *security-scan
    - <<: *test-integration
    - <<: *docker-build
    - step:
        name: Deploy to Staging
        deployment: staging
        trigger: automatic
        script:
          - kubectl set image deployment/service-api 
              service-api=$DOCKER_REGISTRY/service-api:$BITBUCKET_COMMIT
          - kubectl rollout status deployment/service-api -n staging
    
    - step:
        name: E2E Tests
        deployment: staging
        trigger: manual
        script:
          - npm run test:e2e:staging

  branches:
    main:
      - <<: *build
      - <<: *test-unit
      - <<: *security-scan
      - <<: *test-integration
      - <<: *docker-build
      - step:
          name: Deploy to Production
          deployment: production
          trigger: manual
          script:
            - kubectl set image deployment/service-api 
                service-api=$DOCKER_REGISTRY/service-api:$BITBUCKET_COMMIT
            - kubectl rollout status deployment/service-api -n production
            - |
              curl -X POST $SLACK_WEBHOOK \
                -H 'Content-Type: application/json' \
                -d '{"text":"🚀 service-api deployed to production: '$BITBUCKET_COMMIT'"}'

Phase 3: Change Management Integration

Jira_Service_Management_Integration:
  Change_Request:
    - Pipeline creates CR for production deploys
    - Approval required from: Tech Lead, Product Owner
    - Risk assessment based on:
      - Files changed (config vs code)
      - Test coverage delta
      - Security scan results
  
  Deployment_Record:
    - Bitbucket deployment linked to Jira issue
    - Release notes auto-generated from commits
    - Rollback procedure attached

Phase 4: Monitoring and Alerting

Observability_Stack:
  Metrics:
    - Prometheus for collection
    - Grafana for dashboards
    - Jira board: SLO tracking
  
  Logging:
    - Structured JSON logs
    - Centralized in ELK stack
    - Correlation IDs across services
  
  Alerting:
    - PagerDuty for incidents
    - Jira Service Management for tracking
    - Slack for team notifications

§6.4 · Incident Management: Post-Mortem and Process Improvement

Context: A critical service experienced a 45-minute outage. Lead the post-mortem and process improvement.

Atlassian-Engineer Approach:

Phase 1: Immediate Response (T+0 to T+45min)

Incident_Response:
  Detection:
    - PagerDuty alert: "API latency > 2s"
    - Jira Service Management incident: INC-4521
  
  Assessment:
    - Severity: SEV-1 (Customer-facing outage)
    - Impact: 15% of requests failing
    - Blast radius: Payment processing service
  
  Mitigation:
    - 08:15 UTC: Rolled back deployment v2.4.1
    - 08:30 UTC: Service recovery confirmed
    - 08:45 UTC: Incident resolved

Phase 2: Post-Mortem Preparation (T+1 to T+24h)

# Post-Mortem: Payment API Outage (INC-4521)

## Summary
On 2024-03-15, the payment processing API experienced a 45-minute outage
due to a database connection pool exhaustion following a deployment.

## Timeline (UTC)
| Time | Event |
|------|-------|
| 07:55 | Deployment v2.4.1 began |
| 08:00 | Deployment completed |
| 08:05 | Latency alerts began firing |
| 08:10 | Error rate exceeded 5% |
| 08:15 | Rollback initiated |
| 08:30 | Service recovery confirmed |
| 08:45 | Incident resolved |

## Root Cause
The new feature in v2.4.1 added a database query in the hot path without
proper connection pool sizing. Each request held connections longer,
exhausting the pool of 20 connections under production load.

## Contributing Factors
1. Load testing didn't simulate realistic concurrent load
2. Database metrics not included in deployment dashboard
3. Connection pool alerts threshold too high

## Impact
- 45 minutes of degraded service
- ~500 failed payment attempts
- No data loss or financial impact

Phase 3: Action Items (Tracked in Jira)

Action_Items:
  Prevent_Recurrence:
    - key: INFRA-892
      summary: Increase DB connection pool to 50
      owner: platform-team
      priority: Critical
      due: 2024-03-18
    
    - key: INFRA-893
      summary: Add connection pool exhaustion alerts
      owner: sre-team
      priority: High
      due: 2024-03-22
    
  Detection:
    - key: MON-445
      summary: Include DB metrics in deploy dashboard
      owner: observability-team
      priority: Medium
      due: 2024-03-29
    
  Process:
    - key: ENG-201
      summary: Update load test scenarios for DB-heavy changes
      owner: qa-team
      priority: High
      due: 2024-03-25

Phase 4: Confluence Documentation

# Incident Runbook Update

## Database Connection Pool Exhaustion

### Symptoms
- API latency increasing gradually
- Error rate climbing after deployment
- Database metrics: active_connections at limit

### Diagnosis
```bash
# Check connection pool status
kubectl exec -it $POD -- curl localhost:8080/actuator/metrics/jdbc.connections.active

# View database connections
psql -c "SELECT count(*), state FROM pg_stat_activity GROUP BY state;"

Immediate Mitigation

1. Identify recent deployments: kubectl rollout history deployment/api
2. Rollback: kubectl rollout undo deployment/api
3. Verify recovery: Monitor error rate dashboard

Long-term Fix

• Review connection pool configuration
• Optimize queries in deployment
• Scale pool size if necessary

Related

• INC-4521 Post-Mortem
• Connection Pool Tuning Guide

---

### §6.5 · Team Collaboration: Async-First Workflow Design

**Context:** Design an async-first collaboration workflow for a distributed team spanning 4 time zones (Sydney, Bangalore, Berlin, San Francisco).

**Atlassian-Engineer Approach:**

**Phase 1: Team Topology Design**
```yaml
Team_Structure:
  Sydney_Hub:
    timezone: AEST (UTC+10)
    hours: 09:00 - 17:00
    focus: APAC customers, morning standups
    
  Bangalore_Hub:
    timezone: IST (UTC+5:30)
    hours: 09:00 - 17:00
    focus: Development, code review
    
  Berlin_Hub:
    timezone: CET (UTC+1)
    hours: 09:00 - 17:00
    focus: EMEA customers, architecture decisions
    
  San_Francisco_Hub:
    timezone: PST (UTC-8)
    hours: 09:00 - 17:00
    focus: Americas customers, product decisions

Overlap_Strategy:
  - Sydney/Bangalore: 4 hours (best for handoffs)
  - Bangalore/Berlin: 3.5 hours
  - Berlin/SF: 0 hours (async only)

Phase 2: Async Communication Protocol

# Team Communication Charter

## Response Time Expectations
| Channel | Urgent | Normal | FYI |
|---------|--------|--------|-----|
| PagerDuty | 15 min | - | - |
| Slack DM | 4 hours | 24 hours | - |
| Slack Channel | - | 24 hours | 48 hours |
| Confluence | - | - | 72 hours |
| Jira Comment | 24 hours | 48 hours | 72 hours |
| Email | 24 hours | 48 hours | - |
| Loom | - | 48 hours | 72 hours |

## Communication Guidelines

### Use Confluence For:
- Decisions that need to persist
- Documentation and runbooks
- Meeting notes and agendas
- Project status and roadmaps

### Use Jira For:
- Work tracking and assignments
- Technical discussions on issues
- Sprint planning and retrospectives
- Bug reports and feature requests

### Use Slack For:
- Quick questions (< 5 min answer)
- Real-time coordination during overlap
- Social connection and team bonding
- Incident response coordination

### Use Loom For:
- Demos and walkthroughs
- Complex explanations
- Weekly async standups
- Code review explanations

Phase 3: Meeting Minimization

Meeting_Policy:
  Required_Synchronous:
    - Sprint Planning (2 hours, bi-weekly)
    - Retrospective (1 hour, bi-weekly)
    - 1:1s (30 min, weekly)
    - Quarterly ITG (Intentional Together Gathering)
  
  Async_Replacements:
    - Daily Standup: Loom updates in #standups
    - Code Review: Bitbucket with detailed comments
    - Design Reviews: Confluence with async feedback
    - Status Updates: Weekly Confluence page

Meeting_Free_Wednesdays:
  purpose: Deep work focus time
  exception: P1 incidents only
  communication: Async only

Phase 4: Documentation-First Culture

Documentation_Workflow:
  Decision_Making:
    1. Create RFC in Confluence
    2. Share in relevant channels with 48h comment period
    3. Address feedback async
    4. Decision recorded in ADR (Architecture Decision Record)
    5. Only escalate to meeting if no consensus
  
  Knowledge_Sharing:
    - Weekly "Learning Log" entries
    - Post-incident writeups within 24h
    - Code review best practices documented
    - Onboarding improvements captured
  
  Transparency:
    - Open Confluence spaces by default
    - Public Slack channels for work topics
    - Shared metrics dashboards
    - Financials shared in town halls (recorded)

Phase 5: Connection Rituals

Intentional_Connection:
  Virtual:
    - #watercooler Slack channel
    - Monthly "Donut" pairings for 1:1s
    - Weekly "Show and Tell" Loom videos
    - Quarterly virtual game sessions
  
  In_Person_ITGs:
    frequency: Quarterly
    duration: 3-4 days
    location: Rotate between hubs
    activities:
      - Strategic planning
      - Team building
      - Skill workshops
      - Social events
    
  Measurement:
    - Team health surveys (quarterly)
    - Connection index tracked
    - Goal: 80%+ feel connected to team

§7 · Tool Reference

§7.1 · Atlassian Product Equivalents

§7.2 · Key Integrations

Development Workflow:

Bitbucket ←→ Jira (issue linking, smart commits)
Bitbucket ←→ Confluence (documentation in PRs)
Jira ←→ Confluence (roadmaps, requirements)
Jira ←→ Slack (notifications, slash commands)
Bitbucket Pipelines ←→ AWS/Azure/GCP (deployments)

Smart Commits Reference:

# Link commit to issue
PROJ-123 Add authentication middleware

# Link and transition
PROJ-123 #close #comment Fixed the login bug

# Link and time log
PROJ-123 #time 4h 30m Implemented OAuth flow

# Multiple actions
PROJ-123 #in-progress #time 2h #comment Starting implementation

§8 · Quality Checklist

§8.1 · Pre-Implementation Review

• Jira epic created with clear acceptance criteria
• Design documented in Confluence
• ADR created for architectural decisions
• Security review for sensitive data
• Rollback plan documented

§8.2 · Development Quality Gates

• Branch naming follows convention (PROJ-123-description)
• Smart commits link to Jira issues
• PR has meaningful description and linked issues
• Code review approved by 2+ engineers
• Tests passing in Bitbucket Pipelines
• Documentation updated in Confluence

§8.3 · Deployment Readiness

• Feature flags configured for gradual rollout
• Monitoring dashboards reviewed
• Runbook updated for new components
• Change request approved in JSM (for production)
• Rollback procedure tested
• Post-deploy verification checklist ready

§9 · Risk Framework

§9.1 · Risk Severity Matrix

§9.2 · Atlassian-Specific Risk Categories

§10 · Learning Resources

§10.1 · Essential Resources

§10.2 · Certifications

§11 · Quick Reference Cards

§11.1 · JQL (Jira Query Language) Quick Reference

-- Basic filters
project = PROJ AND status = "In Progress"
assignee = currentUser() AND sprint in openSprints()

-- Date ranges
created >= -7d AND created <= now()
updated >= startOfWeek() AND updated <= endOfWeek()

-- Complex queries
project = PROJ AND (priority = High OR priority = Critical)
  AND status changed DURING (-7d, now())
  AND component = "API"

-- Agile queries
sprint in openSprints() AND status != Done
sprint = 123 AND storyPoints > 0

-- Time tracking
timespent > 4h AND remainingEstimate > 0
worklogDate >= -7d AND worklogAuthor = currentUser()

§11.2 · Confluence Page Tree Template

📁 Space Home
├── 📄 Overview
├── 📁 Getting Started
│   ├── 📄 Quick Start Guide
│   └── 📄 FAQ
├── 📁 Documentation
│   ├── 📁 API Reference
│   ├── 📁 User Guides
│   └── 📁 Admin Guides
├── 📁 Decisions
│   └── 📄 ADR-001: [Title]
└── 📁 Meetings
    ├── 📄 Team Sync Notes
    └── 📄 Retrospectives

§11.3 · Team Anywhere Daily Checklist

□ Update Jira board (move completed work to Done)
□ Post async standup (or attend sync standup)
□ Check Confluence for updates on watched pages
□ Review PRs assigned for review
□ Respond to Slack threads requiring input
□ Update time tracking in Jira (if required)
□ Block off focus time for deep work

End of Skill Document

"Unleash the potential of every team." — Atlassian Mission

Workflow

Phase 1: Assessment

| Done | Phase completed | | Fail | Criteria not met |

• Gather requirements
• Analyze current state

Phase 2: Planning

| Done | Phase completed | | Fail | Criteria not met |

• Develop approach
• Set timeline

Phase 3: Execution

| Done | Phase completed | | Fail | Criteria not met |

• Implement solution
• Verify progress

Phase 4: Review

| Done | Phase completed | | Fail | Criteria not met |

• Validate outcomes
• Document lessons

Examples

Example 1: Standard Scenario

Input: Design and implement a atlassian engineer solution for a production system Output: Requirements Analysis → Architecture Design → Implementation → Testing → Deployment → Monitoring

Key considerations for atlassian-engineer:

• Scalability requirements
• Performance benchmarks
• Error handling and recovery
• Security considerations

Example 2: Edge Case

Input: Optimize existing atlassian engineer implementation to improve performance by 40% Output: Current State Analysis:

• Profiling results identifying bottlenecks
• Baseline metrics documented

Optimization Plan:

1. Algorithm improvement
2. Caching strategy
3. Parallelization

Expected improvement: 40-60% performance gain

§ 1.2 · Decision Framework — Weighted Criteria (0-100)

Composite Decision Rule:

• Score ≥85: Proceed
• Score 70-84: Conditional with monitoring
• Score <70: Stop and address issues

§ 1.3 · Thinking Patterns — Mental Models

Domain Benchmarks

Done Criteria

• All tasks completed per specification
• Quality standards met
• Stakeholder approval received

Fail Criteria

• Quality defects detected
• Requirements not met
• Timeline/budget overrun

Done Criteria

• All tasks completed per specification
• Quality standards met
• Stakeholder approval received

Fail Criteria

• Quality defects detected
• Requirements not met
• Timeline/budget overrun