DevOps Culture for Web Development Teams: A Practical Guide to Bridging the Dev-Ops Divide

The gap between writing code and running it in production has traditionally been the widest fault line in web development. Developers push features; operations teams push back with stability concerns. Releases become bottlenecks. Incidents become blame games. Deployments happen at midnight because no one trusts the process enough to ship during business hours.

DevOps culture exists to close that gap — not by adding another tool to the stack, but by fundamentally changing how web development teams think about ownership, feedback, and collaboration. The term itself is a portmanteau of “development” and “operations,” but the real substance is cultural: shared responsibility for the entire lifecycle of a web application, from the first line of code to the last log line in production.

This guide breaks down the core principles of DevOps culture, explains how web development teams can adopt them without a massive reorganization, and provides practical patterns — including pipeline configurations and monitoring scripts — that you can implement today. Whether your team ships a marketing site or a complex SaaS platform, the principles remain the same.

Why DevOps Culture Matters for Web Development Teams

Web development has unique pressures that make DevOps adoption both urgent and rewarding. Release cycles are short. User expectations are high. A broken deployment can mean lost revenue in minutes, not days. And the sheer variety of environments — staging, preview, production, edge — multiplies the surface area for configuration drift and deployment failures.

Teams that embrace DevOps culture report measurably better outcomes. According to the DORA (DevOps Research and Assessment) metrics framework, elite performers deploy code 973 times more frequently than low performers, with a change failure rate that is three times lower. For web teams specifically, this translates to faster feature delivery, fewer production incidents, and engineers who actually enjoy being on call because the systems they manage are observable and resilient.

The Cost of Ignoring DevOps

Without DevOps practices, web teams typically fall into predictable anti-patterns:

• The “it works on my machine” syndrome: Local development environments diverge from production, causing bugs that only surface after deployment. Containerization with Docker addresses this directly by ensuring environment parity.
• Manual deployment rituals: Senior developers become deployment gatekeepers, creating bottlenecks and single points of failure. Every release requires a specific person with tribal knowledge of the deploy process.
• Alert fatigue and blame culture: When monitoring is an afterthought, every incident triggers a scramble. Post-mortems become witch hunts rather than learning opportunities.
• Configuration snowflakes: Servers and environments are manually configured, making them impossible to reproduce. Infrastructure as Code with Terraform eliminates this class of problems entirely.

The compound effect is a team that ships slowly, breaks things frequently, and burns out its best engineers. DevOps culture is the antidote.

The Five Pillars of DevOps Culture

DevOps is not a role you hire for (though DevOps engineers exist). It is a set of cultural principles that reshape how teams operate. The CALMS framework — coined by Jez Humble and popularized by Atlassian — provides a useful structure for understanding these principles.

1. Culture: Shared Ownership Across the Lifecycle

The most important shift in DevOps is psychological: developers own what they build, all the way to production. This does not mean every frontend developer needs to become a Linux sysadmin. It means the team collectively owns the deployment pipeline, the monitoring dashboards, the incident response process, and the post-mortem culture.

Practically, shared ownership looks like this:

• Developers write deployment manifests alongside application code
• The person who writes a feature also writes the health check for that feature
• On-call rotations include developers, not just ops engineers
• Post-mortems are blameless and focus on systemic improvements

Teams practicing agile development in small teams often adopt shared ownership naturally, because there simply are not enough people to maintain a strict developer-operations divide. This is actually an advantage — small teams can move faster on cultural change than large organizations.

2. Automation: Eliminating Manual Toil

Every manual step in a deployment pipeline is a source of error and delay. DevOps culture prioritizes automating everything that can be automated: builds, tests, deployments, infrastructure provisioning, security scans, and compliance checks.

The goal is not automation for its own sake — it is freeing human brainpower for problems that actually require human judgment. A modern CI/CD pipeline can run hundreds of checks in parallel, deploy to staging automatically, and promote to production with a single approval click. The alternative — a developer manually running tests, building artifacts, SSHing into servers, and crossing their fingers — is both slower and riskier.

3. Lean: Reducing Waste and Batch Size

Lean thinking, borrowed from manufacturing, asks a simple question: which steps in our process actually deliver value, and which are pure waste? In web development, common sources of waste include:

• Waiting for approvals that could be automated (code review bots, automated security scans)
• Large batch deployments that bundle dozens of changes (making rollbacks painful)
• Handoffs between teams that could be eliminated with self-service tools
• Meetings that could be replaced by dashboards and asynchronous status updates

The lean principle pushes teams toward smaller, more frequent deployments. Instead of shipping a two-week sprint’s worth of changes in one big release, ship each change independently. This reduces risk, simplifies debugging, and gives you faster feedback from real users.

4. Measurement: Data-Driven Decision Making

You cannot improve what you do not measure. DevOps culture emphasizes four key metrics, known as the DORA metrics:

• Deployment frequency: How often your team ships to production. Elite teams deploy multiple times per day.
• Lead time for changes: The time from code commit to running in production. Elite teams achieve less than one hour.
• Change failure rate: The percentage of deployments that cause an incident. Elite teams stay below 5%.
• Mean time to recover (MTTR): How quickly you restore service after an incident. Elite teams recover in under one hour.

These metrics matter because they are outcome-oriented. They measure what users and the business actually care about — speed and stability — rather than vanity metrics like lines of code or number of commits. Teams that track these metrics consistently find that speed and stability are not trade-offs; they reinforce each other.

5. Sharing: Breaking Down Knowledge Silos

The final pillar addresses the most insidious problem in web teams: knowledge silos. When only one person understands the deployment process, or only the ops team knows how to read the monitoring dashboards, the team is fragile. DevOps culture promotes radical sharing:

• Runbooks for every service, written by the team that builds it
• Internal tech talks and pair programming sessions across disciplines
• Shared dashboards that everyone — including product managers — can read
• Documentation as code, versioned alongside the application

Effective remote team collaboration tools play a critical role here, especially for distributed web teams. Shared dashboards, incident channels, and collaborative runbooks ensure that knowledge does not evaporate when someone goes on vacation or leaves the company.

Implementing DevOps: A Practical Roadmap for Web Teams

Cultural change does not happen in a sprint. The following roadmap breaks DevOps adoption into phases that build on each other, starting with the highest-impact, lowest-risk changes.

Phase 1: Version Control Everything

If your infrastructure, configuration, and deployment scripts are not in version control, start there. This includes:

• Application code (obviously)
• Infrastructure definitions (Terraform, CloudFormation, Pulumi)
• CI/CD pipeline configurations
• Monitoring and alerting rules
• Database migration scripts
• Environment-specific configuration (using secrets management, not hardcoded values)

The principle is simple: if a disaster destroys your servers, you should be able to rebuild everything from your Git repository. Nothing should exist only in someone’s head or in a manually configured server.

Phase 2: Build a Reliable CI/CD Pipeline

A CI/CD pipeline is the backbone of DevOps automation. For web development teams, a well-designed pipeline typically includes these stages: lint and format checks, unit tests, integration tests, security scanning, build artifact creation, staging deployment, end-to-end tests, and production deployment.

Here is a practical GitHub Actions pipeline configuration for a typical web application that demonstrates these stages:

# .github/workflows/deploy.yml
# Full CI/CD pipeline for web application deployment
# Triggers on push to main and pull requests

name: Web App CI/CD Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

env:
  NODE_VERSION: '20'
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  quality-checks:
    name: Code Quality & Tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Lint check
        run: npm run lint

      - name: Type check
        run: npm run typecheck

      - name: Unit tests with coverage
        run: npm run test:coverage
        env:
          CI: true

      - name: Upload coverage report
        uses: actions/upload-artifact@v4
        with:
          name: coverage-report
          path: coverage/

  security-scan:
    name: Security Analysis
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run dependency audit
        run: npm audit --audit-level=high

      - name: SAST scan with Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: p/owasp-top-ten

      - name: Check for secrets
        uses: trufflesecurity/trufflehog@main
        with:
          extra_args: --only-verified

  build-and-push:
    name: Build & Push Container Image
    needs: [quality-checks, security-scan]
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    outputs:
      image-tag: ${{ steps.meta.outputs.tags }}
    steps:
      - uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Login to Container Registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Extract metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: |
            type=sha,prefix=
            type=raw,value=latest

      - name: Build and push image
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

  deploy-staging:
    name: Deploy to Staging
    needs: build-and-push
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/checkout@v4

      - name: Deploy to staging cluster
        run: |
          kubectl set image deployment/web-app \
            web-app=${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} \
            --namespace=staging
          kubectl rollout status deployment/web-app \
            --namespace=staging --timeout=300s

      - name: Run smoke tests
        run: |
          npm run test:e2e -- --base-url=${{ vars.STAGING_URL }}

      - name: Notify team on failure
        if: failure()
        run: |
          curl -X POST "${{ secrets.SLACK_WEBHOOK }}" \
            -H 'Content-Type: application/json' \
            -d '{"text":"⚠️ Staging deployment failed for commit ${{ github.sha }}"}'

  deploy-production:
    name: Deploy to Production
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4

      - name: Deploy with canary rollout
        run: |
          # Deploy to 10% of traffic first
          kubectl set image deployment/web-app-canary \
            web-app=${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} \
            --namespace=production

          # Wait and check error rates
          sleep 120
          ERROR_RATE=$(curl -s "${{ vars.PROMETHEUS_URL }}/api/v1/query" \
            --data-urlencode 'query=rate(http_requests_total{status=~"5.."}[2m]) / rate(http_requests_total[2m]) * 100' \
            | jq '.data.result[0].value[1] // "0"' -r)

          if (( $(echo "$ERROR_RATE > 2.0" | bc -l) )); then
            echo "Error rate ${ERROR_RATE}% exceeds threshold. Rolling back."
            kubectl rollout undo deployment/web-app-canary --namespace=production
            exit 1
          fi

          # Promote to full deployment
          kubectl set image deployment/web-app \
            web-app=${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} \
            --namespace=production
          kubectl rollout status deployment/web-app \
            --namespace=production --timeout=600s

This pipeline demonstrates several DevOps principles in action: automated quality gates, security scanning integrated into the workflow, container-based deployments for environment consistency, canary rollouts to minimize blast radius, and automated rollback when error thresholds are breached. Teams already using Kubernetes for container orchestration will recognize the deployment patterns — the key insight is that these patterns work at any scale, from a two-person startup to a hundred-person engineering organization.

Phase 3: Implement Observability From Day One

Monitoring is not something you bolt on after a production incident scares the team into action. In DevOps culture, observability is a first-class concern, designed into the application from the start. The three pillars of observability are:

• Metrics: Numerical measurements collected at regular intervals (request latency, error rates, CPU usage, memory consumption)
• Logs: Structured event records that tell you what happened and when
• Traces: End-to-end request flows across services, essential for debugging microservices architectures

The following Python script demonstrates a practical health monitoring and alerting system that web teams can adapt for their own services:

#!/usr/bin/env python3
"""
service_monitor.py — Health monitoring and alerting for web services.
Checks endpoint availability, response time, SSL certificate expiry,
and sends alerts via Slack and PagerDuty when thresholds are breached.

Usage:
    python service_monitor.py --config services.yaml
    Run via cron every 60 seconds or as a persistent daemon.
"""

import time
import ssl
import socket
import json
import logging
from datetime import datetime, timezone
from dataclasses import dataclass, field
from typing import Optional
from urllib.request import urlopen, Request
from urllib.error import URLError, HTTPError
from urllib.parse import urlencode

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s [%(levelname)s] %(message)s",
    datefmt="%Y-%m-%dT%H:%M:%S%z",
)
logger = logging.getLogger("service_monitor")

# --- Configuration ---

@dataclass
class ServiceConfig:
    name: str
    url: str
    method: str = "GET"
    expected_status: int = 200
    timeout_seconds: float = 10.0
    latency_warn_ms: float = 500.0
    latency_critical_ms: float = 2000.0
    ssl_expiry_warn_days: int = 30
    check_interval_seconds: int = 60
    consecutive_failures_alert: int = 3

@dataclass
class AlertState:
    consecutive_failures: int = 0
    last_alert_time: Optional[float] = None
    is_degraded: bool = False
    latency_history: list = field(default_factory=list)

# --- Health Check Engine ---

@dataclass
class CheckResult:
    service: str
    healthy: bool
    status_code: Optional[int]
    latency_ms: float
    ssl_days_remaining: Optional[int]
    error: Optional[str] = None
    timestamp: str = field(
        default_factory=lambda: datetime.now(timezone.utc).isoformat()
    )

def check_endpoint(config: ServiceConfig) -> CheckResult:
    """Perform HTTP health check and measure response time."""
    start = time.monotonic()
    try:
        req = Request(config.url, method=config.method)
        req.add_header("User-Agent", "ServiceMonitor/1.0")
        with urlopen(req, timeout=config.timeout_seconds) as resp:
            status = resp.status
            latency = (time.monotonic() - start) * 1000

        ssl_days = check_ssl_expiry(config.url) if config.url.startswith("https") else None

        return CheckResult(
            service=config.name,
            healthy=(status == config.expected_status),
            status_code=status,
            latency_ms=round(latency, 2),
            ssl_days_remaining=ssl_days,
        )
    except HTTPError as e:
        latency = (time.monotonic() - start) * 1000
        return CheckResult(
            service=config.name,
            healthy=False,
            status_code=e.code,
            latency_ms=round(latency, 2),
            ssl_days_remaining=None,
            error=f"HTTP {e.code}: {e.reason}",
        )
    except (URLError, TimeoutError, OSError) as e:
        latency = (time.monotonic() - start) * 1000
        return CheckResult(
            service=config.name,
            healthy=False,
            status_code=None,
            latency_ms=round(latency, 2),
            ssl_days_remaining=None,
            error=str(e),
        )

def check_ssl_expiry(url: str) -> Optional[int]:
    """Check SSL certificate expiration date."""
    try:
        hostname = url.split("//")[1].split("/")[0].split(":")[0]
        ctx = ssl.create_default_context()
        with ctx.wrap_socket(socket.socket(), server_hostname=hostname) as s:
            s.settimeout(5.0)
            s.connect((hostname, 443))
            cert = s.getpeercert()
        expiry = datetime.strptime(cert["notAfter"], "%b %d %H:%M:%S %Y %Z")
        return (expiry - datetime.utcnow()).days
    except Exception:
        return None

# --- Alerting ---

def evaluate_and_alert(
    result: CheckResult, config: ServiceConfig, state: AlertState
) -> AlertState:
    """Evaluate check result against thresholds and send alerts."""
    # Track latency history (rolling window of 10)
    state.latency_history.append(result.latency_ms)
    state.latency_history = state.latency_history[-10:]
    avg_latency = sum(state.latency_history) / len(state.latency_history)

    alerts = []

    # Availability alert
    if not result.healthy:
        state.consecutive_failures += 1
        if state.consecutive_failures >= config.consecutive_failures_alert:
            alerts.append({
                "severity": "critical",
                "title": f"{result.service} is DOWN",
                "detail": result.error or f"Status {result.status_code}",
                "failures": state.consecutive_failures,
            })
    else:
        if state.consecutive_failures >= config.consecutive_failures_alert:
            alerts.append({
                "severity": "resolved",
                "title": f"{result.service} has RECOVERED",
                "detail": f"Latency: {result.latency_ms}ms",
            })
        state.consecutive_failures = 0

    # Latency alert
    if result.healthy and avg_latency > config.latency_critical_ms:
        alerts.append({
            "severity": "warning",
            "title": f"{result.service} high latency",
            "detail": f"Avg latency {avg_latency:.0f}ms exceeds {config.latency_critical_ms}ms",
        })

    # SSL expiry alert
    if result.ssl_days_remaining is not None:
        if result.ssl_days_remaining <= config.ssl_expiry_warn_days:
            alerts.append({
                "severity": "warning",
                "title": f"{result.service} SSL expiring soon",
                "detail": f"Certificate expires in {result.ssl_days_remaining} days",
            })

    for alert in alerts:
        send_slack_alert(alert)
        if alert["severity"] == "critical":
            send_pagerduty_alert(alert)
        logger.info("Alert sent: %s — %s", alert["severity"], alert["title"])

    state.is_degraded = not result.healthy
    return state

def send_slack_alert(alert: dict) -> None:
    """Send alert notification to Slack channel."""
    color_map = {"critical": "#dc2626", "warning": "#f59e0b", "resolved": "#16a34a"}
    payload = json.dumps({
        "attachments": [{
            "color": color_map.get(alert["severity"], "#6b7280"),
            "title": alert["title"],
            "text": alert["detail"],
            "footer": "ServiceMonitor",
            "ts": int(time.time()),
        }]
    }).encode()
    try:
        req = Request(SLACK_WEBHOOK_URL, data=payload, method="POST")
        req.add_header("Content-Type", "application/json")
        urlopen(req, timeout=10)
    except Exception as e:
        logger.error("Slack alert failed: %s", e)

def send_pagerduty_alert(alert: dict) -> None:
    """Trigger PagerDuty incident for critical alerts."""
    payload = json.dumps({
        "routing_key": PAGERDUTY_KEY,
        "event_action": "trigger",
        "payload": {
            "summary": alert["title"],
            "severity": "critical",
            "source": "service_monitor",
            "custom_details": {"detail": alert["detail"]},
        },
    }).encode()
    try:
        req = Request(
            "https://events.pagerduty.com/v2/enqueue",
            data=payload, method="POST",
        )
        req.add_header("Content-Type", "application/json")
        urlopen(req, timeout=10)
    except Exception as e:
        logger.error("PagerDuty alert failed: %s", e)

This monitoring script checks HTTP availability, measures response latency against configurable thresholds, verifies SSL certificate expiry, and routes alerts to Slack and PagerDuty based on severity. The pattern of consecutive failure checks prevents noisy alerting from transient network blips — a critical detail that teams learn the hard way after being woken up at 3 AM for a single dropped packet.

Phase 4: Adopt Infrastructure as Code

Manual server configuration is the enemy of reproducibility. Every time someone SSHs into a server and runs a command, you create drift between what you think your infrastructure looks like and what it actually looks like. Infrastructure as Code (IaC) eliminates this by defining every resource — servers, load balancers, DNS records, databases, CDN configurations — as declarative code that lives in version control.

The benefits compound over time: new environments can be spun up in minutes rather than days, disaster recovery becomes a Terraform apply away, and infrastructure changes go through the same code review process as application changes. Teams that have adopted IaC report dramatically faster onboarding times, because new developers can understand the entire infrastructure by reading a repository rather than asking five different people.

Phase 5: Build a Culture of Continuous Improvement

The technical practices — CI/CD, monitoring, IaC — are necessary but not sufficient. The cultural practices are what make DevOps sustainable:

• Blameless post-mortems: After every incident, write a post-mortem that focuses on systemic causes, not individual mistakes. The goal is to identify what process, tool, or communication gap allowed the incident to happen, and to fix that gap so it cannot recur.
• Chaos engineering: Intentionally inject failures into your systems to verify that your monitoring catches them and your team knows how to respond. Start small — kill a single pod, simulate a slow database — and build confidence gradually.
• Internal developer platforms: As your DevOps maturity grows, invest in self-service tooling that lets developers deploy, scale, and monitor their services without filing tickets. The platform team becomes an enabler, not a gatekeeper.
• Debt tracking: DevOps improvements are not free. Track your technical debt explicitly, and allocate a percentage of each sprint to paying it down. Twenty percent is a common starting point.

Common DevOps Anti-Patterns in Web Teams

Understanding what not to do is as valuable as knowing the right approach. These are the most common anti-patterns observed in web development teams attempting DevOps adoption:

Tool Obsession Without Culture Change

Buying Kubernetes, Terraform, and a monitoring stack does not make you a DevOps team. These tools amplify existing culture — if your culture is siloed and blame-oriented, fancy tools will just give you faster, more visible failures. Start with the cultural principles and let tool choices follow naturally. Teams that use Kubernetes effectively do so because they already had the operational maturity to manage distributed systems, not the other way around.

DevOps as a Separate Team

Creating a “DevOps team” that sits between development and operations is a common organizational reflex — and it misses the point entirely. You have now created three silos instead of two. DevOps is a practice that every team member participates in, not a department. Platform engineering teams can exist to build shared tooling, but every development team should own its own deployment pipeline and production monitoring.

Automating a Broken Process

If your manual deployment process involves fifteen steps, eleven of which are workarounds for known bugs, automating those fifteen steps gives you a fast, automated broken process. Before automating, simplify. Remove unnecessary steps, fix the underlying issues, and then automate the clean process.

Ignoring Security Until the End

DevSecOps — integrating security into the DevOps pipeline — is not optional for web teams. Web applications are directly exposed to the internet and are constant targets. Security scanning should run on every pull request, dependency vulnerabilities should block deployments, and secrets management should be automated from day one. Bolting security on after launch is exponentially more expensive than building it in from the start.

Measuring DevOps Success

Track these metrics from the beginning, even before you start making changes. Having a baseline is essential for demonstrating improvement to stakeholders and for catching regressions.

Beyond the four DORA metrics mentioned earlier, web teams should also monitor:

• Deployment confidence: Would your team deploy on a Friday afternoon? If not, your pipeline lacks sufficient automated safeguards.
• Time to onboard: How many days until a new developer can make their first production deploy? This measures the clarity of your documentation and automation.
• Incident learning rate: How many post-mortem action items are completed within 30 days? This measures whether your team actually improves from incidents or just documents them.
• Developer satisfaction: Survey your team quarterly. DevOps should make engineers’ lives better, not worse. If your developers hate being on call, your observability and automation are insufficient.

Project management tools like Taskee can help teams track DevOps improvement initiatives alongside regular feature work, ensuring that infrastructure and culture improvements do not get perpetually deprioritized in favor of the next feature request. Similarly, agencies managing multiple client projects with different DevOps maturity levels benefit from centralized project oversight — platforms like Toimi provide the visibility needed to standardize DevOps practices across teams and clients.

Getting Started: A 30-Day DevOps Kickstart Plan

For web teams that are new to DevOps, here is a concrete 30-day plan to build momentum without overwhelming the team:

Week 1 — Foundation: Put all infrastructure configuration into Git. Set up a basic CI pipeline that runs linting and unit tests on every pull request. Establish a shared Slack channel for deployment notifications.

Week 2 — Deployment: Automate staging deployments. Every merge to the main branch should deploy to staging within minutes, with zero manual steps. Add end-to-end smoke tests that run automatically after deployment.

Week 3 — Observability: Instrument your application with basic metrics (request count, latency, error rate) and set up dashboards. Configure alerts for the most critical conditions: site down, error rate spike, SSL certificate expiring.

Week 4 — Culture: Run your first blameless post-mortem (even if you need to pick a minor incident to analyze). Document your deployment process as a runbook. Start an on-call rotation that includes developers. Celebrate your first fully automated production deployment.

This plan deliberately starts with technical foundations and ends with cultural practices, because cultural change is easier to adopt when the tooling supports it. It is hard to practice blameless post-mortems when you have no monitoring data to analyze.

Frequently Asked Questions