Forem: Davide de Paolis

Kiro showcase: Automating Changes Across Several Repos with Spec-Driven Development and Custom Sub-Agents

Davide de Paolis — Tue, 07 Apr 2026 14:54:04 +0000

As I mentioned in my previous post about engineering leadership and AI, I'm constantly looking for opportunities to experiment with AI-native development. Given how scarce hands-on time is in a manager's calendar, I'm often "vibe-coding between meetings" - trying to make the most of short, focused sessions with an AI-native SDLC.

In my recent talk at AWS Community Day Slovakia, I referenced the four archetypes of AI adoption by AWS Serverless Hero Lee Gilmore. Until last year, I was a "dismissive expert", and I still recognise that scepticism around AI in engineering almost daily - at work and online.

Many sceptics limit AI to debugging tasks or use it as a glorified search engine. That's a missed opportunity.

This post documents a real-world case where I used AI for a small but necessary "side-quest" that would have required several hours of tedious refactoring. It's a practical example of spec-driven development and AI-native SDLC in action.

The Problem

While reviewing IAM policies on a colleague's PR, I noticed references to DynamoDB tables that were used for Terraform state locking. HashiCorp deprecated DynamoDB-based state locking in Terraform 1.10 (November 2024) in favor of S3 native locking: I was sure we had already updated all our 200+ repositories' Terraform backend configurations to avoid the deprecated lock mechanism.
Was this policy an unnecessary leftover, or had we forgotten some repos?
Or had other teams recently created new IaC using the old mechanism?

Searching and fixing this was definitely out of scope for the original ticket and PR. We have bigger, more important problems to solve than this small cleanup. But as my team is responsible for our Cloud Infrastructure Platform and for Cloud Engineering practices, it bothered me that we had such an inconsistency, that we were using deprecated Terraform versions, and risked pipeline failures if a Terraform update suddenly broke things, causing panic and wasted time in feature teams.

Since a manual migration/refactoring would be tedious and error-prone, this appeared like a great task for AI - not just to run a search-and-replace across 200 repos, but to explore the capabilities of several MCP servers, spec-driven development, and agent orchestration with Kiro.

A well-integrated AI-native SDLC use case: simple but useful.

Phase 1: Discovery

Rather than manually searching through repositories, I used Kiro with the GitHub MCP server to:

Find all repositories using the deprecated config
Identify repos using Terraform versions below 1.10
Retrieve the actual files (Terraform configs, Terragrunt files, CI workflows)
Group them by codeowners for easier review coordination

Since switching to S3 object locking could corrupt state if bucket versioning isn't enabled, I also wanted to verify our buckets' configurations across all AWS accounts.

Using the AWS MCP server and our own connect-aws skill, I could:

Automatically reconnected to all accounts in our AWS config
Checked every S3 bucket used by these repos
Verified versioning was enabled

The discovery phase took less than few minutes of actual work. The AI handled the tedious data gathering while I focused on validation and decision-making.

With the data collected, I used the Atlassian MCP server to create a Jira ticket documenting the context, affected repos, and migration risks. Without leaving my IDE, all the relevant information was nicely formatted in a user story.

Phase 2: Spec-Driven Development

Rather than jumping straight to coding, I used this as an opportunity to practice spec-driven development and AI-native SDLC.

I started a new project and asked Kiro to pull the Jira ticket and help write a spec.

Requirements Phase

The AI-generated requirements document captured the key aspects well:

Load migration targets from repositories.json
Validate Terraform version compatibility (>= 1.10 required)
Update backend configurations via text replacement
Handle edge cases (older Terraform versions, CI pipeline overrides)

I refined a few details around how pipelines use backend-config flags, but overall the requirements were solid.

Design Phase

This is where iteration became necessary. The AI's initial approach was a monolithic Python script - procedural and difficult to parallelize (let alone review and debug).

After several iterations where I emphasized the need for orchestration, progress tracking, error correction, and race condition avoidance - basically where I tried to achieve the so-called "Ralph Wiggum Loop" (see Ralph Wiggum Pattern by G. Huntley and Massimo Ferre's Kiro implementation) - we arrived at an agent-based architecture:

Orchestrator Script
├── Spawns multiple worker agents
├── Each agent claims a repository atomically
├── Agents work in parallel
├── Shared state via migration-status.json
└── Learning system via corrections.md

The design included:

Atomic operations: Each repo migration is independent
Status tracking: migration-status.json prevents duplicate work
Learning loop: corrections.md records failures and solutions
Race condition protection: Agents verify ownership after claiming

Tasks Phase

Despite defining the design with an agent-based approach, the tasks initially generated by Kiro had issues: the first task was meant to write a script for subsequent tasks to use, which wouldn't work for parallel orchestrated execution.

However, the task descriptions themselves were useful. Therefore I pivoted and asked Kiro to use its /custom-agent-creator to create an agent (not a script) with proper tool settings and a prompt to execute the workflow.

It's quite annoying that Kiro IDE creates and uses agents written in markdown, but if you rely on agents invoked as subagents or start kiro-cli directly with an agent, you need a JSON format. So usually I tend to write (or ask Kiro to create) the agent in Markdown (with frontmatter section) and then in JSON format as well (but importing the prompt from the markdown file: "prompt": "file://migrator-agent.md").

Phase 3: Building the Migrator Agent

The agent prompt handled the complete workflow:

Claim a repository from migration-status.json atomically
Load corrections from previous failures
Clone the repo and create a branch
Search for the deprecated configuration using dynamodb_table
Replace the config with the new S3 use_lockfile
Check and update Terraform versions if needed
Format the code (terraform fmt / terragrunt hclfmt)
Commit, push, and create a PR
Update status (completed/failed)
Clean up temp directories
Record errors in corrections.md for learning

The agent configuration (.kiro/agents/migrator-agent.json) defined the Tools that the agent has available and what are allowed with or without approval:

  "tools": [
    "read",
    "write",
    "shell",
    "mcp:github",
    "mcp:atlassian"
  ],
  "allowedTools": [
    "fs_read",
    "write",
    "shell",
    "mcp:github",
    "mcp:atlassian"
  ],
  "toolsSettings": {
    "write": {
      "allowedPaths": ["*"]
    },
    "fs_read": {
      "alwaysAllow": [
        "*"
      ]
    },
    "shell": {
      "allowedCommands": [".*"],
      "autoAllowReadonly": true
    }
  }

Defining the tools and what is allowed is one of the trickiest parts. I want to orchestrate agents and have as much as possible automated, and I definitely want to spend my time solving other problems rather than being a guardian/gatekeeper clicking "approve or reject" for each action. On the other hand, granting full write or shell access is concerning. Finding the right balance is important.

After running the agent on its own and addressing a couple of issues, the agent was ready to be called as a subagent.

Phase 4: Orchestration

The agent worked well sequentially, but processing 30+ repos one at a time would be slow. Therefore I asked Kiro to create an orchestrator script that:

Spawns 4 agents in parallel (the current maximum of kiro-cli)
Monitors progress
Shows real-time stats (completed, in progress, failed, pending) and pipes progress and errors
Waits for all workers to finish
Generates final report

The agents coordinate through migration-status.json using atomic file updates with jq, save the progress to that file and to a more detailed corrections.md where all errors and different attempts are documented, to retry without going through the same mistakes but instead trying different approaches.

Necessary Reminder About AI-Generated Code

AI-generated code can be confidently incorrect. During this project/experiment, Kiro produced several times:

Made-up Kiro Agents' JSON schemas - which is particularly surprising since I would expect Kiro should know how it works...
Non-existent commands
Illogical implementations

Always review what's generated. Think critically about the problem and solution. Challenge the AI when something seems off. Otherwise, you'll waste time debugging broken code.

The Results and What This Really Demonstrates

I spent probably less than 90 minutes iterating on the entire "side-quest" - from identifying the scope of the changes (number of files and repos, type of change) and defining the prompt of the agent and putting everything together with the orchestrator (once again, not in one focused session but spread across meetings).
Once working, all 30+ PRs were created within a few minutes.
The amount of credits consumed was roughly ~80 (out of 1K monthly allowance with $20/month plan).

Was that worth it?

The manual alternative would have required likely 4-6 hours of very repetitive work:

Clone each repo
Find the files
Make the changes
Handle version updates
Create PRs

Tedious and error-prone. Considering breaks and some meetings, working manually on this ticket would have required a full day of an engineer, and likely a very wasted one - not such great conceptual work, nor a great learning experience (if not becoming faster in git clone, search & replace, git commit, and gh pr create --title --body --base main).

The value isn't just time saved.

This project provided:

Hands-on experience with AI automation and parallel agent orchestration
Practice with spec-driven development (requirements → design → tasks)
A learning system (corrections.md) that improves over time
Reusable patterns for any bulk repository operation

I took this small opportunity ( a necessary, but not so crucial refactoring task ) as a training ground for more complex problems.
You don't learn advanced techniques by tackling the hardest problems first - you build skills incrementally.

When I face truly challenging automation needs, these patterns will be ready.

Key Takeaways

What Worked

MCP servers (GitHub, AWS, Atlassian) enable AI to interact with real APIs effectively - although I am already aware that MCP servers, especially for local development, are losing the attention they received last year because actually using any CLI is likely faster and cheaper. Using them allowed me to really start experimenting more with AI and see the benefit of integrating different tools to improve productivity and focus. (Read more about the MCP vs CLI discussion and why CLI tools are beating MCP for AI agents.)
Spec-driven development forces clarity before implementation: this is something that we engineers should always do, and this is how we should have always been working (receiving well-described tickets with clear specifications and requirements, and then spending some time thinking about the problem and how to implement the solution rather than just diving into coding). Now spec-driven development finally forces us to do that.
Agent-based architecture with shared state scales simply
Learning loops (corrections.md) turn failures into improvements

What Required Iteration

AI defaults to monolithic solutions; modular design requires explicit guidance
Generated code needs critical review before execution
Edge cases emerge during testing that specs don't anticipate
Despite refined prompts and clear guidance, context rot and hallucination are relatively common

Key Lessons

Use AI for discovery and data gathering before making decisions
Document requirements and design - specs are thinking tools
Iterate on design; don't accept the first solution
Review generated code critically
Test incrementally before full-scale execution

Conclusion

By taking on this side-quest - likely an improvement ticket that would have been postponed for months, if ever, due to low urgency and low importance (and almost a day of effort) - I praticed AI-native development workflows, built reusable automation patterns, experimented with spec-driven development, and with Ralh Wiggum loop.

When faced with tedious, automatable work, using it as an opportunity to experiment and learn is more valuable than optimizing for immediate completion. The patterns and experience gained here will apply to far more complex problems in the future.

Hope it helps!

Setting Up Kiro for Your AI-Native SDLC

Davide de Paolis — Fri, 06 Feb 2026 12:28:21 +0000

I didn't wake up one morning and decide, "Today I'm building an AI-native Software Development Life Cycle!" It took weeks of trial and error to figure out what actually works. This post is my attempt to save you that time, so you can hit the ground running from day one.

The Context: Coding Between Meetings

When you move from IC to Tech Lead or Engineering Manager you will face different challenges: you write less code, but you're expected to stay technical. At this point, my hands-on coding is close to zero (though I know the role of EM varies wildly depending on company and team). But I'm not just doing people stuff like 1:1s, roadmaps, vacation planning and agile ceremonies.
The real job is still:

Providing technical guidance and architecture decisions
Keeping an eye on delivery and quality
Mentoring the team
Evaluating technical contributions
Building a high-performing team where blockers get removed and quality, security, and automation are just how we work.

You know the difference between the maker's schedule and the manager's schedule? Yeah, that's my life now.

Still, I try to stay close to the code whenever I can. It keeps me sharp, and often dogfooding our own platform helps me understand what pains my team members, our internal users and newly onboarded teams are going through.

So I pick up tickets that are off the critical path. The grunt work. The nice-to-haves. Stuff that could take a day or a month and nobody's blocked waiting for it:

Documentation improvements
Pipeline fixes and optimizations
Small refactors that have been bugging people
Architecture diagrams that actually reflect reality
Raising the bar on code quality through better practices and conventions

Plus, there's the other stuff:

Code reviews (even in languages I'm rusty in)
Making sense of old, poorly documented repos we've inherited
Cutting through documentation overhead and decision paralysis
Exploring new services we might want to add to our platform

It's a lot of hats. And the time is always scarce.
Trying to do all this between meetings, with constant context switching and maybe 30 minutes here and there? It was rough. Until recently, my AI usage was pretty basic: ChatGPT or Langdock for document reviews, text polishing, brainstorming. Basically a fancy Google search.

For coding, I had Copilot in VS Code and Amazon Q in my terminal, but I was barely scratching the surface. "Summarise this document", "Refactor that function", "Write me a quick shell script." The most useful thing was asking Q for AWS CLI commands in plain English.

Then Kiro happened. When it launched (and especially when Q became Kiro in November), I immediately upgraded to Kiro Plus. Perfect timing, too—my team got hit hard with parental leave, sick days, and vacation all at once. Suddenly, I had a chance to get my hands dirty again, yet I still can't get long, uninterrupted coding sessions.

Most EMs and Staff+ engineers I know are coding in the gaps between meetings. That's exactly why AI matters so much now. We can use it to amplify what we can do in those fragmented windows of time.
Turning hours into minutes.

What Changed: The Mindset Shift

These days, Kiro is my go-to for:

Code Reviews: Even in languages where I'm not the expert, I can provide meaningful guidance
Documentation: Making sense of legacy repos and actually documenting them properly
Problem Structuring: Taking vague requirements and turning them into something actionable
Architecture: Quickly exploring alternatives, surfacing trade-offs, challenging my own assumptions. And yeah, drawing diagrams (with Draw.io and Mermaid) that actually stay up to date
Decision Records: Writing RFCs and ADRs while the context is still in my head
Maintenance: Keeping docs and diagrams from going stale
Learning: Getting up to speed on unfamiliar (but not necessarily new) tech

Has it boosted my productivity? Absolutely. But I won't lie; the setup took time. Figuring out steering files, agents, hooks, MCP servers, powers... it was a lot. That's why I'm writing this: to save you the mental overhead I went through.

I won't bore you with the details of setting it up. It's really straightforward and well documented: Kiro How-To

But I want to briefly introduce Kiro features and how you can take advantage of them.

Quick Note on Cost and Pricing

Before we dive in, let's talk money. Kiro's pricing is refreshingly simple: monthly plans with credits. €20 gets you 1,000 credits, €40 gets you 2,000, and €200 gets you 10,000.

How fast you burn through credits? That depends on which model you're using and how complex your interactions are. Bigger context means more credits. But what I appreciate is the full cost visibility. Every single interaction shows you exactly how many credits it used. No surprises at the end of the month.

If you do run out of credits mid-month, you can pay as you go at $0.04/credit. And from the org side, you can:

Toggle overage on/off to control costs
Enable detailed usage metrics (saved to S3) to see where credits are going

The cost isn't entirely predictable, but it's transparent. After a few weeks of use, I found the middle tier works well for our workflow. The time I save on documentation, code reviews, and understanding unfamiliar codebases more than justifies the cost. Your mileage may vary depending on how you work, but the visibility makes it easy to adjust.

Prompts: Reusable Instructions

Prompt: an input or instruction you give to the AI. It tells the AI what to do, what context to consider, and how to respond. Think of it as a mix between a command, a question, and a set of guidelines.

In our daily work, we have recurring tasks. Not the simple "refactor this" or "make this more professional" requests - (and even these could benefit from better prompting!) - I'm talking about complex, multi-step instructions that you'd otherwise repeat every time. That's where prompt files come in.

What Are Prompt Files?

Prompt files are markdown documents stored in your project that contain reusable instructions for the AI. They're written as behavior guides, not templates for users to fill in.

Where They Live

Source: .kiro/prompts/
Usage: Reference with @your-prompt in CLI, or mention naturally in the IDE

How to Structure Them

Write prompts TO the AI, not FOR the user. Include context, approach, and expected behavior. Here's a basic structure:

# Prompt Name

You are helping the user with [specific task].

## Your Approach

1. First, do this
2. Then, do that
3. Finally, conclude with this

## Communication Style

- Be clear and concise
- Ask clarifying questions
- Provide examples

## Example Interaction

User: "Help me debug this"
You: "Let me analyze the error. First, I'll check..."

Prompts We Actually Use

Here are a few we've built that save us time:

AI Review: Before opening a PR, we ask AI to review all committed changes. Catches obvious issues before bothering teammates.
PR Generation: The agent analyzes committed changes and creates a detailed summary for the PR description. Gives reviewers context upfront.
Project Review: When jumping into an unfamiliar repository, we ask Kiro for a project review. It summarizes structure, dependencies, main components, risks, and opportunities. Helps you decide where to focus first.

Steering Files: Teaching Consistent Behaviour

If prompts let you manually instruct the AI for specific tasks, steering files teach it to behave consistently without repeating yourself every time.

Steering files are markdown documents that live next to your code and provide context, conventions, and guidelines to AI assistants. Think of them as persistent documentation that automatically shapes how Kiro behaves across all your sessions. Instead of telling the AI your team's conventions every time, you tell it once.

Other tools use similar concepts with different names (like .rules files). I must say I prefer the concept of "steering" because these files guide and influence behavior rather than enforce rigid constraints. They let the AI move fast within the boundaries you've defined.

What Goes in Steering Files?

Kiro can generate foundational steering files (product overview, tech stack, project structure) just by reviewing your project. After that, you can add custom steering for specific areas:

Security guidelines
Testing strategies
Deployment procedures
Code review standards
Naming conventions
Architecture principles
Team communication protocols

The Human Benefit

I have read a lot of negative comments about the verbosity of AI and the sprawl of ai-context markdown files, but personally, I believe Steering files are just as useful for humans as they are for AI. They become:

Living documentation that stays close to the code
Onboarding guides for new team members
Quick reference for project conventions
Single source of truth for standards

The more I use them, the less I need those manually written READMEs with tables of contents and multiple subpages that go stale after a few weeks. Now I keep a main README for humans, the AGENTS.md file for AI Agents and a couple of other entry points for humans consuming or contributing to the repository. But they mostly point to the steering files.

Kiro's Smart Loading Strategy

The "always on" nature of context files could be a problem. Load too much, and you'll burn through credits. This is where Kiro stands out: it supports three loading strategies to keep context focused.

Always: Loaded in every conversation

---
inclusion: always
---

Use this for core project context that's always relevant.

File-Based: Loaded when specific files are open

---
inclusion: fileMatch
fileMatchPattern: "*.tf"
fileMatchPattern: ["**/*.ts", "**/*.tsx", "**/tsconfig.*.json"]
---

Use this for domain-specific guidance. When you open a Terraform file, the Terraform guide loads automatically.

Manual: Loaded only when referenced

---
inclusion: manual
---

Use this for detailed guides you only need occasionally.
This on-demand loading keeps context focused and prevents overwhelming the AI with irrelevant information.

Content Organisation

You can write content directly in the steering file or reference another file in your repo. I tend to put shared context under .agents/context/ so different AI tools can reference it. Each developer can then create pointers in their tool's settings (.cursorrules, .kiro/steering/, etc.). More on this approach in a later post.

You can read more about steering files and their conventions in the Kiro documentation.

MCP Servers: Extending Capabilities

I covered what MCP servers are in more detail in a previous post. The short version: they're a great way to extend your AI tool's capabilities, and they're easy to integrate into your workflow.

Why They Matter

Of course, I can browse AWS docs in one tab, check GitHub in another, switch to our observability platform to look at the latest incident, then jump to Jira to update a ticket. But every tab/tool switch is a tiny context switch. And for me, that often leads to distractions: I open Slack to check something, then see another urgent message, reply to that, and suddenly I'm asking myself: wait, why did I leave the IDE? (Similarly to the Doorway Effect)

If I can do all of that from the same window where I'm already working, I can stay focused and move faster. (and also, less strain on fingers and wrists to use the mouse or keyboard shortcuts to switch tabs).

What I'm Using

I keep several MCP servers installed but I pay attention to have them enabled only on demand. Here's what I use most:

GitHub
New Relic
Atlassian
AWS API
AWS Diagram
AWS Terraform
AWS EKS
AWS Pricing

Real Usage Examples

Instead of leaving the IDE to search AWS documentation:

You: "How do I configure Lambda function URLs?"
Kiro: *searches AWS docs*
      *provides relevant documentation*
      *suggests implementation*

Also, I recently discovered I can manage tasks generated by SpecDriven Development with Kiro using the Backlog.md MCP:

You: "Create a task for implementing XYZ"
Kiro: *creates task in Backlog.md*
      *links to relevant spec*
      *sets priority and acceptance criteria*

A Word of Caution

Be careful with how many MCP servers you have enabled. Too many can clutter your context and slow things down. The on-demand activation helps, but it's still worth being selective about what you install.

I'll cover Backlog.md and spec-driven development in another post. For now, let's look at how agents and powers build on these foundations.

Custom Agents: Specialised Configurations

Agents combine prompts, steering files, and MCP servers into specialised configurations for specific tasks. Think of them as roles you can switch between, each with its own context, tools, and behaviour.

How They Work

Agents are defined as JSON files stored in .kiro/agents/ (either globally or per project). You can view available agents with /agent list or switch between them with /agent swap. (only in kiro-cli)

The magic is in the packaging. Instead of manually loading the right prompts, enabling the right MCP servers, and remembering which tools to use, you reference an agent and get everything configured automatically.

A Real Example

Here's our PlatformSupportAgent (redacted for brevity) that helps colleagues get answers about our platform offering:

{
  "$schema": "https://raw.githubusercontent.com/aws/amazon-q-developer-cli/refs/heads/main/schemas/agent-v1.json",
  "name": "cloudplatform-support",
  "description": "Answers questions about cloud platform using documentation, Terraform, GitHub, and AWS resources",
  "prompt": "quite descriptive prompt",
  "mcpServers": {
    "aws-documentation": {},
    "terraform": {},
    "github": {}
  },
  "tools": [
    "fsRead",
    "listDirectory",
    "fileSearch",
    "grepSearch",
    "@aws-documentation",
    "@terraform",
    "@github"
  ],
  "allowedTools": ["fsRead", "listDirectory", "fileSearch", "grepSearch"],
  "toolsSettings": {},
  "resources": [
    "file://.agents/context/iac-baseline.md",
    "file://.agents/context/code-quality.md",
    "file://README.md",
    "file://AGENTS.md",
    "file://docs/**/*.md"
  ]
}

This agent comes pre-configured with GitHub, AWS docs, and Terraform tools, has baseline standards always loaded, and maintains the support persona throughout the conversation.

Agents vs. Prompts

You might wonder: why not just use prompts? Here's the difference:

Prompts (.kiro/prompts/*.md):

Reference with @your-prompt
Injects instructions into the current conversation
Use when you want to add specific methodology to your current agent
More flexible, can combine with other prompts

Agents (.kiro/agents/*.json):

Activate with /agent swap your-agent
Switches to a completely different persona with its own tools and context
Use when the task requires specific resources, tools, and persistent context
More powerful for complex, recurring workflows

For the same task, I often create both. The prompt gives me flexibility to use it with any agent. The agent gives me a complete, pre-configured environment when I need the full setup.

The Maintenance Challenge

What I don't love about agents: the prompt field in the JSON can get hard to read and maintain. Because of this (and to improve reusability across AI tools), I often publish agents in both JSON and Markdown formats. The Markdown version is just a human-readable version of the same content. (that can also be fed to other AI tools, to achieve similar results - although without the MCP servers and tools).

I automate this with Kiro Hooks, which we'll cover next.

Hooks: Automation

Hooks execute commands or trigger the agent whenever specific events occur in your IDE. Think of them as automated workflows that respond to file changes, saves, or other IDE events.

Why Use Hooks?

I used to finish writing code and then remember I needed to update the documentation. Or I'd move files around and forget to update links. Hooks remove that mental overhead by automating the repetitive parts.

Available Triggers

Hooks can respond to several events:

fileEdited: When you save a file
fileCreated: When you create a new file
fileDeleted: When you delete a file
agentStop: When an agent execution completes
Plus more in Kiro CLI

What Hooks Can Do

When triggered, hooks can either:

Invoke the agent with a specific prompt
Run a shell command directly

A Simple Example

{
  "name": "Lint on Save",
  "when": { "type": "fileEdited", "patterns": ["*.ts"] },
  "then": { "type": "askAgent", "prompt": "Run linter and fix errors" }
}

My Real-World Hook

Here's the hook I mentioned above, that I use to automate Agents' readability. Whenever I create or edit an agent JSON file, this hook automatically generates a readable Markdown version:

{
  "name": "Auto-convert Agent JSON to Markdown",
  "when": {
    "type": "fileEdited",
    "patterns": [
      "**/agents/**/*.json"
    ]
  },
  "then": {
    "type": "askAgent",
    "prompt": "Convert the edited agent JSON file to a markdown format. Create a corresponding .md file with the same name in the same directory. Include all agent properties in a readable format with sections for name, description, instructions, and any other relevant fields. Explain what tools and resources the agent has available"
  }
}

This keeps my agent documentation up to date without any manual work.

Why I'm Cautious with Automatic Triggers

I haven't gone all-in on automatic hooks yet. In these early iterations, I'm rarely happy with the first result. I don't want hooks updating all my documentation just because I created a new piece of code that I'll definitely iterate on.

But hooks are powerful for truly repetitive tasks. If you find yourself doing the same thing after every file save or commit, that's a good candidate for a hook. The Kiro documentation has more examples, including one for maintaining test coverage.

Kiro Powers: Composable Functionality

If Agents are a great way of preconfiguring prompts and MCP servers for specific scenarios, meet the next level: Kiro Powers (unfortunately, not available in the CLI yet). They package documentation, workflows, and MCP servers into reusable units. Like plugins that give your AI assistant specialised knowledge and capabilities.

Why They're Useful

Instead of seeing dozens of individual MCP tools cluttering your configuration, you see a list of installed Powers. You activate them on demand, and they automatically enable their embedded MCP servers. This keeps your context clean while providing full access when you need it.

The Activate-Then-Use Pattern

Powers use a structured discovery approach:

Activate a Power to see what it offers
Discover available tools, documentation, and guides
Use specific capabilities as needed

What's Inside a Power

Powers include:

Documentation explaining what the Power does
Steering files with step-by-step guides for common tasks
Best practices from the team that built it
Examples showing real usage patterns
MCP servers that provide the actual functionality

A Real Example

Without a Power:

"How do I find our customized SQS Terraform module?"
→ Search GitHub manually
→ Find repository
→ Read README
→ Copy module path
→ Check version tags

With our Platform Engineering Hub Power:

"I need to add SQS to our project, what should I do?"
→ AI uses GitHub MCP via the Power to search our private CustomTerraformModules repository.
→ Gets README, examples, and usage
→ Provides complete answer instantly

Building My Own
Building your own Power is very easy - and guess what, a Kiro Power exist to guide you in the process! check it out here

So, this is what I just recently started playing around; starting from the CloudPlatform Support Agent I mentioned above, I'm currently building a Platform Knowledge-Base Power for our team. The goal is to distribute guidelines and resources in a centralised place while providing MCP servers that know where to search in our Confluence and GitHub repositories. This way, engineers can ask the AI agent questions before reaching out to us on Slack.

Current Limitations

I've noticed that Powers can't embed agents, prompts, hooks, or scripts (for obvious security reasons). My original goal was to use Powers to distribute a baseline of AI tools, but unless I convert everything to Markdown and document it within the Power's steering files, users won't see it.

Kiro Powers give you a clean, composable system. Each Power stays focused on its domain, and you activate only what you need for the current task. I'm still experimenting with them and will likely have more to share in the coming weeks.

What About Skills?

Skills are a concept from Claude that have gained traction in the broader AI tooling community. Kiro doesn't have native skills support (that's what steering files are for), but you can still use them thanks to skills.sh.

Skills.sh makes it easy to browse, install, and update skills from a central repository. The installation process is straightforward, and skills get copied into your .kiro/skills/ folder (either globally or per project).

I've started experimenting with AWS Hero Anton Babenko's Terraform skill for infrastructure work, which is genuinely useful and well-crafted.

The Integration Challenge

Here's where I'm still figuring things out: skills can be quite large and often overlap with steering files. Unlike steering files, they don't have an inclusion method (always, fileMatch, or manual). This means they're always loaded, which can bloat your context.

I'm still working through how to integrate skills smoothly with my existing steering file setup. The content is valuable, but the lack of conditional loading makes it tricky to manage alongside everything else.

I'll likely write a follow-up post once I've spent more time with them and figured out a good workflow.

Wrapping Up

This post covered the core building blocks of an AI-powered workflow with Kiro:

Prompts for reusable instructions
Steering files for consistent behavior and context
MCP servers for extending capabilities
Agents for specialized configurations
Hooks for automation
Powers for composable functionality
Skills for community-driven guidance

Each piece serves a specific purpose, and together they create a system that amplifies what you can accomplish in those fragmented windows of time between meetings.

The setup takes effort. I won't pretend otherwise. But once you have these pieces in place, the productivity gains are real. Not because the AI writes perfect code (it doesn't), but because it helps you think faster, explore alternatives quicker, and stay focused when context switching would normally derail you.

What's Next

Team Collaboration: How to work effectively when everyone uses different AI tools (Kiro, Cursor, Claude, Copilot), and how skills.sh fits into that picture
AI-Native SDLC: What it actually looks like in practice, including spec-driven development and the Backlog.md workflow

If you're experimenting with AI in your development workflow, I'd love to hear what's working for you. What tools are you using? What problems are you trying to solve?

Resources

Kiro Documentation: kiro.dev/docs
Promptz Library: promptz.dev/library - Community prompts and templates
Promptz Agents: promptz.dev/agents - Community agents
Skills.sh: skills.sh - AI skills management
AGENTS.md Standard: gradually.ai/en/agents-md - Emerging industry standard for AI context

I Didn’t Get MCP Until I Built One

Davide de Paolis — Mon, 02 Feb 2026 08:11:00 +0000

Eight months ago, I could barely tell you what an MCP server was.

I’d seen the term (Model Context Protocol) floating around on LinkedIn posts and in our AWS Community Builders Slack. Everyone seemed excited about it, but I had no idea what it was or why I should care. It felt like something for AI people - “Data Science and ML Engineers” - far removed from the daily grind of my team’s cloud infrastructure tasks and platform duties.

I had tried to use some of the AWS Labs MCP servers via Amazon Q, especially the documentation and pricing ones, but my experience wasn’t that exciting. They worked well, but I treated them like plugins - useful, but opaque.

I could use them; I couldn’t explain them.

Then, in November, Kiro became publicly available, and I started exploring its features more extensively (more on that in future posts).

Around the same time, I had the chance to participate in a Proof of Concept to build an MCP server. The initial idea was to expose our public API to AI tools and LLMs through an MCP server. Once proven, the goal was to move that into the product so that customers could use it too.

Of course, as I dove deeper into the topic MCP servers gradually started to make sense.

MCP servers are similar to APIs, but designed for AI agents. They allow them to communicate and utilise services and datasets outside their training data. to In this post, I’ll go through the basic concepts as I understood and learned them (by doing).

This post isn’t a guide or tutorial. You can find excellent resources around, or just ask your AI tool of choice, and you’ll get plenty of clarifications. It's a reflection on moving from “I have no idea what this is” to “I can build and deploy one.”

The Problem MCP Solves: The N×M Nightmare

Let’s start with the problem, because that’s what made everything click for me.

Large Language Models are powerful, but they are frozen in time. (the time when they were trained with data).

They don’t know:

the current state of your repositories
what’s in your internal documentation
the status of your Jira tickets
the shape of your APIs or databases

If we want AI tools to be genuinely useful in real engineering workflows, we need a way to safely and consistently connect them to live, external systems.

That’s where integrations come in, and that’s also where things get messy very quickly.

So, imagine you're building integrations for AI tools. You want your assistant to:

Access your GitHub repositories
Query your Jira tickets
Search your company’s documentation
Check your database

Now imagine you have multiple AI tools:

Claude Desktop
GitHub Copilot
Cursor
ChatGPT with plugins

Without a standard:

Claude needs a GitHub integration
Copilot needs a GitHub integration
Cursor needs a GitHub integration
ChatGPT needs a GitHub integration

Now multiply that by Jira, your docs, your database and the math is simple: 4 AI tools × 4 data sources = 16 custom integrations

Each integration is:

Built differently
Maintained separately
Incompatible with other tools
Duplicated effort

That’s completely unsustainable. Every AI tool needs its own integration with every data source. That’s N×M integrations, where N = AI tools and M = data sources.

With this standard protocol, instead of writing endless client integrations for each vendor, you describe your capabilities once, and any compliant AI can consume them.

Now you have N + M components instead of N×M integrations. The complexity shifts from O(N×M) to O(N+M).

MCP is the missing universal adapter between our data sources and AI-native tools.

MCP is like USB-C for AI tools.
This is the metaphor you will find basically everywhere, and for a good reason (so I won't try to unnecessarily and awkwardly find another one).

Remember before USB? Every device had its own connector:

Keyboards had PS/2 ports
Mice had serial ports
Printers had parallel ports
Cameras had proprietary connectors

You needed different ports for everything, and devices only worked with specific computers.

Then USB came along: one standard connector that works everywhere.

MCP does the same thing for AI tools:

Before MCP: Every AI tool had custom integrations for every data source
After MCP: One standard protocol, any MCP server works with any MCP client

Build a GitHub MCP server once → it works with Claude, Copilot, Cursor, and any future MCP-compatible AI tool.

What Actually Is an MCP Server?

So, MCP is a standard. But what’s an MCP server?

Simply put, an MCP server is a program that:

Connects to a data source (GitHub, database, API, etc.)
Exposes that data through standardized “tools”
Speaks the MCP protocol so any AI can use it

Basically, an MCP server is a wrapper, very similar to an API, but instead of several REST endpoints, you have so-called tools.

The Magic: Self-Describing Tools

When an MCP server connects to an AI, it announces its capabilities.

{
  "tools": [
    {
      "name": "search_repositories",
      "description": "Search GitHub repositories",
      "parameters": {
        "query": "string",
        "limit": "number"
      }
    },
    {
      "name": "get_file_contents",
      "description": "Get contents of a file from a repository",
      "parameters": {
        "owner": "string",
        "repo": "string",
        "path": "string"
      }
    }
  ]
}

The AI now knows:

What tools are available
What each tool does
What parameters they need
How to call them

The tools are self-documenting (docs here. But you still have to be careful.

The Tool Overload Problem

As soon as I started understanding and enjoying MCP servers, I began adding more and more to my setup.
But having too many MCP servers installed - each with multiple tools retrieved (self-described) at startup - creates an unexpected issue: too many tools can overwhelm the AI.

5 MCP servers × 20 tools each = 100 tools available
Every time you ask the AI a question, it needs to:

Load all 100 tool definitions
Understand what each does
Decide which to use
Execute the right one

This causes context bloat because tool definitions consume valuable context window space and often lower accuracy because the wrong tool ( especially if poorly named) could be picked

With 100 tools, every request includes:

100 tool names
100 descriptions
100 parameter schemas = thousands of tokens before you even ask a question! That’s why it’s important to be intentional, both as a user and as a developer.

From the User Perspective

*Don’t install every MCP server you find. *
Ask yourself:
Do I actually need this?
How often will I use these tools?
Can I enable/disable it when needed?

Example configuration:

{
  "mcpServers": {
    "awslabsaws-documentation-mcp-server": {
      "command": "uvx",
      // some args
      "disabled": false, // use it daily
      "disabledTools": [],
      "autoApprove": ["read_documentation"]
    },
    "terraform-mcp-server": {
      "command": "uvx",
      // some args
      "disabled": true,  // weekly use, enabled on demand
      "autoApprove": []
    }
  }
}

Different agents can have different MCP setups: my CloudOps agent uses AWS documentation and Terraform MCP servers, while a frontend agent might use React and GitHub MCP servers.

You can also autoApprove safe commands so the agent executes them automatically.

From the MCP Server Author’s Perspective

Use Clear Tool Naming: When building your own MCP servers, use namespaced names.

# Bad
- search()
- get()
- list()

# Good
- github_search_repositories()
- github_get_file_contents()
- github_list_pull_requests()

The AI can filter and understand domains faster.

Lazy Loading with Resources: Some MCP servers use resources instead of many tools. (docs here)

# Instead of 50 tools for different docs:
- get_lambda_docs()
- get_s3_docs()
- get_ec2_docs()

# One tool + resources:
- read_documentation(resource_uri)
  Resources:
  - docs://aws/lambda
  - docs://aws/s3
  - docs://aws/ec2

Resources are discovered on-demand, not loaded upfront.

We’ll look deeper into best practices when we actually build our first MCP server.

MCP Transport Protocols: stdio vs Streamable HTTP

As I dug deeper, I learned that MCP servers can communicate in two ways. (docs here)
Understanding this helped me choose the right setup for different use cases.

stdio (Standard Input/Output)

How it works:

Runs as a local process
Communication via stdin/stdout (like terminal piping)
The AI client spawns and manages the process

Configuration example:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/files"]
    }
  }
}

When to use stdio:

✅ Local tools, file systems, git operations
✅ Great for privacy (no network)
✅ Simple and fast
✅ Works offline

Cons:
👎 Installed locally per machine
👎 Hard to share across teams

HTTP (Remote Server)

How it works:

Runs as a remote HTTP service
Clients connect via URL + auth

Configuration example:

{
  "mcpServers": {
    "company-api": {
      "type": "http",
      "url": "https://mcp.company.com",
      "headers": {
        "Authorization": "Bearer ${API_TOKEN}"
      }
    }
  }
}

When to use HTTP:

✅ Shared services or APIs
✅ Team-wide/multi-user access
✅ Centralized updates & scalability

Cons:
👎 Requires network and auth setup
👎 Slightly more complex to operate

The Ecosystem

Once I understood MCP, I realized there’s an entire ecosystem growing fast:

Only for AWS - there is already plenty of choice --> AWS Labs MCP
Terraform
Atlassian (Jira and Confluence)
Github
MCP Servers
Awesome MCP Servers

There are plenty that can really be useful and boost how you use AI to work, but be careful and selective because you might find yourself in the first week you start using MCP servers with already a dozen installed!

Build your own

And of course, you can also build your own; the barrier to entry is very low:

Python (FastMCP)
with TypeScript (@modelcontextprotocol/sdk) or any language that speaks JSON-RPC over stdio or HTTP --> https://modelcontextprotocol.io/docs/sdk

In the next posts, I’ll show how we built our internal POC to showcase the concept to colleagues and management:
wrapping parts of our public API into an MCP server so AI tools could retrieve account information by simply chatting.

I’ll admit I was initially intimidated (that imposter syndrome never really goes away), but it turns out it’s not about “adding AI”, it’s about making your system AI-accessible.

From here, we’ll dive into the actual implementation.
As we’ll see, it’s easy to start, but moving from prototype to production takes care and design.
We’re not fully there yet, but we already have it running internally via AWS Agent Core Runtime.

Before we go deeper into building MCP servers, I need to introduce the tool that made this exploration possible at all: Kiro.

As the title of this series suggests, this journey happened Vibecoding in between meetings. Without the right AI setup, it simply wouldn’t have been possible to stay hands-on while juggling everything else.
In the next post, I’ll walk through how I set up Kiro (both the CLI and the IDE) cover its core capabilities (hooks, steering, and powers), and share the MCP servers, skills, and prompts that genuinely changed how I work with AI agents.
They didn’t just make the experience more enjoyable; they made my limited time far more effective.

Stay tuned.

No Time to Code: AI as Leverage for Engineering Leadership

Davide de Paolis — Mon, 26 Jan 2026 08:24:00 +0000

Let’s be honest: nobody gets into engineering and aspires to climb the career ladder - whether on the technical or managerial track—because they love meetings.

We get into software engineering because we enjoy solving problems. And we do that with code.

Of course, at some point - especially for EMs, Directors, and above - the problems become less technical and more strategic or people-oriented: how to lead the people who are solving technical problems.

Yet, as we progress in our careers, the time to do exactly that—solving problems through coding—seems to shrink year after year. Hard skills appear less required or less frequently applied (even though they remain the foundation of your work), while more and more soft skills are demanded. And we need those soft skills to navigate meetings.

Meetings for technical alignment, meetings for requirement specification, meetings for stakeholder management, meetings for architecture design and reviews, and so on.
Calendars fill up. Context switching becomes the norm. And quickly, you find yourself opening your IDE less and less—and when you do, it’s mostly to review other people’s code or to create documentation and diagrams.

Makers time vs Managers time

At some point, you might start asking yourself:

when was the last time I actually built something end-to-end?

This is one of the hardest truths of stepping up: Code becomes less important.

The expectation changes. You’re no longer measured by how much code you write, but by:

how you connect teams and domains
how you communicate with stakeholders
how you share knowledge
how you set direction and standards
how you amplify impact across the organization

And at that point, it becomes clear that it was never really about the code itself.
It was about the problems you solved with it.

Quote from this interesting episod of the Tech Lead Journal

At senior levels, you still solve highly technical problems - but differently:

You design systems, review architectures, reason about trade-offs, write RFCs and ADRs, guide others, and try to make decisions that will age well. For EMs especially, the focus shifts further toward delivery, team dynamics, and creating the conditions for teams to succeed.

Among all this "talking about work", the technical part often feels squeezed into the margins. So the question becomes: when do we actually “do the work”?

Why I Became Obsessed with Productivity and Simplicity

I have a confession to make: I am kind of lazy.
Not the type of laziness that makes me lie on the couch all day or shy away from responsibility and hard work. It’s a very specific kind of laziness. Especially when I don’t like doing something, I try to become so good and so fast at it that I can get it over with and move on as quickly as possible.

I never really loved coding for its own sake. I never found deep joy in typing brackets, semicolons, or chasing syntax errors. What I really hated were the headaches: trying to get a legacy project up and running, digging through outdated docs, obscure comments, convoluted logic, and unclear or inconsistent naming conventions.

I hate avoidable complexity and cognitive overload. I hate doing the same task over and over again.

Over time, that turned into an obsession with simplicity, quality, and productivity - not because I want to work less, but because I want to solve problems once and solve them well. And because I want to use my skills and brainpower for more important things.

That mindset is exactly why I’m very open — almost eager — to experiment with AI.
I didn’t jump blindly on the AI bandwagon. The hype does not carry me away, and I remain skeptical and cautious in many circumstances.

But the potential to reduce the tedious, boring, error-prone work that consumes so much of our time is undeniable. And that’s not all.

I genuinely believe AI can help all engineers:

Juniors, by providing structure and feedback
ICs, by accelerating implementation and iteration
Staff+ engineers and EMs, by reducing coordination and documentation overhead

Different stages, different leverage points.

For me, the real promise of AI isn’t “write more code faster.”
It’s enabling an AI-native SDLC that helps us think better, decide faster, and capture knowledge more effectively.

AI as a Multiplier of the SDLC

The Software Development Life Cycle (SDLC) has 6 core stages.

1️⃣ Requirement Analysis

Goal: Understand what needs to be built and why.
Activities: Gather business and technical requirements, define user stories or use cases, identify constraints and success criteria.
Output: Approved requirement specification or backlog.

2️⃣ System Design

Goal: Define how the system will meet the requirements.
Activities: Architecture decisions (e.g., microservices, cloud topology), data modeling, API/interface definitions, security and scalability considerations.
Output: Design documents, architecture diagrams, and tech stack choices.

3️⃣ Implementation (Development)

Goal: Build the product according to the design.
Activities: Code development, unit testing, version control, continuous integration, peer review.
Output: Source code with passing unit tests; deployable build artifacts.

4️⃣ Testing

Goal: Validate that the system behaves as expected and meets acceptance criteria.
Activities: Integration, regression, performance, and user acceptance testing (automated and manual).
Output: Quality‑assured release candidate.

5️⃣ Deployment

Goal: Deliver the working system into its target environment (staging → production).
Activities: Infrastructure provisioning, configuration, CI/CD pipelines, rollback strategy, deployment validation.
Output: Production system live and monitored.

6️⃣ Maintenance & Operations

Goal: Keep the system stable, secure, and evolving.
Activities: Monitoring, incident response, patching, scaling, feature enhancements, collecting feedback for the next iteration.
Output: Updated, reliable system with continuous improvement loop.

Each stage has specific activities and produces concrete artifacts. While often presented as a linear sequence, in reality these stages overlap, interleave, and repeat across multiple iterations.

Recently, there’s been a lot of discussion about how AI can boost the SDLC — both by improving individual stages and by fundamentally reshaping the lifecycle itself. This is where the idea of an AI-Driven Development Life Cycle (AI-DLC) comes in.

The AI-DLC is often simplified into three macro phases:

Inception: What are we building, and why?
Construction: How are we building it?
Operation: How do we ship and run it safely?

At each stage, the cycle repeats: plan, clarify, execute, approve.
The partnership between humans and AI is strong - and necessary -with humans remaining the input source and control gate.

Regardless of how your current development lifecycle looks, the key question isn’t the exact model. What really matters is how we leverage AI to do more, faster, and better - depending on seniority and on the level of zoom (a single feature, a bug fix, or a long-term product roadmap).

While ICs tend to focus heavily on implementation, testing, and maintenance, Staff+ engineers and EMs have much higher stakes in:

understanding the problem correctly
designing the right architecture
making and documenting good decisions
sharing knowledge clearly and consistently

And this is where AI can have a disproportionate impact.

AI can help:

structure vague or incomplete problem statements
explore architectural alternatives quickly
surface trade-offs and challenge assumptions
draft RFCs, ADRs, and best practices while context is still fresh
keep documentation and diagrams up to date
support learning when tackling unfamiliar (but not necessarily “new”) problems

Yes, AI can hallucinate. Yes, it needs steering. And yes, judgment still matters. But used critically, it dramatically speeds up learning, reduces friction, and lowers the cost of doing the right thing.

From "No time to Code" to "AI-DLC"

Although week after week I find myself further away from hands-on coding, I still love technical challenges. And it’s still my responsibility to steer my team toward building a high-quality platform for our engineering organization—meaning scalable and reliable cloud architectures, useful and easy-to-use modules, and clear documentation, best practices, and guidelines that empower engineers.
Between roadmap alignment meetings, 1:1s, hiring, agile rituals, and incident response, I’m left with very little time to support my team technically or review code and documentation.

So when an opportunity recently arose for my team to support our Data team in building and deploying a prototype MCP server integrating our API, I jumped on it. It was the perfect chance to start experimenting with an AI-native SDLC / AI-DLC while:

staying technically sharp despite a packed calendar
validating ideas through prototypes, not just discussions
reducing overhead around documentation and alignment

This series documents that journey — not as a polished playbook, but as learning in public.

In the next posts, I will start showing you how I set up my AWS Kiro IDE, how a AI-native SDLC actually looks like day-to-day, and how I began applying it in a real proof of concept.

More to come.

Useful Resources:

Other articles you might be interested in:

Header Picture: Me at AWS Community Day Rome 2024

Road To Compliance: Will Your Internal Users Hate Your Platform Team?

Davide de Paolis — Sat, 10 Jan 2026 09:19:55 +0000

Picture this: It's Thursday, 10:20 AM. You're the Engineering Manager of the Platform Team, and you've just called a "DevOps & Compliance Meeting." You announce new mandatory guidelines that must be implemented by next week, deployments will break without them, and no, this wasn't discussed with Product Managers. The room fills with frustrated voices: "Will this break our deployments?" "We already planned our sprint!" "Was this discussed with our PMs?!"

Sound familiar? This scenario plays out in engineering organizations everywhere (where security and platform teams often play the "cloud police"). And it's exactly where we found ourselves.

When I joined my current company to rebuild and grow the platform team, we were a cloud-native organization that had outgrown its single-account AWS setup. With 15 teams and ~80 engineers, we faced classic scaling challenges:

Operational Overhead: When you scale your organization from a handful of developers working on a monolith to multiple autonomous teams, operational and organizational overhead multiplies—monitoring, roadmap alignment, interfaces and contracts, backward/forward compatibility across services and APIs, security, and deployment pipelines all become more complex.

Compliance Chaos: How do you monitor compliance, enforce best practices, and attribute ownership and costs across a growing infrastructure?

Developer Friction: Every compliance initiative feels like extra work, new constraints, and broken workflows.

The previous platform team had literally burned out trying to build too much with too few resources. They were ambitious — dreaming of an Internal Developer Platform, a Service Catalog, a Cloud Center of Excellence. But fear of vendor lock-in led to over-reliance on self-hosted solutions. (I suggest this great post by Gregor Hophe about lock-in

Starting with the foundational choice of using Kubernetes to run our workloads (at least it was on AWS EKS), to basically everything else (image registries, access management, security scanning)—a plethora of self-hosted tools (Keycloak, Rancher, Longhorn, Harbor) had to be learned, configured, hosted, and maintained on our Kubernetes cluster. All of this burdened the small platform team, and they eventually collapsed under the weight of their own ambitions.

I am already strongly opinionated about Kubernetes - and that is the topic of another talk I co-hosted at several conferences last year too Serverless vs Kubernetes: the final showdown

Building the Foundation

We needed a fundamentally different approach. Our first step was establishing a proper multi-account landscape using AWS Organizations. This wasn't just about separation—it was about creating the foundation for everything that followed:

🗄 Isolation: Data, infrastructure, and access boundaries
🔒 Security Controls: Tailored policies for different applications
📊 Quota Allocation: Individual quotas for projects
💰 Cost Allocation: Separate billing and budgets by domain/team

To reduce operational overhead, we replaced self-hosted tools with AWS native services. This facilitated security and compliance while dramatically reducing the burden on our team.

The Human Challenge

Despite the obvious benefits to us and the security team, developers saw only:

Extra work
New setups
More constraints
Broken routines
Forced learning of new skills

Although frustration was building on our side as well (why did everything seem so difficult for the developers, despite our goodwill and efforts in supporting them?), we couldn't ignore the fact that all these changes were genuinely difficult. We were the ones literally responsible for "engineering enablement", so we couldn't just tell people: "We made this decision, here's the documentation, make those changes, live with it" especially when our documentation was overly detailed, extremely boring, and worse, often outdated.

We knew how to solve the technical challenges, but how were we supposed to support our initiative without solving the cultural ones?

Tagging: A Deceptively Simple Problem

We decided to revamp an old initiative that hadn't been particularly successful: tagging AWS resources. Per-se, this is a very trivial task, just add some key-value pairs to your resources. The reasons why tagging is crucial are:

Ownership Attribution: Who owns this resource? Who should we contact when issues arise?
Cost Allocation: Which team or project should be billed for this resource?
Access Management: IAM and resource policies can be scoped by owner tags
Incident Response: Quickly identify affected teams and applications
Compliance Reporting: Track resources by environment, sensitivity, and regulatory requirements

Early on, we made the mistake of treating tagging as "just metadata," assuming teams would adopt it once the rules were defined. That didn't work. Tagging only becomes effective when clearly connected to outcomes developers actually care about, like cost visibility, ownership, and faster incident resolution.

We started small by defining a minimal, opinionated set of required tags and making them easy to apply through infrastructure-as-code templates and platform defaults. Instead of enforcing everything upfront, we focused on visibility first: showing teams where tags were missing, what that meant in terms of cost and accountability, and how to fix it with minimal effort.

Over time, we gradually introduced stronger guardrails using Tag Policies and Service Control Policies, but only after teams understood the value and had the right tooling in place. The result was much better adoption, fewer exceptions, and a shared understanding that tagging wasn't "platform bureaucracy," but an enabler for governance and FinOps.

Let me dive into the technical details that made this possible. Understanding the differences between these AWS services is crucial for implementing effective compliance.

Tag Policies vs. Service Control Policies: Understanding the Difference

AWS Organizations Tag Policies: The Standardization Layer

Tag Policies help you standardize tags across your organization by defining allowed keys and values:

What Tag Policies do:

Define standardized tag keys across the organization
Specify allowed values for each tag
Validate tag values during resource creation
Provide compliance reporting on tag usage

Critical limitation:

They validate values but don't prevent resource creation without tags
Resources can still be created with missing tags
They're about standardization, not enforcement

Service Control Policies (SCPs): The Prevention Layer

SCPs provide hard enforcement by preventing actions that don't meet your requirements:

What SCPs do:

Prevent resource creation without required tags
Apply at account-level or OU-level
Cannot be overridden by any user or role in the account
Provide true enforcement of compliance policies

Critical challenge:

Can break deployments if not carefully implemented
Requires thorough testing before activation
Should only be enabled after teams are informed and prepared

The Key Difference: Validation vs. Prevention

Here's the crucial distinction:

Tag Policies say: "If you're going to use the 'Environment' tag, it must be one of these values: production, staging, development (not _prod, not live, not test)"

Service Control Policies say: "You cannot create an EC2 instance unless it has an 'Environment' tag."

This was all good and effective. But if we had simply rolled out those policies—informing teams a couple of sprints ahead and warning them that deployments would break without proper tags — we knew chaos would break loose. Teams were already stretched thin with product deadlines and feature commitments. They had little time, and even less interest, in making changes that didn't directly contribute to their goals. The tagging requirement would inevitably be forgotten, postponed, and only remembered when deployments failed at the worst possible moment.

Avoiding this scenario was the main cultural and collaborative change we wanted to introduce (compared to the previous team's approach).

Inform Before You Enforce

So instead of jumping straight to enforcement, we needed a different approach: detect untagged resources first, then inform teams about what needed to change and why.

The good news? AWS provides separate tools for informing and enforcing compliance. We could use Security Hub Resource Tagging Standard to detect issues and give teams visibility, then only later enforce the rules through policies once everyone was on board.

AWS Security Hub Resource Tagging Standard: The Detection Layer

The AWS Security Hub Resource Tagging Standard is a foundational security standard that became our compliance visibility engine. Here's what it actually does:

Core Capabilities:

Automatically discovers and evaluates resources across all AWS accounts
Checks for the presence of required tags on resources
Generates findings for non-compliant resources
Provides compliance scoring and trending over time What it doesn't do:
It doesn't prevent resource creation
It doesn't validate tag values (only presence)
It doesn't enforce anything—it only detects and reports

This was perfect for our "inform before enforce" strategy. We could see the compliance landscape without breaking anyone's deployments.

Security Hub Tagging Standard says: "Here are all the resources that don't have the required tags."

Understanding the differences between Tagging Standard, Tagging Policies, and SCPs is essential for implementing a phased compliance approach.

Our Three-Layer Governance Strategy

We implemented a comprehensive tagging governance strategy using these three complementary services:

Layer 1: Tag Policies (Standardization)

Purpose: Prevent tag chaos and inconsistency
Define allowed tag keys and values
Ensure consistency across the organization
Validate values when tags are present

Layer 2: Security Hub + Config (Detection & Reporting)

Purpose: Provide visibility and inform teams
Continuously monitor compliance
Generate findings for non-compliant resources
Track compliance trends over time

Layer 3: Service Control Policies (Prevention)

Purpose: Ensure compliance for critical resources
Prevent resource creation without required tags
Hard enforcement at the account/OU level

We activated these layers in sequence, not all at once.

The Soft Enforcement Process: Detection Without Disruption

Following the principle don't block deployments—detect and inform instead. we ended up not just using Tag Policies, SCPs, and Security Hub out of the box, but building a custom serverless solution that leveraged these services along with AWS Config, Lambda, EventBridge, SQS, and Chatbot to create two complementary enforcement mechanisms.

Solution 1: Real-Time Detection and Notification

Instead of blocking the deployment of untagged resources with SCPs, we allow them to be created but detect them immediately:

How it works:

AWS Config monitors all resource creation events in real-time
EventBridge filters for "ConfigurationItemChanged" events with "ResourceDiscovered" status, checking for missing mandatory tags
Lambda processes each finding to identify the owner by correlating:
- CloudTrail events
- CreatedBy tags
- Resource naming patterns
- CI/CD infrastructure metadata (GitHub Actions runs, etc.)
SQS buffers the findings to aggregate multiple resources from the same deployment (avoiding Slack spam)
AWS Chatbot sends a friendly but firm Slack notification to the responsible team: "Hey, we saw what you just deployed! It's missing tags, but we're letting it through for now. Here's how to fix it..."

The processing interval is carefully tuned — fast enough to provide timely feedback, but slow enough to batch related resources from the same CI/CD run.

Solution 2: Weekly Progress Reporting

For existing infrastructure and tracking overall progress, we built a separate reporting pipeline:

How it works:

EventBridge triggers a Lambda on a weekly schedule
Lambda fetches all Security Hub findings related to tagging compliance
Noise filtering removes:
- AWS-managed resources
- Temporary resources (spot instances, auto-scaling test instances)
- Resources in exempted accounts (sandbox, development)
Aggregation groups findings by team and calculates compliance metrics
SQS buffers the aggregated reports
Report generator creates:
- Jira tickets for teams to plan into their sprints [well.. actually were are not there yet!]
- Slack messages celebrating progress and thanking collaborative teams
- Gentle pokes for teams falling behind

Decoupling real-time monitoring from weekly reports gives teams a grace period. They can quickly add tags after deployment but before the weekly report runs.

This is soft enforcement — it doesn't slow down development, but it makes non-compliance visible and trackable. Teams can work "eventually compliant" by planning the automatically generated tickets into their regular sprints.

Lessons Learned

Why Previous Efforts Failed

Loss of focus on either goals or people
Over-engineering compliance controls without considering team experience
Not listening enough and imposing too much

What Works Instead

Focus on urgent and high-impact items first
Define clear purpose and iterate based on feedback
Combine automation, communication, and empathy
Mix soft and hard enforcement strategically
Make compliance visible and measurable without breaking workflows

The Phased Rollout That Actually Worked

Phase 1: Monitor Only (Security Hub)

Collect baseline compliance data
Identify patterns and common violations
Build team awareness through reporting
Start with a minimal set of required tags (3-4 tags max)
Gradually iterate and expand Tag Policies based on feedback

Phase 2: Soft Enforcement (Notifications)

Deploy real-time Slack notifications for new violations
Launch weekly progress reports and Jira ticket creation
Refine Tag Policies to add more allowed values as teams requested them
Iterate on tag requirements based on actual usage patterns
Continue to adjust and improve the tag schema

Phase 3: Selective Hard Enforcement (SCPs)

Activate SCPs only for critical resources in production accounts
Keep development/sandbox accounts with soft enforcement only
Gradual expansion based on compliance rates
Final iteration on Tag Policies to lock in the standardized schema

Key Insights from Our Journey

Our tagging compliance initiative taught us valuable lessons that apply to any internal compliance effort—not just tagging. Here's what we discovered:

Our approach has shifted compliance from a source of friction toward a more collaborative effort:

Proactive Communication: Teams now receive actionable, timely feedback when resources are created without proper tags
Visible Progress: Weekly reports show improvement over time, celebrating wins and identifying areas needing attention
Reduced Resistance: Informing before enforcing and empowering team champions has helped build trust
Ongoing Journey: Compliance is an ongoing process, not a one-time project—we're still iterating and improving

The technical implementation was the easy part. The hard part? The human factors. Here's what our experience highlighted:

1. Empower Team Champions

Instead of imposing rules from the top, empower champions within product teams to carry ownership of compliance topics. This scales your influence and reduces resistance.
(We're still learning how to identify and support these champions effectively. It's not a one-and-done activity—it requires ongoing investment and relationship building.)

2. Communication and Trust

Share your goals openly and adjust your approach as priorities shift. Make your communication style collaborative, not prescriptive. This means regular check-ins, transparent roadmaps, and being willing to say "we got this wrong" when feedback reveals issues.

3. Quick Wins and Momentum

Start with quick wins, build momentum, and iterate with patience and empathy. As Robin Sharma says:

"Change is hard at first, messy in the middle, and gorgeous at the end."

(We're still in the "messy middle" for many initiatives. Progress isn't linear, and that's okay.)

4. Tour of Duty Model

Involve representatives from engineering teams early through temporary rotations. Engineers join the platform team for a fixed period (or vice-versa), providing direct feedback while spreading platform knowledge back to their home teams.
This creates empathy in both directions — platform engineers understand product pressures, and product engineers understand platform constraints.

A Framework You Can Use

Our biggest realisation was how much the human factors mattered more than the technical implementation. The AWS services worked as expected (in a matter of days of development). The hard part was - and continues to be - building trust, communicating effectively, and maintaining empathy when teams push back.

Our Minimum Viable Governance framework can be applied to any internal compliance initiative—security policies, cost controls, access management, or anything else:

Define clear purpose and communicate it openly
Assess urgency vs. impact to prioritize efforts
Inform before you enforce using automated systems
Measure and communicate progress regularly
Iterate based on feedback from your internal users
Empower team champions to drive adoption

This isn't just about tagging. It's about how platform teams can drive any compliance initiative without becoming "the cloud police."

Conclusion: Compliance as a Collaborative Journey

The question isn't whether your internal users will hate your Platform Team — it's whether you'll give them reasons to.
The real work (for Platform Teams, DevEx teams, or even Security teams ) is understanding that compliance is fundamentally a people problem, not (only) a technology problem.

Your internal users are your customers too. Treat them with the same care you'd give external customers, and they'll become your biggest advocates rather than your biggest obstacles.

About This Post

This blog post is a written adaptation of my conference talk "Road to Compliance: Will Your Internal Users Hate Your Platform Team?" which I presented at several conferences throughout 2024 and 2025.

I wanted to document both our compliance journey and the content of the talk in written form, making it easier to reference and share with others facing similar challenges. While the live presentations included interactive discussions and Q&A sessions that brought additional insights, this post captures the core narrative, technical implementation details, and lessons learned from our experience.

If you prefer video format, you can watch recordings of the talk here:

Feel free to reach out if you'd like to discuss platform engineering, compliance strategies, or building better developer experiences!

Resources and Further Reading

The Culture Map: Book review and reflections from an EM Leading International Teams

Davide de Paolis — Tue, 06 Jan 2026 07:17:23 +0000

I’ve just finished reading The Culture Map: Breaking Through the Invisible Boundaries of Global Business by Erin Meyer, and I absolutely loved it because it finally explained my past 10+ years of international teamwork in a way that made me think: "oh… so THAT’s what was going on".

I’m currently an Engineering Manager leading a fully remote platform engineering team based in Germany, with team members from Germany, India, and Tunisia (and myself being Italian). Previously, I led a fully distributed team comprising colleagues from Egypt, Jordan, Ukraine, Turkey, and Brazil (a few were in Germany, living as expats, therefore with at least some exposure to German culture and international environment). And before that, I was working as Software Engineer in teams with people from Albania, Russia, Spain, Scotland and US.

Looking back, The Culture Map gave language, structure, and explanations to many situations that had previously caused confusion, frustration, and unnecessary friction.

This post is both a short summary of the book’s core ideas and a personal reflection on what I learned, sometimes the hard way, about leading across cultures.

The Eight Scales of the Culture Map

Erin Meyer describes culture not as a set of stereotypes, but as relative positioning across eight behavioural scales. Every culture sits somewhere on each scale, and misunderstandings often arise when we assume others are positioned where we are.

Very briefly:

Communicating: Low-context vs. High-context

How much is said explicitly vs. implicitly.
Some cultures rely heavily on context, shared understanding, and what is not said; others value clarity, precision, and explicitness.

Evaluating: Direct vs. Indirect negative feedback

How feedback, especially critical feedback, is given and most importantly, how comfortable people are with blunt criticism.

Persuading – Principles-first vs. Applications-first

How people build arguments: starting from theory and concepts, or from practical examples and concrete use cases.

Leading – Egalitarian vs. Hierarchical

How power distance shows up in teams, decision-making, and expectations toward managers.

Deciding: Consensual vs. Top-down

Who decides, and how much input is expected.

Trusting: Task-based vs. Relationship-based

Whether trust is built primarily through reliability and delivery, or through personal relationships and time spent together.
(by the way, speaking of performance and trust - here's a great video by Simon Sinek)

Disagreeing: Confrontational vs. Avoids confrontation

How openly people challenge ideas, debate, and express (and react to) disagreement.

Scheduling: Linear-time vs. Flexible-time

How people relate to time, deadlines, agendas, and plans.

Individually, none of these are good or bad. Problems arise when we unconsciously assume our position on the scale is “normal” and everything else is wrong - when we treat our way (explicit over implicit, structured over flexible, confrontational instead of harmony-seeking, task-focused instead of relationship-driven) as the only reasonable one, and everyone else must therefore be just rude, lazy, unreliable, dishonest, disorganised.

Why This Book Was Eye-Opening for Me

Reading this book felt like replaying old team interactions - so precisely that it was at times funny and embarrassing.
Many situations that had previously frustrated me, or others, were not about competence, motivation, or personality. They were about cultural mismatches we never made explicit.

What makes this especially interesting in my case is my own cultural mix.

I’m Italian (from the north, which already comes with footnotes), but I’ve lived for 18 months between Australia and New Zealand, and I’ve been living and working (with international teams) in Germany for over 13 years. In many ways, I’ve become more German than Germans:

I value clear scheduling and planning
I’m comfortable with direct disagreement
I trust through delivery and reliability

And yet… the Italian side still shows up loudly, sometimes literally.

I got that! Do you think I am stupid?

One of the first scales where I laughed out loud was high-context vs. low-context communication; because the example in the book described exactly how I (Italian, relatively high-context) tend to react when working with people from lower-context cultures like Germany or the US.

“Stop stating the obvious! We talked about that, you don’t need to repeat it three times and then send me a follow-up email.”

I find low-context communication overly specific, verbose, and sometimes even condescending or patronising, stating the obvious, adding excessive detail, recapping things that were clearly already understood (at least in my head).

When dealing with Americans and Germans I often found this style boring and unnecessary.
And yet with colleagues from Brazil, India or Giordan I often found myself thinking or asking:

“Why didn’t you ask immediately if it was unclear?”
“How could you miss the requirements so badly?”
“We talked about this! didn’t you get the decision we made in the meeting?”

From my perspective, it was obvious. From theirs, it wasn’t and they were often waiting for signals, confirmation, or shared context that I assumed was already there.
What I thought was clear, was, in fact, just implicit while what I perceived as over-communication was often just safety.

Understanding this scale helps adjust in both directions: being more explicit than feels natural to me, without assuming others are being pedantic or mistrustful.

Honest Feedback shock

I consider myself a fairly direct person, and I’m generally very open to criticism. But… in Italy we usually soften feedback, sometimes a lot. We dance around it. We add context, empathy, and occasionally so many disclaimers that the actual message risks getting lost entirely.

Germans, on the other hand, often separate ideas from people with almost surgical precision.

I still remember one of my first code design review meetings in Germany. I presented a solution and asked for feedback:

“What do you think of it?”

A German colleague looked at it for a moment and then very calmly said:

“Oh. That’s a silly idea. I don’t agree with that.”

No smile. No softener. No “but maybe we could…”

At that moment, I felt embarrassed and quite angry at that unnecessary rudeness. Over time, though, I learned to appreciate this style. There is no sugar-coating, no backstabbing, and no “everything is fine” in the meeting followed by complaints afterwards. You know exactly where you stand.

Of course, being polite, constructive, and specific still matters everywhere. But without cultural awareness, it’s very easy to feel personally attacked or to unintentionally attack others, when in reality, it’s just a different way of delivering feedback.

Winging It

Another chapter that felt painfully accurate: scheduling and meetings.
My meeting style was ( often still is ) very Mediterranean:

No agenda, just a vague title/topic of discussion.
Let the discussion flow
See where the conversation takes us
end when it feels right

That worked well with some colleagues but from germans I also received very clear feedback:

Calendar invites without an agenda (with time slots!) were confusing
Meetings that “derailed” were frustrating
Decisions and next steps were unclear

I still value some flexibility, but again, adapting to the context and being aligned on the expectations makes meetings dramatically more effective.

Disagreement and Expressiveness

One of the most mind-blowing chapters for me was about disagreeing and expressiveness and this is where I’ve had the most trouble in the past (and sometimes still do).

As an Italian, I:

Use my hands a lot
Change tone and facial expressions
Get passionate when discussing ideas

To me, this means: I care about the topic.
To others, it sometimes means: I am furious and attacking them personally.

I’ve had people (from Germany, UK or Russia) tell me later they were surprised that two minutes after a heated discussion, I was perfectly calm and even joking, with the same person I had the conflict with.
What felt like a lively debate about ideas to me felt like a distressing argument for others.

This can even become more complex:

Colleagues from Brazil or some Arab cultures may be even more expressive than Italians but handle confrontation very differently.

Colleagues from India or East Asian cultures may find open disagreement overwhelming or inappropriate.

I recently experienced this again while traveling in Thailand. I was surprised and honestly annoyed by how impossible it is get a clear “no.” Instead, refusals were phrased in ways that sounded like a “yes,” which was incredibly confusing to me.

The book helped me see that this wasn’t dishonesty or avoidance but a deeply ingrained cultural approach to harmony and face-saving.

Same Same, But very different

The main takeaway of the book is that

We are all the same and we are all very different.

Individual personality matters a lot. But cultural traits absolutely play a role, often subconsciously.

Leading international teams feels to me like another level of situational leadership: understand, adapt, and make the implicit explicit.

Situational leadership is the idea that there is no single “best” leadership style. Effective leaders continuously adapt their approach (directing, coaching, supporting, delegating) based on context, the people involved, their experience, the situation, and the environment.
Leading international teams simply adds another dimension to this: culture. What motivates, reassures, or challenges someone in one cultural context may confuse or discourage someone in another. The core skill, then, is not knowing all cultures perfectly, but being curious, adaptable, and willing to adjust your default behavior.

This also means practising humility, especially when pointing out the idiosyncrasies of other cultures, while acknowledging our own.

"They" are not

Rigid: they value structure
Disorganised: they operate in flexible time
Unreliable: they prioritize relationships
Confrontational: they separate ideas from people

Labelling people based on our own cultural lens is easy but dangerous.

From Awareness to Practice

Awareness alone is not enough. What really matters is collectively discussing and agreeing on how we work together. This book showed me that talking about these differences explicitly as a team is crucial.

I’ve used Team Canvases (sometimes called Team Charters) many times to define vision, purpose, roles, and stakeholders. But I never thought of using them to align on

Communication styles
Feedback expectations
Meeting norms
Decision-making
Disagreement and escalation

Although recently, I’ve also introduced Manual of Me / Personal Readmes to support onboarding and mutual understanding. Now I see how well these practices complement the ideas from The Culture Map.

I think in the near future I will start introducing in 1:1s the book and the 8 dimensions of the culture map and then have a team session to discuss altogheter and position ourselves on the culture map. I found a great Miro Template to facilitate the session and I will likely update this post with some sort of form/cheat sheet to facilitate the discussion.

Final Thoughts

The Culture Map is an outstanding book that should be on the shelf of anyone working with or within international teams.

It doesn’t give simple answers but it provides us with a shared language to talk about differences without judgment.

And sometimes, that alone can save you from yet another meeting where everyone leaves slightly confused, mildly offended, and convinced the others are just… weird.

Highly recommended.

Vibecoding in Between Meetings: Learning MCP Servers and Building a PoC ( with AWS Kiro)

Davide de Paolis — Fri, 19 Dec 2025 03:19:52 +0000

A few weeks ago, an opportunity came up for my team to collaborate with our datascience team on a small prototype: building and deploying an MCP server. Nothing massive. No big roadmap commitment. Just a chance to explore something new and see if it could be useful.

I took it. Not only because the topic was interesting, but because it gave me an excuse to do something I don’t get to do often anymore: get my hands dirty again.
I wanted to learn how MCP servers actually work, what capabilities AWS AgentCore offers (and what / alternatives exist) and whether this whole AI-native development hype holds outside inspirational talks and LinkedIn influencers' posts.

It also felt like a good opportunity to experiment with an AI-native SDLC in practice, not just as a concept, but as a way of working.
I used AI to structure my learning, bootstrap experiments, and iterate on ideas quickly. Partly for myself, and partly to understand how this could help drive AI adoption more broadly across our organisation.

This experience sparked two ideas:

This would make a good conference talk
I should write about it while it’s still fresh, messy, and honest and create a serie of posts where I learn in public.

The Talk (Rough, Temporary Abstract)

Vibecoding in Between Meetings: Building & Deploying MCP Servers with Kiro and Agent Core Runtime

Engineering Managers and Staff+ engineers often share the same fate: back-to-back meetings while the builder inside silently screams. This talk explores how adopting an AI-Native SDLC helped me reclaim my building time—allowing me to learn a new topic, structure my exploration, and build a proof of concept in the gaps between meetings.

We’ll go from zero to deployed: starting with a simple stdio MCP server, evolving it into an HTTP MCP server, validating everything with the MCP UI Inspector, and finally deploying it on AWS using Agent Core Runtime. Along the way, we’ll lean on Kiro agents, personas, and prompts as well as MCP servers, to accelerate learning loops, automate documentation, and capture architectural decisions.

I’m hoping to bring this talk to a conference sometime next year. This series is, in many ways, the raw material for it.

Where We Are Right Now

We’ve just wrapped up phase one of the proof of concept:

A first stdio MCP server
its HTTP version, run locally on docker and tested with MCP Inspector
then deployed on our AWS infrastructure with AgentCore Runtime

That’s a solid foundation—but there’s a lot we haven’t explored yet. AgentCore has more components we need to understand. Costs and operational pitfalls need to be evaluated. And most importantly, we need to figure out how (or if) this fits into our actual product.

Which is why this series isn’t a fixed plan.

What’s Coming (Subject to Change)

Here’s the rough structure I’m starting with. The content and even the number of posts may change as development continues over the next month or two.

From “No Time to Build” to an AI-Native SDLC
Getting Started with Kiro: Setup, Powers, and Steering the AI
MCP Servers Explained: The Missing Layer Between AI and Your Systems
Vibecoding a First MCP Server: Building a stdio MCP for Internal Use
From stdio to HTTP: Evolving an MCP Server with FastMCP
From Local to the Cloud: Running MCP Servers on AgentCore Runtime
Beyond the Runtime: Gateway, Identity, and Memory in Agent Core

Some posts may split. Others may merge. New ones might appear as we uncover things we didn’t expect especially around integration, security, and cost.

If you’re an Engineering Manager, a Staff+ engineer, or anyone trying to stay technically sharp despite spending your days trapped in meetings, I hope you find this series interesting and useful. My goal isn’t to present perfect solutions: it’s to show how (if?) AI can really become a Multiplier - helping us learn faster, validate earlier, and building again, even when time is scarce.

Let’s see where this goes.

My 2025 Year in Review - Conferences, Community, and Growth as an AWS Community Builder and Leader

Davide de Paolis — Tue, 16 Dec 2025 13:58:32 +0000

2025 has been an intense, fulfilling, and transformative year for me — as an Engineering Manager, public speaker, and AWS Community Builder, filled with conferences, community contributions, flights, new experiences, and meaningful connections.

It has also been a year of growth: as a leader, as a communicator, and as part of a global technical community that energises me every day.

Below is my look back at the journey.

Kicking Off the Year in Milan - AWS Community Day Italy

The conference season started on 2 April 2025, when I flew to my original hometown, Milan, to speak for the second time at AWS Community Day Italy.

There, I presented: “Road to Compliance: Will Your Internal Users Hate Your Platform Team?” a talk where I shared the journey of my team at sevdesk: how we implemented internal governance, operational guardrails, and FinOps in a way that didn’t create frustration or friction with engineering teams.

Enforcing rules consistently while still supporting autonomy is a delicate balance. The challenge is never purely technical - empathy, communication, and a customer-centric mindset play an essential role.

We covered how services like AWS Security Hub, AWS Config, SCPs, and Tagging Policies help automate compliance and reduce risk, while preserving trust and collaboration inside the company.

AWS Summit Hamburg - Something Different

On 5 June, I supported the selection of speakers for the Community Stage at AWS Summit Hamburg.
My own talk didn’t make it this year - which honestly happens to all of us - so I embraced a new challenge instead.

I worked at the AWS Community Builders booth, talking to attendees about the program, sharing my experience, and explaining why it’s such a powerful career accelerator. (by the way - applications for 2026 will open soon - check here for a great guide about how-to)

And then I stepped onto a different stage entirely:
for the first time, I put on the mic and headphones to introduce another speaker and moderate the Q&A.
It felt awkward not hearing myself or the audience, but incredibly fun and rewarding.

AWS Community Day Poland and AWS community Day Netherlands

On 18 September in Warsaw, at AWS Community Day Poland, I presented (with Tiago Bilou) Serverless vs Kubernetes — The Final Showdown:

A lively, no-holds-barred debate about two polarising cloud approaches.
We talked about complexity, scalability, costs, security, legacy modernization, and event-driven architectures.
The room, set in a cinema, was packed, around 350 people, despite other big-name speakers presenting at the same time.
I wrote a post about the talk and why such a debate was a great learning experience.

A few days later, on 24 September, I brought the same talk (this time with Damiano Giorgi) to AWS Community Day NL in Utrecht - again in a cinema, again in front of a huge, energetic audience.

Come to Code - A Conference Like No Other

From Utrecht, I flew straight to Basilicata in Italy for Come to Code, where I gave my “Road to Compliance: Will Your Internal Users Hate Your Platform Team?” talk again.

But the event itself deserves a special mention.

This conference was magical.
Maybe because it lasted two and a half days, giving us time to truly connect. Maybe because of the shared lunches, the drawing and crochet workshops 🧶, the walk in the woods, the retro gaming corner (including ChatGPT on a Commodore 64!), or the live concerts in the town square.
Maybe because speaking in my native language hit differently.

Everything was perfect - pizza nights, a Bavarian dinner, the “Cloud Taboo” game, the AWS Builder Cards, Lucanian food and drinks, music, laughs, deep conversations with other Engineering Managers, and the huge passion of 180 people who travelled to a small southern Italian mountain town on a weekend.

The organisers deserve infinite applause for the logistics, the hospitality, and the heart they put into every detail.

AWS Community Day DACH - Behind the Scenes

On 7 October, I sadly could not attend AWS Community Day DACH - too many conferences this year and packed into a few weeks.
However, as part of the AWS Community DACH Association Booster Club I again joined the selection committee for talks.

My own submission wasn’t selected this time, but the process is always inspiring, fair, and full of incredibly well-crafted abstracts.

InfoQ Dev Summit Munich - Beyond AWS

On 16 October, I presented again my “Road to Compliance: Will Your Internal Users Hate Your Platform Team?” talk at InfoQ Dev Summit Munich, a highly professional, multi-platform conference — not just AWS-centric.

A highlight was moderating the “Birds of a Feather” discussion/panel on Platform Engineering, which was a brand-new experience for me.

On the train back to Hamburg, I wrote a blog post summarising my impressions and the talks I attended.

Closing the Conference Year at DevFest Hamburg

My last event of the year was 14 November, back home in Hamburg.

With Tiago Bilou, I delivered “Serverless vs Kubernetes — The Final Showdown” at DevFest Hamburg—on the Container Stage, in front of an audience mostly focused on Google Cloud.

It truly felt like an away game.
But architecture principles are cloud-agnostic, and we were welcomed with great curiosity and engagement.

The engineering community is inclusive everywhere — no matter the cloud provider.

A Feature on The Serverless Advocate

I was also featured in the Serverless Advocate Newsletter by Lee Gilmore, in the “Ask the Expert” section, where I shared experience, tips, and practical advice for engineers working with serverless.

Writing Less, But Writing Deeper

This year I didn’t publish as many technical articles - partly because the Engineering Manager role limits deep hands-on exploration, and partly because the conference season was incredibly busy.

But I did write pieces I’m proud of:

A follow-up to an old post about being a Multiplier—one of the reasons I became an EM and Community Builder.🌊 Be the Rising Tide: The Multiplying Effect of Lifting (and Pushing) Others
A reflection on imposter syndrome, vulnerability, and personal growth, inspired by moments where I cried at work—and why that’s not weakness, but honesty and humanity. Discomfort isn’t the enemy: Lessons from 3 times I cried at work

Internal Impact - Building Communities at Work

Not directly part of AWS Community Builders, but still related to sharing knowledge:

I gave a talk on Observability and Incident Management at our company onsite in March: “From DevOoops to SRE.”
I launched internal Guilds and Tech Communities.
With support from the AWS Enterprise RAMP-UP program, I organised workshops for our engineers on Amazon Q, SQS & EventBridge, and Microfrontends, delivered by AWS experts.

These were some of the contributions I’m most proud of.

My Speaking Goals for 2025 — and The Reality

I started the year with two goals:

Speak at 6 conferences.
Speak at least once outside AWS-focused events, ideally on leadership topics.

I achieved the first goal — though only barely.
Until August, I thought I’d miss it.
Then September and October arrived with 4 conferences in 30 days.

I sincerely hope conference organisers coordinate better in the future — autumn is becoming impossibly crowded!
I had to decline 4 accepted CFPs and withdraw from 5 evaluations because of scheduling conflicts.

Just as a reminder for anyone struggling with CFPs: I was rejected by 15 events this year.
Keep refining your abstracts. Make them personal, relevant, and clear. Rejection is part of the process.

My second goal — speaking about leadership — didn’t happen.
My talk on DORA Metrics and high-performing teams didn’t get accepted this year.
But I’ll keep improving it and try again in 2026.

Looking Back - And Ahead

2025 was exhausting, energising, emotional, and unforgettable.
It reminded me why I love being part of the AWS Community and the broader engineering world:

Sharing knowledge makes us all better.
Speaking publicly creates connections that last.
Helping others grow amplifies our own growth.
And community - real community - happens when people bring passion, vulnerability, curiosity, and kindness.

Here’s to another year of learning, building, speaking, and lifting others. And to the AWS Community Builders program, which continues to be an incredible catalyst for personal and professional growth.

See you in 2026.

From Nagging to Holding People Accountable

Davide de Paolis — Mon, 15 Dec 2025 07:36:00 +0000

One of the many great things about meeting people at conferences and networking is that the inspiration doesn’t stop when the event ends. It continues later, while scrolling through my LinkedIn feed: sometimes it’s just a thought, a leadership gem, or an engineering tip. Sometimes it’s a thoughtful blog post about a hot topic (recently: overly-present MCP servers, or Lambda durable functions). Often, it’s a reading suggestion.

I love books and I read a lot (still not as much as I’d like and I’m actively working on reducing my screen time in favour of good old paper). I almost never read literature or novels; my shelves are mostly filled with books on communication, leadership, productivity, goals, engineering, or the journeys of athletes and adventurers.

So when I came across Crucial Accountability: Tools for Resolving Violated Expectations, Broken Commitments, and Bad Behavior by Patterson, Grenny, McMillan, Switzler, and Kerry on LinkedIn, I bought it immediately.

Unspoken Expectations, Repeated Demands

I’m ambitious, demanding, and hold a pretty high bar — for quality and speed. I’m also direct, sometimes too direct, immediately pointing out what hasn’t met that standard. This “radical candor” doesn’t always land the way I intend.
Sometimes I walk away frustrated, unheard, and feeling I am becoming a serial nagger — at work as at home with my teenagers. Resentment builds, and conversations become less effective over time.

So yes, the book’s back cover spoke directly to me:

Broken promises, missed deadlines, poor behavior — they don’t just make others’ lives miserable; they can sap up to 50 percent of organizational performance.

What I really wanted to learn was:

How can I express expectations without sounding judgmental?
How can I create safety and show that I care — not only about goals and commitments, but also about people?
How can I hold others accountable and protect the relationship?

From Silence or Violence to Skill

The authors highlight a common accountability trap: when things go wrong, people often swing between silence (avoiding the issue to preserve harmony) and violence (pushing too hard and escalating tension).
Neither works. Silence breeds resentment. Violence triggers defensiveness or shutdown.

Understanding Accountability: (CPR)

The book defines accountability as something that should happen “early, often, and skillfully.”

Everything starts with understanding what kind of accountability problem you’re dealing with.
The authors' CPR model (Content, Pattern, Relationship) offers a helpful lens for diagnosing what kind of problem you’re facing:

Content: A single instance of a missed expectation (“You missed yesterday’s deadline.”)
Pattern: A recurring problem (“This is the third missed deadline this month.”)
Relationship: When trust or reliability is at stake (“When deadlines are missed, it’s hard for me to rely on you.”)

The key rule: start with the lowest level needed (Content → Pattern → Relationship) and escalate only if the problem persists.

This was a big insight for me. If you jump straight to Pattern or Relationship on a first occurrence, you risk overreacting and appearing unfair or aggressive. On the other hand, if you ignore patterns, resentment builds until the relationship itself is at risk.

It also reinforced how important it is to address issues early, before they pile up.

Master Your Story

When a promise is broken — especially repeatedly — we tend to turn the other person into the villain of the story. We tell ourselves stories that label them: they’re just lazy or selfish, they don’t care, they’re simply incapable.

“Mastering your stories” means separating facts from assumptions ( from the stories we tell ourselves) and choosing explanations that keep us curious rather than judgmental.

It’s about telling the whole story, not just our part of it.
Instead of starting from blame, we gather facts and enter the conversation with genuine curiosity:

What actually happened?
What might I be missing?

This shift alone changes the tone of the conversation dramatically.

Describe the Gap

To hold people accountable, they must clearly understand the expectation and the gap.

That means describing, without labels or judgment:

What was expected
What actually happened

No vagueness. No character assessments. Just observable facts.

Contrasting: Saying What You Don’t Mean

One tool I found extremely useful — and one I rarely use — is contrasting - a technique to defuse defensiveness.

I used to avoid it because it feel like I am justifying myself, that I am approaching the conversation walking on egg-shells, or worse, that I am anticipating what people would then use against me as an excuse.
But contrasting is powerful when used well:

“I’m not saying you’re unreliable. I am saying this deadline was important, and missing it put the project at risk.”

This simple structure reduces fight-or-flight responses and keeps dialogue open even when things are tense.

The 6 Sources of Influence

This was the most eye-opening part of the book for me.

If someone isn’t performing, at least one source of influence is failing.

Your job isn’t to blame, it’s to diagnose and fix.

The six sources fall into two categories:

Motivation (Do they want to?)
Ability ( Can they? )

Each category has three dimensions:

Personal
Social
Structural

Examples that really resonated with me:

“If others routinely miss deadlines too, it makes sense this feels optional.”
“If speed is rewarded more than accuracy, this behavior is being encouraged.”

I always knew multiple factors were at play—peer pressure, incentives, organizational values — but this framework gave me a concrete way to ask better questions.

Understanding whether it’s a motivation or ability issue (and at which level) helps tailor the solution:

Make it Easy: Remove barriers and assume good intent.
Make it Motivating: Clarify impact, purpose, and feedback loops.

It reminded me of the “blameless postmortem” mindset: if the system allowed the error, the problem lies in the system.

Agree on a plan (WWWF)

After the conversation, we want improvement. Behavior change doesn’t happen without clarity.
To move from talk to action, the authors propose a clean framework that made me laugh at first. The acronym is WWWF. I initially read it as WTF — because honestly, sometimes my inner voice still says: "Wtf, just do your part!"

WWWF: Who will do What by When —and how you’ll Follow up.

It’s simple, explicit, and powerful.

Stay Focused and Flexible

This might be my personal mantra. It sounds contradictory, but it’s often the key to success: the magic lies in balancing focus (keeping commitments) and flexibility (adapting wisely when priorities shift).
People often justify broken commitments with “something more urgent came up.” That’s not laziness but lack of clarity about priorities.
People think they are being flexible by prioritising something else, and in teams like mine - plagued by low capacity and constant firefighting - they are being kind and helpful (willing to help and unblock others).

The solution isn’t just better tools (Eisenhower Matrix, impact/effort charts), but also a simple agreement:

If something comes up, come to me first. Then we decide together whether it’s time to be focused—or flexible.

Focus and flexibility also matter for the person holding the conversation. If new information emerges, adapt. Maybe there’s a bigger problem to solve first. Maybe you need to pause and come back later to restore safety and avoid derailment.

Final Thoughts

“Hold others accountable by addressing gaps early, focusing on facts, diagnosing motivation vs. ability, and ending with clear commitments — while maintaining mutual respect.”

That’s the essence of Crucial Accountability.

The real value, though, lies in how practical it is. I really enjoyed the last section of the book, which walks through concrete scenarios and how to handle them. The chapter titled “No Yeah, But..._s” made me smile — I had that exact thought many times while reading: _All good, yeah… but this won’t work with my teen, or with that low performer I once managed.

The self-assessments helped me see where I am and where I can improve, and I appreciated the additional free resources:

The book also connects beautifully with other books I’ve read in recent years:

Radical Candor - Be a Kick-Ass Boss Without Losing Your Humanity (balancing care and challenge - the traps of obnoxious aggression and ruinous empathy)
Nonviolent Communication: A Language of Life (expressing needs without blame)
The 4 Stages of Psychological Safety by Timothy R Clark (contrasting, flexibility, curiosity)

This book didn’t just give me tools — it gave me language, structure, and a mirror. I read it, underlined it, circled entire sections, added bookmarks and folded corners so that I can go back to it when I need it. When my books look like that in the end, it's the mark of a truly useful read.

Am I doing the best I can? Thoughts about talent, mediocrity, expectations and success.

Davide de Paolis — Mon, 24 Nov 2025 07:14:00 +0000

“È bravo, ma non si impegna.” ( “He is very smart, but if he put in more effort, he could achieve so much more.” )

This sentence followed me for my entire childhood.
I was a good student: good grades, good results, never the best, but good. And I studied. A lot, in my opinion.
Yet the feedback always carried that same message:

“You could have gotten an A… if only you had worked harder.”

Sometimes I even got worse grades than classmates who had identical results because they “worked hard”, so they were rewarded, while my work was discounted and attributed to “talent.”

I can’t say whether those comments shaped who I am today, or whether something deeper was already there. Pushing me to always do something more - although I always knew I could put in more effort.

But the reason I didn’t give “everything” is simple:
Good enough was, simply, good enough.

Somewhere in my head, there has always been a calculation:

What is the right effort/result ratio that still allows me to enjoy life?

If studying one hour gives me a B and 30 minutes of play… why study 90 minutes to get an A and lose that joy?

This is something I’ve realised even more since becoming a father ( and while reflecting on my climbing goals).

I could definitely climb harder - if I gave up some joy.
Climb 20 minutes more each session instead of enjoying a beer with my climbing partners.
Skip a fun climbing day in favour of painful, boring weight lifting and stretching.
Avoid indulging in food and alcohol.
But… would all that be worth it?

My son recently got the same remark (he's good but could put in some more effort) from his teachers, and he also stopped getting on the podium in climbing competitions.

He’s still top 10 in Germany - but he achieves that with the right amount of effort, while staying a happy, social kid, who alongside hard trainings and competitions, plays an instrument, does well in school, and has friends and a life.

Some children sacrifice everything for one goal. Some parents push their kids to go all in on a single bet.

He doesn’t. I didn’t.
And I’m not sure that’s a flaw.

Proudly Mediocre

Recently I stumbled upon a short reel by Mauro Corona - climber, writer, sculptor - talking about being “proud of being mediocre.”
He says:

“To excel at one thing, I would have had to throw away years of my life…
And I only have one of those.
So I ended up being mediocre — but I did everything I loved doing.”

Here the video

And suddenly everything clicked.

Life is too short to sacrifice variety for perfection, being mediocre at 10 things can be more valuable than being the best at one. Because diverse experiences compound into something far richer.

And let’s be clear, Mauro Corona is anything but mediocre! He is an incredible man, with a strong character and lots of stories.
He just consciously chose breadth over obsession.
And so, in a way, did I.

But Then Comes the Other Voice: “You Could Do More.”

Despite everything, that teacher’s voice still echoes somewhere:

“You could do more.”
“You should do more.”
“You’re not doing enough.”

And this connects to something else that often bothers me: untapped potential.

That awareness that if you want to excel at something, you must commit fully. And if you don't put in 110%, it feels like a pity!

The responsibility of luck

This conflict became even clearer when I read the book:
“I Must Do That, Because I Can.” (Devo perche’ posso) by the mountaineer Simone Moro.

If life gives you the gift of talent, opportunity, and luck, you feel a duty to honour it by doing something meaningful with it.
If chances are handed to you, you must catch them.
You have a responsibility not to waste them.

This resonates deeply with me:

I know I am lucky.
Lucky to have opportunities, resources, health, support, the ability to learn and grow.
Lucky to have challenges worth pursuing.

And this is where the tension lives: I know I have untapped potential and I could accomplish much more - therefore I feel grateful and guilty at the same time.

But then I remind myself that giving 90% across multiple domains is not wasting my potential. It is choosing a full, rich, multidimensional life.

Still, these thoughts push me, especially at work and in parenting.
I set a high bar for myself and, admittedly, for others too. With the downside that I often end up frustrated, disappointed, and exhausted.

Constraints, Expectations, and Excellence

An ex-colleague who was leaving for “greener pastures” told me something that made me think, about ambition, agency and acceptance. About understanding that no matter how high my expectations are, I operate within real constraints:

How much time I have
How many resources are available
How much support and collaboration I can expect
How quickly others can deliver their part
How much of the system can I realistically influence

Maybe the version of excellence I envision is not what the current context requires.
Maybe what I could achieve in ideal conditions is irrelevant; what I could achieve at full potential is not what is needed now.
Maybe it’s not even desired.

Accumulating frustration about “what could be” is pointless and damaging; the resentment is visible and it impacts morale and performance, mine and others’.

Love It, Change It, or Leave It

I am not someone who gives up easily. I try to change things first.
But I also need to focus on what I can control, what I can influence, and what I must accept.
Until I manage to change a situation, the choice is simple:

Love it — or leave it.
Focus on what I can control.
Influence what I can influence.
Let go of the rest.

And if I choose not to leave — not now, or not ever — then the healthiest thing I can do is love it as it is, not as it would be under perfect conditions.

Turning constraints into catalysts

Focusing on what I can do within real constraints allows me to acknowledge effort and success, instead of always staring at the gap.
To be proud of what I accomplish within the actual boundaries I face — not imaginary ones.

Constraints force priority.
Constraints sharpen focus.
Constraints make expectations realistic.

They become not the reason I underperform, but the reason I choose the right things to perform on.

"Maybe excellence isn’t doing everything at 110%, but choosing where 90% is actually impactful.”

And here’s something I say with humility, not arrogance - with gratitude rather than pride:
I know that even when I operate at 80–90%, it often looks like “a lot” from the outside.
Not because I’m exceptional, but because my baseline has been shaped by years of habits, curiosity, and luck — luck in the opportunities I've had, the people who supported me, and the challenges that pushed me.
That’s exactly why I must stay mindful of expectations: What feels natural to me isn’t necessarily fair, realistic, or healthy to expect from others.
And as a leader I’ve learned (almost) that expecting permanent 110% from myself or others is unsustainable.

It hurts morale.
It hurts quality.
It hurts people.

Learning to choose my effort deliberately has made me more effective, not less ambitious.

I am grateful for the chances life has given me.
I do feel the responsibility to honour them.
Therefore, I constantly push myself — sometimes too far, sometimes not far enough. But it's fine, as long as I keep on growing.

I’m proud of being many things — a software engineer, a climber, a father, a community builder, a leader, a writer, a public speaker and a curious human — even if I’m not world-class in any single discipline.
Mediocre snowboarder, mediocre engineer, mediocre climber — maybe.
But I got to be all of them.
And that breadth has shaped me far more meaningfully than mastery of one.
All those experiences compound, and choosing a full, multi-dimensional life is the most honest way I can honour the luck I was given.
Not by squeezing every drop of potential into a single pursuit, but by living widely, intentionally, gratefully.

Maybe that’s my version of excellence.

Be the Rising Tide: The Multiplying Effect of Lifting (and Pushing) Others

Discomfort isn't the enemy

Serverless vs Kubernetes: The Final Showdown - Why we decided to hold this talk and where to go from here

Davide de Paolis — Wed, 19 Nov 2025 08:45:00 +0000

In the past 8 years, I mostly built serverless applications, then joined a company running its workloads on Kubernetes. The transition for me was hard, and since I stayed in contact with an old ex-colleague who on the other end, spent his career building on containers and on-premise k8s in particular I often reached out to him to understand Kubernetes, and more than occasionally, rant about it.

In response, he shared his frustrating experiences in attempting to run serverless applications - both from cold starts and costs perspectives.

That's how we came to the idea of writing a Talk about this and presenting it at Conferences.

Every engineering team has heard, or been part of, the endless “Serverless vs. Kubernetes” debate. Strong opinions are thrown around, memes circulate on LinkedIn, and blanket statements spread like wildfire. And like all stereotypes, they are true and false at the same time.

The truth? Much of the conversation is oversimplified, emotionally charged, and disconnected from the reality teams face when building and operating software at scale.

Our talk, and this article, is our attempt to bring nuance back into the discussion.

Too often we watch people compare these two paradigms the way you’d compare Car-Sharing to owning a car

Both models are valid. Both are powerful. And neither can replace the other across all use cases.

The real question is not “Which one is better?” but Which one is better for this workload, with this team, in this organisation, at this time?”

In our talk we go through several aspects and try to debunk them.

Control vs. Complexity

Kubernetes gives you:

precise control over deployments
resource scheduling (CPU, GPU, affinity rules)
hybrid/on-prem/cloud consistency
advanced rollout patterns and self-healing

Serverless gives you:

minimal configuration
"infrastructure you don't manage"
the fastest path to shipping business logic

But control comes with cost:
A typical Kubernetes stack isn’t just k8s. It’s:

Ingress controller
Service mesh
Metrics stack
Logging stack
Secrets manager
Autoscalers (HPA, VPA, CA, Karpenter...)
Backup tools
Certificate management
Policy/OPA
CI/CD integrations

So you don't just have to tame the Kubernetes beast; you also need to understand and manage an ecosystem of several critical open-source tools.

Serverless shifts much of this burden to AWS (or GCP/Azure), leveraging the shared responsibility/fate model.

Automagical scaling

Serverless: “I don’t want to be bothered.”
K8S: “We’re a large org; we must be bothered.”

Scalability in K8S works with Autoscalers (HPA, VPA, CA, Karpenter, EKS Automode), but each solves a different slice of the scaling problem. And each introduces configuration overhead.

Serverless scalability feels magical until you hit concurrency quotas or encounter cold starts.
Because Lambda does have constraints in reality:

Account/Regional concurrency limit
Scaling rate = 1,000 new execution environments every 10 seconds
Requests per second limit (10k RPS per 10 seconds)

and you indeed to understand how they work and how to use

Reserved concurrency
Provisioned concurrency

Cost is too often misunderstood

When comparing serverless and K8S on high-volume apps (~4B requests/month) it seems obvious who the winner is. By the thousands ( of $$$ ).

But the key missing factor is:

The most expensive resource isn’t compute. It’s people.

If you need:

platform engineers
k8s experts
observability specialists
SRE practices
on-call rotations
tooling ownership

…you must include those in your cost model.

A Kubernetes cluster may be cheaper than Lambda…
but is it cheaper than hiring two expert platform engineers?

I would rather pay for 2 more engineers developing our business logic and adding value to the product.

Long-Running Processes and Application Modernisation

Most detractors of serverless usually then mention Lambda’s 15-minute timeout and Lift & Shift as deal-breakers.

But this assumes you build long-running monolithic workloads.
while Serverless is, for me, primarily a mindset. Once you start seeing things from a Serverless perspective, things look different and you might not even have such problems.

Because serverless offers alternative patterns:

Task chunking
SQS fan-out
Event-driven pipelines
Step Functions (with workflows lasting up to a year)
Checkpointing/state transition events

And because Lift and Shift does not address the architectural and technical challenges that are pushing your organisation into modernisation. Serverless and the Strangler Fig pattern do!

API Gateway + Lambda façade
Gradually carve out endpoints
Migrate at your own pace
Avoid rewriting the entire system upfront

Serverless modernization is incremental.
Kubernetes modernization is infrastructural.

Different problems, different solutions.

So… How Do You Choose?

Organizational factors trump technical ones.

You should ask:

What is our current team capable of supporting?
Is our priority speed, cost, stability, or control?
What are the budget constraints ( predictability vs cost per transaction )
What are the company priorities, direction and budget ( survival, growth, innovation )?

The smartest teams don’t argue over technology choices.
They ask: “Which architecture best serves our workload and our organization right now?”

And instead of fighting over paradigms, we should be learning from each other—teams that build scalable serverless systems and teams that run rock-solid Kubernetes platforms.

Both worlds have powerful ideas worth sharing.

Your turn: Help us expand the conversation

I don't want to go too much into detail because I don't want to spoil the talk, as I hope after presenting it already at AWS Community Day Poland and Netherlands, as well as DevFest Hamburg, I hope we will be able to visit many other conferences in 2026.

But since the talk sparked a lot of interest during these conferences, I would like refine and deepen it further.

👉 Which technical aspects would you like us to explore next?

Kubernetes autoscaling internals
Hybrid architectures (EKS + serverless)
Evolutionary architectures
EDA patterns and Migrating from monolith to event-driven?

Or maybe you disagree with something we said.
Perfect — tell us!

Drop your thoughts, critiques, and questions.
Your input will help shape Version 2 of our talk.

Know your tendencies - Questioning yourself (and others)- The 4 Tendencies Framework

Davide de Paolis — Wed, 22 Oct 2025 15:50:54 +0000

Recently, our People & Culture team shared something in our Learning Nuggets Slack channel: “The Four Tendencies” quiz, a framework by Gretchen Rubin that explores how people respond to expectations.

The premise is straightforward: we all face external expectations (from others) and internal expectations (from ourselves). The way we respond to these defines which of the four tendencies we belong to:

Upholders

“I do what others expect of me—and what I expect from myself.”

They meet both outer and inner expectations with discipline and consistency. Their motto: “Discipline is my freedom.”

Obligers

“I do what I have to do. I don’t want to let others down, but I may let myself down.”

They readily meet outer expectations but struggle with self-imposed ones.

Questioners

“I do what I think is best, according to my judgment. If it doesn’t make sense, I won’t do it.”

They turn all expectations into inner ones. They comply, if you can convince them why.

Rebels

“I do what I want, in my own way. If you try to make me do something, even if I try to make myself do it, I’m less likely to do it.”

They resist both outer and inner expectations alike.

My Result ( No Surprise!)

When I took the quiz, the result didn’t surprise me.
To some extent, I somehow longed and feared coming out as a Rebel, but the description of the Questioner fit almost perfectly.

I don’t suffer from analysis paralysis (anymore): I’ve learned to embrace the AWS Leadership Principle “Bias for Action.” I also love the quote by Dr. Ellen Langer:

“Rather than waste your time being stressed over making the right decision, make the decision right.”

That resonates deeply with how I approach both work and life.

Understanding the Questioner

The more I read about this tendency, the more I recognised myself in it, sometimes smiling, sometimes grimacing.

Questioners:

Value logic, reason, research, and fairness above all else.
Question all expectations and comply only if they believe the reasoning is sound.
Trust authority only when they respect the authority’s expertise.
Can appear uncooperative or defiant because of their relentless questioning.
Hate arbitrary rules (“Five garments per fitting room” drives them mad).
Often dislike being questioned themselves.
Sometimes struggle to delegate because they doubt others will act with enough urgency or thoughtfulness.

This was spot on, and I absolutely loved the line:

“They wake up and think, ‘What needs to get done today—and why?’”

That’s exactly how my brain starts every morning.
But a few of these points really made me pause and think.

Disliking being questioned (yes, the irony)

When someone challenges my decision, there’s an instant internal reaction:

“Do you think I didn’t research? Do you think I’m talking without thinking? Do you think I am stupid?”

It’s not arrogance, but a reflex, a consequence of my awareness of how much thought I put into my own decisions.

I am open to feedback, and I can change my mind quickly when proven wrong. But I realise that this initial defensiveness can make me seem less open than I actually am. It’s something I need to pay attention to, especially my tone ( and likely my facial expressions).

Authority and Expertise

I follow authority only if I trust its expertise — and for me, that usually means technical expertise.
That’s been one of my biggest leadership challenges.
Sometimes I still feel I need to prove my technical ability to deserve respect, even though my role now is no longer about being the most technical person in the room.

Learning that influence and impact don’t always require technical authority, literally letting go of that has been an ongoing process.

Delegation and Trust

I sometimes hesitate to delegate decision-making because I worry others won’t have the same bias for action.
And yes, I’ve been burned before by people who took ages to decide, or made poor choices after endless deliberation.

But I’m learning that leadership isn’t about optimising every decision, it’s about enabling others to grow, even if that means tolerating inefficiency in the short term.

And that (as arrogant as it may sound), as David Farley said in this amazing and inspiring talk:

Allow team members freedom to do a worse job than you would

I know these kinds of tests are far from being scientifically rigorous; they’re as valid as horoscopes.
We answer based on how we see ourselves (or how we want to see ourselves), and the results are kind of blanket statements - they can always be true at some point for someone.

Still, I love what they provoke: reflection.
They make me see myself and others through slightly different lenses.
(If you’ve ever read “Surrounded by Idiots”, you know the value of such frameworks when used as mirrors, not labels)

Growth and Acceptance

One line from Gretchen Rubin’s website resonated deeply because it feels like the essence of growth:

“We can accept ourselves and also expect more from ourselves.”

I often get frustrated by the oversimplified messages in personal growth, self-help or mental health content that say: “Just accept yourself as you are.”

Yes, acceptance matters. But acceptance doesn’t mean stagnation.
I accept who I am today, and I’m also committed to improving not because I think I’m bad, but because I strongly believe in getting better.
The desire to improve does not always come from insecurity, a negative feeling of inferiority or guilt (although I also wrote about that in my post Maybe you should start listening to that voice telling you that YOU SUCK!, it can simply be inspired by what we see around us.

Probably I have been strongly shaped by the sports I have always practiced in my life: skateboarding, snowboarding, slacklining, climbing. Sport where failure is a constant, where progress comes from repetition, discipline, and yes, a bit of pain. You master one move, then immediately start working on the next, harder one.
And you start learning that failure is giving up, or not even trying, not not achieving your goal. You will, at some point, and right around the corner, there will be a new challenge.

So, understanding that we can always improve, it's not self-rejection, it's evolution.

Maybe personality frameworks like The Four Tendencies aren’t about boxing ourselves in.
Maybe they’re about understanding the forces that drive us, so we can work with them, not against them.

And as a lifelong Questioner, that’s enough reason for me.