Technical Leadership & Delivery Best Practices

This is the index for the Technical Leadership & Delivery section. It condenses every page's guidance into one review sheet.

Each best practice below is a one-line rule linking to the full page behind it. Use this to decide how much process a given AWS-touching change actually needs.

How to Use This List

• Read top to bottom for a fast refresher, or use it as a router: pick the category the situation touches and open its page.
• Groups run roughly in the order a change moves through: review it, ship it, measure it, then grow the people doing it.
• Every practice holds regardless of whether the team writes boto3 or AWS SDK for JavaScript v3.
• If you only read two pages from this section, read the design review checklist and the release strategy page.

A - Design Review

• Read the IAM policy before the code. A too-broad policy is dangerous on its own, independent of whether the logic using it is correct.
• Turn the cost model into a number, not a feeling. Estimate spend at expected volume and at 10x volume before approving anything usage-priced.
• Assume every mutating call will run twice. Guard writes and deletes with a conditional expression or an idempotency token; retries happen by default.
• Decide the rollback plan in the review, not the incident. Name the mechanism (flag, config toggle, revert) and the owner before shipping.

Full detail: Design Reviews for New AWS Integrations.

B - Release Strategy

• Pick the right layer for the ramp. Use Lambda alias weighted routing when the unit of deploy is a function; use an application-level flag otherwise or when ramping by user/tenant.
• Set a rollback trigger before the ramp starts. A specific metric and threshold, not "we'll know it if we see it."
• Decide fail-open vs fail-closed per feature. An enhancement can usually fail open to old behavior; a security or integrity control should fail closed.
• Remove the flag once rollout is complete. A permanent-looking rollout flag is technical debt nobody is sure is safe to delete.

Full detail: Release Strategy & Feature Flags for AWS-Backed Features.

C - Measuring Delivery (DORA)

• Track all four DORA metrics, not a subset. Deployment frequency, lead time for changes, change failure rate, and MTTR.
• Measure lead time through IAM and quota waits. For AWS work, approval and service-quota delays often hide outside "commit to merge."
• Count cost-driven rollbacks as change failures. A functionally correct feature that triggers a billing alarm is still a failed change.
• Use these metrics on the team, never on an individual. They measure the delivery system, not any one engineer's output.

Full detail: DORA Metrics for AWS SDK Teams.

D - People: Mentoring and Product

• Ramp newcomers read-only first. Start with list/get/describe calls, then a least-privilege sandbox, before any shared or production mutating call.
• Pair the first mutating call, always. It's the highest-leverage moment to transfer judgment about blast radius and idempotency, even for senior hires.
• Let engineers reach independent ownership. Perpetual special oversight is a bottleneck, not a safeguard.
• Translate AWS cost into business-unit terms for product. Cost per user, per document, or per conversation - not cost per API call - at current and 10x scale.

Full detail: Mentoring Engineers New to AWS SDKs and Working with Product on AWS-Cost-Sensitive Features.

E - Where to Start

• Read the overview first. Leading AWS SDK Technical Work frames how these pieces fit together.
• Use the basics page for a first-PR checklist. Technical Leadership Basics gives a starter checklist for reviewing a teammate's first AWS integration PR.
• Apply one standard to both languages. Every practice here holds for boto3 and AWS SDK v3 equally.

FAQs

Related

• Leading AWS SDK Technical Work - the overview these practices condense from.
• Design Reviews for New AWS Integrations - the highest-impact checklist.
• DORA Metrics for AWS SDK Teams - measuring whether this process is actually working.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).