DEV Community: maria tzanidaki

How I Passed the AWS Certified Security – Specialty Exam on My Second Attempt

maria tzanidaki — Tue, 11 Aug 2026 12:00:00 +0000

I recently passed the AWS Certified Security – Specialty certification, but this was not my first attempt.

I had taken the exam once before and did not pass. Although that was disappointing, it helped me identify my knowledge gaps and understand how the exam approaches complex security scenarios.

Instead of treating the first attempt as wasted time, I changed my study strategy, returned to my notes, and focused on how AWS security services work together.

This time, I passed—while on maternity leave and studying between feeds, naps, and everything else that comes with becoming a first-time mother.

Here is what helped me.

About the Exam

The current AWS Certified Security – Specialty exam, SCS-C03, includes 65 multiple-choice or multiple-response questions and lasts 170 minutes.

It covers six domains:

Detection – 16%
Incident Response – 14%
Infrastructure Security – 18%
Identity and Access Management – 20%
Data Protection – 18%
Security Foundations and Governance – 14%

You need to understand more than individual service definitions. The exam tests whether you can select the best solution for a complete security scenario.

My Background—and My Blind Spots

I work as a Cloud Infrastructure Engineer and regularly use AWS, Terraform, EC2, IAM, VPC, monitoring, and Infrastructure as Code.

However, professional experience alone was not enough.

In my daily work, I mostly use Terraform, so I underestimated how much attention I needed to give to CloudFormation and other AWS-native governance tools.

The Topics I Would Know Inside Out

Although every exam experience is different, I would pay particular attention to four areas.

Service Control Policies

Understand SCPs in depth.

An SCP defines the maximum available permissions for accounts or organizational units, but it does not grant permissions.

Study:

SCP inheritance
Explicit denies
Organizational units
Member accounts
Central security guardrails
How SCPs interact with IAM policies

Always distinguish between granting access and limiting the permissions available across an organization.

Permissions Boundaries

A permissions boundary defines the maximum permissions that an IAM user or role can receive. It also does not grant permissions by itself.

Remember the main difference:

An SCP limits permissions at the account or organization level.
A permissions boundary limits a specific IAM user or role.

Make sure you understand how permissions boundaries interact with identity-based policies, resource-based policies, session policies, and SCPs.

Amazon GuardDuty

Know GuardDuty beyond its basic definition.

Focus on:

Multi-account management
Delegated administrators
AWS Organizations integration
Finding types and severity
GuardDuty protection plans
Integration with Security Hub
Automated responses through EventBridge and Lambda
Differences between GuardDuty, Inspector, Macie, Detective, and Security Hub

GuardDuty detects suspicious activity, Inspector identifies vulnerabilities, Macie discovers sensitive data, Detective supports investigations, and Security Hub aggregates findings.

These differences should feel natural before the exam.

AWS CloudFormation

Do not ignore CloudFormation—even if you mainly work with Terraform.

I focused on:

CloudFormation service roles
StackSets
Multi-account and multi-Region deployments
CloudFormation Guard
Drift detection
Secure parameters
AWS Organizations integration
Consistent security controls through Infrastructure as Code

This was one of my biggest gaps during my first attempt.

Other Important Areas

I also reviewed:

IAM policy evaluation and explicit denies
Cross-account access and role assumption
AWS KMS, key policies, and grants
CloudTrail and centralized logging
Security Hub, Inspector, Macie, and Detective
Incident response and forensic evidence
VPC security, WAF, Shield, and Network Firewall
AWS Organizations and Control Tower
AWS Config and automated remediation
Secrets Manager and Parameter Store
Encryption at rest and in transit

I organized my notes in Obsidian and created comparisons between services that could easily be confused.

The Resources I Used

I used the official exam guide to structure my preparation and studied through the QA AWS Certified Security – Specialty SCS-C03 learning path.

My preparation combined:

The official SCS-C03 exam guide
The QA learning path
AWS documentation
Obsidian notes
Practice questions
Knowledge from my daily AWS work

Whenever I answered a practice question incorrectly, I tried to understand why the correct answer was better and why the other options failed to satisfy the requirements.

Request the Extra 30 Minutes

If English is not your native language and you take the exam in English, request the ESL +30 MINUTES accommodation before registering.

AWS offers non-native English speakers an additional 30 minutes. You only need to request it once for eligible future AWS exams.

This is particularly useful for an exam with long, detailed scenarios.

You can request it from your AWS Certification account under Request Exam Accommodations.

My Online Exam Setup

I prefer taking AWS exams online from home because it is extremely convenient. I do not need to travel to a testing center, and I can choose an appointment that fits my schedule.

I usually book my exams in the morning. The Security Specialty exam is already 170 minutes—and can reach 200 minutes with the ESL accommodation—so I prefer to begin when I am rested and focused.

I normally take the exam in my bedroom instead of my office because my office has multiple external monitors. Pearson OnVUE allows only one active monitor, and additional monitors must be unplugged or removed.

Using my laptop in another quiet room is much easier than rearranging my entire office setup.

Before the exam, I make sure that:

The room is private and quiet
Nobody will enter
The testing surface is completely clear
Only one monitor is active
My laptop is connected to power
The internet, camera, and microphone work correctly
I have completed the OnVUE system test

Remember that during an online AWS exam, you cannot leave the camera view—even for a break.

Final Advice

If I were preparing again, I would:

Start with the official exam guide.
Know SCPs and permissions boundaries in depth.
Study GuardDuty until its integrations feel natural.
Spend more time on CloudFormation.
Practice IAM and KMS policy evaluation.
Compare similar AWS security services.
Request the ESL +30 accommodation.
Schedule the exam when I am well-rested.
Prepare my online testing space in advance.

Failing once did not define my final result. It simply showed me what I needed to improve.

My study schedule during maternity leave was not perfect. Some days I studied more, while on others I reviewed only a few Obsidian notes.

Progress was not always fast, but it was still progress.

If you do not pass on your first attempt, review your gaps, adjust your strategy, and try again.

That is what I did—and this time, I passed.

Useful Resources

Thinking About Becoming an AWS Community Builder? Here’s What You Should Know

maria tzanidaki — Sat, 08 Aug 2026 18:46:32 +0000

When I first discovered the AWS Community Builders Program, I assumed it was mainly intended for established content creators, frequent conference speakers, or people who were already well known within the AWS community.

I was wrong.

The program is not about having the largest audience or knowing everything about AWS. It is about being genuinely curious, sharing what you learn, and helping others move forward in their cloud journeys.

Today, I am proud to be part of the AWS Community Builders Program in the Serverless category.

During my first year, I have probably learned far more than I have contributed. Between maternity leave, becoming a first-time mother, studying for an AWS certification, and trying to find a new rhythm, some of my community plans naturally moved more slowly than I expected.

Receiving my AWS Community Builder welcome kit gave me exactly the push I needed to become more active, share what I have learned, and give something back to this wonderful community.

If you have ever wondered whether you are experienced, visible, or “ready enough” to apply, this article is for you.

What Is the AWS Community Builders Program?

AWS Community Builders is a global program for people who are passionate about AWS technologies and enjoy exchanging technical knowledge with others.

Its members come from many different backgrounds. They include cloud engineers, developers, solutions architects, students, content creators, user group organizers, and people who are simply enthusiastic about building and learning with AWS.

Community Builders contribute in many different ways, including:

Writing technical articles and tutorials
Creating videos and live streams
Building open-source projects
Sharing GitHub repositories
Speaking at conferences and meetups
Answering questions in technical forums
Organizing workshops and study sessions
Publishing educational content on social media
Supporting local cloud communities

There is no single “correct” way to contribute.

You do not need to become a YouTuber, launch a podcast, or speak at a major international conference. What matters is finding a format that suits you and using it to create genuine value for other people.

Who Can Apply?

According to the official AWS Community Builders page, anyone aged 18 or older who is passionate about building on AWS can apply.

You do not need to hold a senior position, work for a large technology company, or have thousands of followers. Students, beginners, career changers, and experienced professionals can all bring something valuable to the community.

What can strengthen your application is evidence that you are already sharing your knowledge publicly.

This could include:

A blog post explaining an AWS solution
A tutorial based on a real problem you encountered
A public GitHub project
A technical presentation or workshop
A video demonstrating an AWS service
Helpful answers in technical forums
Participation in an AWS User Group
Educational posts that make complex topics easier to understand

A small number of thoughtful and original contributions can say much more about you than a large amount of generic content.

At the time of writing, applications are still being accepted. If you are considering applying, this is a good time to organize your public contributions and tell your story.

What Did I Include in My Application?

Before applying, I had delivered two technical talks—one at the AWS User Group Thessaloniki and another at the AWS User Group Athens.

My presentations focused on Amazon EC2 and practical AWS topics based on real tasks and situations I encounter in my daily work as a Cloud Infrastructure Engineer.

I believe this is important because your contributions do not need to be based on abstract or overly advanced topics. You can share the problems you solve at work, the decisions you make, the approaches you follow, and the lessons you learn along the way—provided that you do not disclose confidential company information.

Real-world experience can make technical content more practical, relatable, and useful to others.

Those two talks demonstrated that I was willing to step outside my comfort zone, share what I knew, and actively participate in my local AWS community.

You do not need dozens of talks or articles before applying. A few genuine contributions that clearly demonstrate your interest and community involvement can provide a strong foundation.

You Don’t Need to Be an Expert

One of the biggest misconceptions is that you must already be an AWS expert before you can contribute.

You do not.

Some of the most useful technical content comes from people who have recently solved a problem and still remember exactly which parts were confusing.

You can document:

What you were trying to build
Which approaches you considered
What did not work
How you identified the problem
What finally solved it
What you would do differently next time

That learning process has real value.

For example, while preparing for my AWS certification, I discovered several gaps in my own knowledge. The exam was strongly focused on CloudFormation, while most of my daily infrastructure-as-code work is based on Terraform.

I did not pass on my first attempt.

However, that first attempt showed me exactly what I needed to study more deeply. When I eventually passed, the result was important, but the notes, scenarios, mistakes, and lessons I collected along the way were even more valuable.

Those lessons can now become articles or practical guides that may help someone else avoid the same confusion.

You do not have to wait until your journey looks perfect before you start sharing it.

What Makes a Strong Application?

A strong application should make it easy for the reviewers to understand three things.

1. What Are You Genuinely Interested In?

Choose the category that reflects your real interests, professional experience, and the subjects you want to explore further.

Do not select a category simply because it sounds popular. Your application will feel more authentic when it is connected to the work you actually do and the topics you naturally enjoy discussing.

I joined the Serverless category because it gives me the opportunity to learn, experiment, and share more about building applications and solutions without managing traditional server infrastructure.

Your chosen category does not have to represent every part of your professional experience. It should represent the area in which you would like to participate, learn, and contribute within the program.

2. How Are You Helping Others?

Show how your contributions support other people.

Perhaps your tutorial saved someone several hours of troubleshooting. Maybe your repository provides a reusable example. Your presentation may have introduced beginners to a difficult concept, or your post may have encouraged someone to attempt a certification.

Community impact does not always have to be measured through thousands of views.

A meetup talk delivered to a smaller local audience can still create meaningful conversations. An article read by only a few people can still help someone solve a real technical problem.

Helping even a small audience in a meaningful way matters.

3. Are Your Contributions Genuinely Yours?

Your personality and perspective are part of the value you offer.

Avoid trying to sound like every other technical writer. Explain concepts in your own way, include lessons from real projects, and be honest about challenges or mistakes.

Originality does not mean discovering something nobody has ever discussed before. It means adding your own experience, understanding, and voice to the conversation.

How to Prepare Your Application

If you are interested in applying, do not wait until the last moment to begin your community journey.

Start now.

Create a Consistent Public Identity

Set up your AWS Builder ID and try to use a consistent name across the platforms where you publish.

This makes it easier for reviewers and other community members to recognize your work and connect your different contributions.

Choose a Subject You Genuinely Enjoy

Focus on an area that connects with your real interests or professional experience, such as:

Serverless
Cloud Operations
Containers
Security
Networking
Storage
Data
AI and Machine Learning
Infrastructure as Code
DevOps
Developer Tools

A clear focus helps people understand what they can learn from you, but it does not prevent you from exploring other AWS topics.

My previous talks focused on Amazon EC2 and topics related to my daily work, while I am now part of the Serverless category. Your existing contributions and the direction in which you want to grow do not always have to be identical.

Publish Useful Public Contributions

Create two or three strong pieces of work that clearly represent your knowledge and willingness to help.

Quality matters more than publishing as much content as possible. One detailed article based on a real technical problem can be more valuable than several rushed or generic posts.

If writing is not your preferred format, you could deliver a meetup talk, create a video, share a useful repository, or contribute to a technical discussion.

Keep a Record of Your Work

Save the public URLs of your articles, repositories, videos, talks, event pages, and other contributions.

When you complete your application, you will already have your strongest examples organized and ready.

For talks and community events, keep links to event announcements, presentation materials, recordings, or public posts that confirm your participation whenever possible.

Tell Your Real Story

The application is not only a list of links. It is also an opportunity to explain why you contribute, what you have learned, and what being part of the community would mean to you.

Be concise, specific, and honest.

You do not need to exaggerate your achievements or present yourself as someone who never encounters difficulties. Your real progress, motivation, and willingness to help are more meaningful.

There Is Room for Honest Mistakes

It is also worth knowing that there is some room for genuine mistakes during the application process.

In my case, I accidentally submitted two applications.

I completed my first application without a referral. When I later received a referral, I submitted a second application so that I could include it.

Submitting two applications was not ideal, and it is certainly not something I would recommend. However, the AWS team did not criticize or disqualify me because of it.

They understood that it was an honest mistake, and I was still accepted into the program.

Review your application carefully before submitting it, but do not allow the fear of making a small mistake to stop you from applying. Behind the process, there are real people who understand that applicants are human too.

What Do AWS Community Builders Gain?

The program provides access to learning resources, educational opportunities, networking, and connections with AWS experts and community members from around the world.

Depending on the current program cycle, members may also receive additional resources, recognition, community activities, or other benefits.

Since these benefits can change, applicants should always check the official AWS Community Builders page for the latest information instead of relying on lists from older articles.

The most important benefit, however, is difficult to measure.

It is the opportunity to meet people who are learning, building, experimenting, and sharing just like you.

Being surrounded by an active technical community can expose you to new ideas, encourage you to leave your comfort zone, and give you the motivation to turn your private notes and experiences into something useful for others.

My Advice to Future Applicants

Do not create content only because you want to add links to an application.

Share because you encountered something worth explaining.

Share the answer you wish you had found when you were stuck. Document the mistakes that taught you something. Turn your notes into a guide that makes another person’s journey a little easier.

Most importantly, do not reject yourself before AWS has the opportunity to review your application.

You may be a student, a beginner, an experienced engineer, a career changer, or a parent trying to find time between new responsibilities. None of these prevents you from becoming a meaningful member of a technical community.

I am a Cloud Infrastructure Engineer, a first-time mother currently on maternity leave, and an AWS Community Builder in the Serverless category.

Before applying, I shared parts of my professional experience through two talks about Amazon EC2 and practical AWS topics at the AWS User Groups in Thessaloniki and Athens.

During my first year in the program, I focused more on learning than contributing. My journey has not always moved as quickly or perfectly as I would have liked, but I am still here, still learning, and now ready to share more and give back to this wonderful community.

If I can be part of this program, why not you?

Start with one useful contribution. Then create the next one.

Your community journey may have already begun before you even realized it.

Useful Links

Check this out!

maria tzanidaki — Sat, 21 Mar 2026 01:56:07 +0000

Tetiana Mostova for AWS Community Builders

Mar 8

AWS Strands Replaced 40 Lines of LangGraph With 3. Here’s the Full Story

#agents #ai #aws #llm

5 min read

From Seen to Responded: A Small Guide to Respectful Replies in Tech

maria tzanidaki — Wed, 11 Feb 2026 11:13:03 +0000

We’re surrounded by notifications: Slack, email, Teams, LinkedIn, WhatsApp, calendars, tickets, and more. No one can answer everything instantly, but we can all get better at replying eventually in a respectful way.

I’m definitely guilty of delayed replies myself. I’ve opened messages, thought “I’ll answer later,” and then remembered days afterward. The goal isn’t perfection. The goal is to build simple habits so people don’t feel ignored.

Why Replies Matter More Than Speed

Most people don’t need an instant answer; they just need to know they haven’t been forgotten.

Thoughtful communication helps because it:

Reduces anxiety and guessing (“Did they see it?”, “Did I say something wrong?”).
Keeps work moving by making expectations clear.
Builds trust and a healthier team culture over time.

A short “Got it, I’ll check and get back to you” is often enough. It’s not about long messages; it’s about acknowledgement.

My Own Rule: Late Is Better Than Silent

Since I know I can be slow to reply sometimes, I try to follow a simple personal rule:

Late is okay.
Completely silent is not.

When I realize I’ve delayed too much, I still reply with something like:

“Sorry for the late response, last week was packed. Here’s my answer…”
“I missed this earlier, thanks for your patience…”

It’s surprising how often people respond kindly when you just acknowledge the delay honestly.

Practical Tips to Be More Responsive

Here are a few small habits that help me respond more consistently without burning out:

Use “micro‑replies”: A quick “Received, will review tomorrow” keeps things moving while you stay focused.
Batch your responses: Set 1–2 blocks a day to clear Slack DMs, emails, or LinkedIn messages instead of context‑switching all day.
Use reminders or stars: Mark messages you can’t answer now and schedule a reminder to revisit them.
Set expectations early: If you’re in a busy period, tell people: “This week is heavy, replies may be delayed, but I’ll get back to you.”
Close the loop: Even when the answer is “no” or “we’re not moving forward,” send a quick note so others aren’t left hanging.

These are small actions, but they add up to a more respectful and predictable way of working together.

A Note on Hiring and HR

One area where this matters a lot is interviews and hiring. People invest time, energy, and emotion into interviews. Even a short message like “We’ve decided to move forward with other candidates, but thank you for your time” makes a big difference.

I try to remember that on the other side of every message—whether it’s a colleague, candidate, recruiter, or connection—there’s a real person who appreciates closure, even if the answer is “not now” or “not this time”.

The Culture We Create With Replies

Every reply we send (or don’t send) shapes the culture around us.

By:

Acknowledging messages, even briefly
Owning our delays honestly
Saying “no” instead of disappearing

…we create a work environment where people feel respected and informed, not ignored.

We don’t need to be perfect communicators. But we can all be a bit more intentional, one reply at a time.

How Many Jira Tickets Does a "Good" Engineer Close Per Week?

maria tzanidaki — Wed, 04 Feb 2026 21:16:14 +0000

Obsessing over ticket velocity misses the point, but benchmarks may exist.

Why Tickets/Week Isn't Everything

Raw count is misleading:

20 trivial bugs ≠ 3 complex tasks
Story points matter more than ticket count (baseline: 5-10 pts/engineer per 2-week sprint)
True throughput = completed tickets/week with quality + reasonable cycle time

Reality check: 1 ticket/day (5/week) is a sustainable pace; spikes to 10+ during bug triage weeks are normal but unsustainable.

DevOps-specific: Infrastructure tickets may take longer especially if there is more than one team involved in decision making.

What Drives Higher Throughput

1. Ticket Sizing (The Goldilocks Rule)

Too Big (>1 week): Split → Epic → Stories → Tasks
Too Small (<4 hours): Batch into 1-day tickets
Just Right: 1-3 days each → 2-5/week sustainable

Teams breaking work into 1-day tasks can hit 25 tickets/week/team.

2. Workflow Hygiene

WIP limit: Keep "In Progress" <5 tickets
Cycle time: Target <7 days per ticket
Automation: CI/lint/tests cut review time by 50%

3. Context Switching Tax

Juggling 3+ tickets/day wastes 40% of productivity. Focus deeply on 1-2 at a time.

Red Flags vs. Green Flags

Red Flags

Low velocity (<3/week):

Oversized tickets (not broken down)
Blocked >3 days consistently
Poor estimation skills

High but fragile (>12/week):

Bug-only work (tech debt accumulating)
Skipping tests/reviews
Burnout risk

Green Flags

5-8 quality tickets/week + deploy frequency >weekly + low rework rate = healthy velocity.

Jira Native Metrics

Velocity Chart: Average completed points/week
Control Chart: Cycle time trends
Burndown: Sprint commitment tracking

The Bottom Line

Good engineers optimize for impactful velocity (deployed value/week), not raw ticket count.

What matters more:

Are you shipping features or just closing tickets?
Is your cycle time improving?
Are you reducing blockers quarter over quarter?

Focus on sustainable throughput with quality—not vanity metrics.

I took a look on scrum.org to elaborate my thoughts on this : https://www.scrum.org/scrum-kanban
https://www.scrum.org/forum/scrum-forum/31862/story-points-complexity-vs-effort

Blocked Tickets Kill Momentum—Here's the Systematic Fix

maria tzanidaki — Tue, 27 Jan 2026 13:57:03 +0000

Tickets stuck in "In Progress" for more than 10 days? Blockers unresolved for over 5 days? These red flags signal flow breakdowns—and they're entirely preventable. Elite engineering teams don't panic when these situations arise; instead, they deploy proven escalation protocols and systematic interventions. No fluff, no guesswork—just actionable steps that restore velocity and unblock your pipeline.

Why Red Flags Matter

Work stuck in intermediate states costs more than you realize. Every day a ticket languishes in "In Progress" represents lost context for developers, risk of scope creep, team demoralization, and delayed value delivery. Blocked work compounds the problem: stakeholders lose confidence, dependencies pile up, and what should have been a 2-day task balloons into a 3-week nightmare.

The difference between high-performing teams and average ones? Early detection and systematic response.

Diagnose Red Flags Daily

Red flags don't appear overnight. They accumulate silently until they derail your sprint. Catch them early with structured daily checks.

Daily Standup Diagnostic:

- In Progress >7-10 days: Is this a skill gap? Unclear requirements? 
  Multitasking splitting focus?
- Review >5 days: Is the reviewer overloaded? Are feedback loops 
  broken? Is communication stalled?
- Blocked >3-5 days: External dependencies? Missing information? 
  No escalation assigned?

Implementation: In your daily standup, explicitly call out tickets approaching these thresholds. Flag them visually in Jira (yellow card + red icon). Document the blocker reason and estimated time to resolution in comments. This creates accountability and visibility—two things that kill silent failures.

Response 1: Swarm the Bottleneck

When a ticket hits 7 days in "In Progress," the solution isn't to wait—it's to swarm.

The Swarm Protocol:

Assign 2 developers to the ticket (30-60 minutes daily until resolved).
Structure it intentionally: Pair the stuck developer with a senior engineer or someone from a different team. This brings fresh perspective and unblocks thinking.
Cross-train as you go: The junior developer learns from real-time problem-solving.
Break large work into subtasks: If the ticket is epic-sized, decompose it immediately.

Why it works: Solo work often stalls because one person lacks context, hits a wall, and spins in circles. A second pair of eyes identifies the real blocker in minutes. Real-world impact: teams report 50-70% faster resolution when swarming vs. grinding alone.

Real Example: A database migration ticket that would've taken 21 days solo? Swarmed on day 8 with a database expert. Resolved by day 12.

Response 2: Escalate Blockers Systematically

Blocked work is the fastest way to poison team morale. Without escalation protocols, blockers fester. With them, they vanish.

The Escalation Timeline:

Day 1-3: Blocked status → Daily sync with block owner assigned.
Day 3: Create daily standups focused on the blocker alone if needed.
Day 5: 15-minute escalation call (developer + stakeholder).
  - Vendor delay? CC management + attach SLA reminder.
  - Data access missing? Ping requester + explore workarounds.
  - Environment issue? File infra ticket immediately with priority tag.

Documentation: Log every escalation step in Jira comments for audit trail and pattern recognition. Set up automation (detailed below) to notify stakeholders on Blocked >3 days.

Why structure matters: Without timelines, blockers drift. With them, you create urgency and accountability.

Response 3: Enforce WIP Limits Ruthlessly

Work-in-Progress (WIP) limits prevent the chaos of too many simultaneous tasks. They force focus and expose bottlenecks.

When Your Column Hits Capacity:

Pause new pulls: No new tickets enter "In Progress" until the column is under limit.
Root-cause the blockage: "What's actually preventing closure? Is it review? Testing? Deployment?"
Swarm the oldest ticket first: Finish one ticket completely before starting the next.
Document the violation: Record why the limit was breached and what lesson applies (e.g., "Reviewer bottleneck—rotate reviewers" or "Environment access delays—add auto-provisioning").

Handling Emergencies: Production incidents override WIP limits—document them and treat them as learning opportunities. If you're violating limits chronically, reduce your WIP limit by 20% and investigate why throughput is constrained.

Example: If your "In Progress" limit is 5 and you have 7 tickets, stop everything. Pick the oldest 5, swarm them to completion, then pull the next batch.

Response 4: Weekly Red Flag Retros

Every Friday, spend 15 minutes reviewing aging tickets. This ritual prevents small problems from becoming culture problems.

Analyze Trends: Plot the data over weeks. Is "In Progress" spiking? You have a throughput or clarity problem—hire, train, or break down work smaller. Are review delays consistent? Rotate reviewers or implement async code reviews. Is "Blocked" growing? Strengthen your escalation protocol.

Action items come out of every retro: Assign owners, set due dates, track to completion.

Response 5: Automate Alerts & Visualize SLAs

Humans forget. Automation doesn't. Set up automated notifications to catch aging work before it becomes a crisis.

JQL Automation Rules (Using ScriptRunner or native Jira Automation):

status = "In Progress" AND updated <= -7d → 
  Post Slack message to #blockers channel with ticket link

status = "Blocked" AND updated <= -3d → 
  Email stakeholders + PM with status and escalation request

status = "Review" AND updated <= -5d → 
  Notify reviewer + author to reconnect

Board Improvements:

Add a "Blocked/Red Flags" swimlane at the top of your Kanban board for instant visibility.
Color-code aging tickets: yellow at 5 days, red at 10 days.
Display cycle time metrics on the board so the team sees the cost of delays in real time.

Metrics to Track:

Average time in "In Progress" (target: <5 days).
Average time in "Review" (target: <3 days).
Blocker resolution time (target: <3 days to escalation call).
Overall cycle time (track quarterly for improvement targets; 20% reduction is realistic within a quarter).

Implementation Roadmap

Week 1: Set up daily red flag checks in standup. Implement Jira flags + comments.

Week 2: Create escalation protocol document. Run first "Block Buster" meeting for any current blockers >3 days.

Week 3: Implement WIP limits. Enforce them strictly (this will feel uncomfortable—that's the point).

Week 4: Launch weekly "Aging Tickets Review" retro. Set up JQL automation.

Month 2+: Track metrics. Adjust limits based on throughput data. Iterate on protocols.

Why This Works

Red flags aren't problems—they're improvement signals. When you systematize detection and response, you:

Reduce cycle time by 20-40% within a quarter.
Improve team morale (work feels unblocked).
Build institutional knowledge (patterns emerge, you prevent future issues).
Empower junior developers (swarming teaches; escalation protocols prevent helplessness).

The teams that excel don't work harder. They work smarter—they swarm bottlenecks, escalate blockers, enforce limits, and reflect continuously.

What's your team's current blocker ritual? Are you seeing patterns in what gets stuck? Share in the comments—your approach might solve someone else's problem.

Evolve Every Repo You Touch in 2026

maria tzanidaki — Tue, 20 Jan 2026 11:57:00 +0000

In 2026, one simple rule can quietly level up your entire engineering landscape: every time you touch a GitHub repo, you leave it a little better than you found it. This is not about big rewrites; it is about small, repeatable upgrades that compound over time across dozens of applications.

The mindset: small upgrades, big compounding

You probably revisit the same repositories again and again: a bug fix here, a small change for a business request there, a quick tweak after an incident. Instead of “just doing the ticket”, treat each visit as a chance to evolve the repo’s quality, safety, cost, and hygiene.

The idea is to codify this as a habit: when you open a repo in 2026, you don’t only change the feature you were asked for; you also add one improvement in GitHub hygiene or AWS efficiency that will pay off for future you and for the owning team.

GitHub hygiene: leave guardrails behind

When you revisit a repo, you can improve how that team collaborates in GitHub without touching business logic at all. These are low‑risk, high‑impact additions that often take minutes.

Add or improve CI with GitHub Actions Even a minimal workflow that runs tests or lint on push and pull request can catch obvious issues before reviewers see them. For YAML-heavy repos (infra, workflows), a lightweight yamllint job in .github/workflows/lint.yml is enough to prevent broken pipelines.
Introduce a PR template A PULL_REQUEST_TEMPLATE.md nudges contributors to explain context, describe changes, and confirm tests, which reduces back‑and‑forth in reviews. This is a tiny file that changes the tone of collaboration from “what is this?” to “thank you, this is clear”.
Define CODEOWNERS for clarity A CODEOWNERS file makes it explicit who reviews what paths, which reduces the classic “who owns this directory?” chaos and helps keep reviewer lists accurate over time. This also supports healthier code ownership: people are responsible for reviewing and maintaining their area, not for merging and fixing everything themselves.
Set up stale PR automation Nothing clogs a repo worse than ancient open PRs that no one remembers or needs. Add the popular actions/stale GitHub Action to automatically label and close inactive PRs after a configurable period (e.g., 30 days inactive → label “stale”, 7 more days → close). This keeps the PR list actionable and prevents stale entries from skewing metrics like cycle time. You can exempt high‑priority PRs by label or milestone to avoid over‑automation. These upgrades are generic enough that you can apply them across many repos, regardless of language or domain, and they align well with inclusive, non‑condescending collaboration practices recommended in modern dev communities. ***

AWS evolution: rightsizing while you are there

Many “finished migrations” are actually in maintenance mode and running with their original sizing assumptions, even if traffic and usage have changed. When you open the repo for a change, it is the perfect time to also look at its AWS footprint.

Check rightsizing recommendations Using AWS Cost Explorer rightsizing recommendations, you can quickly see if the EC2 instances behind this app are chronically underutilized and good candidates for downsizing or termination. Under the hood, these recommendations use usage data to highlight instances where you can keep performance but pay less, and you can act on them directly in the EC2 console.
Turn cost reviews into a continuous practice Instead of a one‑off cost project, you turn every repo visit into a small cost review: “Is this EC2 still sized reasonably for its current load?” Over a year, this habit can create significant savings without large dedicated initiatives, because you bake cost awareness into normal engineering work rather than treating it as a separate topic. Even if you cannot change the instance immediately (risk, approvals, or timelines), opening a ticket or documenting the recommendation gives the owning team a clear starting point instead of a vague “we should optimize this someday”.

A practical “touch checklist” for 2026

To make this mindset actionable, you can adopt a simple checklist whenever you work on a repo in 2026. Be the “annoying” engineer who gently enforces hygiene—your future self and the team will thank you.

For GitHub:
- Is there at least basic CI (lint/tests) on push/PR? If not, add a minimal GitHub Actions workflow.
- Is there a PR template? If not, add a short one that asks for context, changes, and testing notes.
- Is CODEOWNERS defined for the paths you touched? If not, propose or add it with the right reviewers.
- Are there stale PRs rotting the list? Add or update a stale automation workflow to label/close inactive ones.
For AWS (if the repo maps to an AWS workload):
- Are there rightsizing recommendations for its EC2 (or related resources) in Cost Explorer or Compute Optimizer that look safe and sensible?
- If you cannot implement them now, can you at least file an issue, add a note in the ops docs, or include a backlog item linked to the recommendation?

This is not about turning every small task into a giant refactor. It is about leaving behind one small improvement every time you interact with a repo, so that by the end of 2026 your organization’s GitHub space and AWS footprint look very different—not because of one huge project, but because evolving every repo became your default habit.

Code ownership is not “please fix this for me”

maria tzanidaki — Mon, 12 Jan 2026 10:22:34 +0000

I've noticed a common pattern: code ownership gets misunderstood as "manual fixer" duty.

On one hand, I love controlling my repos—keeping them structured, clear, and high-quality. Strict standards matter.

On the other hand, that's not the purpose. Code ownership is about long-term responsibility, not touching every line.

What code ownership actually means

Code ownership is about responsibility for the long‑term health of a part of the codebase, not about manually touching every single line that ever changes.

In practice, that means:

Owners define architecture, patterns and constraints for their area (interfaces, contracts, invariants).
Owners review and approve changes, especially when they affect risky or business‑critical paths.
Owners are accountable for quality, security and maintainability over time – not for typing every change themselves.

Tools like CODEOWNERS in GitHub/GitLab formalize this by routing reviews to the right people, but the mindset has to come first.

Where ownership stops

There is a subtle but important boundary that often gets crossed:

“You own this code” quietly becomes “You must implement, debug and ship everyone else’s ideas.”

That is not sustainable, and it creates bottlenecks.

Healthy boundaries usually look like this:

Owners are not obligated to implement other teams’ work when they have full context and capacity to implement it themselves.
Owners should not be the default “hands” for every hotfix, especially for incidents triggered by changes they did not make.
Ownership includes the right to say “no” or “not like this” when a proposed change breaks contracts, SLAs or design principles.

If every cross‑team request ends with “can you just commit this for us?”, you do not have code ownership – you have a helpdesk.

What other teams are expected to do

The other side of the contract is equally important: if you touch someone else’s code, you also have responsibilities.

At a minimum, a contributing team should:

Read the code and existing tests, not only the docs.
Adapt their implementation to the existing patterns and contracts instead of fighting them.
Own their changes end‑to‑end: implement, test, and iterate on review comments.
Be available for incident support related to their recent changes (with the owner guiding, not taking over).

In other words: you are welcome in a code owner’s “house”, but you do not walk in, move the furniture, and then call them to clean up.

A simple ownership contract for teams

A lightweight agreement many teams adopt looks like this:

Owners
- Define standards and interfaces for their domain.
- Review and approve changes, especially cross‑boundary.
- Step in when systemic issues appear (architecture, security, performance).
Contributors
- Implement and maintain their own features, even when they live in someone else’s repo or module.
- Follow the owner’s patterns and accept feedback during review.
- Do not assume the owner will “just fix it” after merge.

Documenting this explicitly (in a team charter, README, or architecture decision record) prevents a lot of tension later.

If you’re a tech lead or owner

If you are the de facto owner of a large part of the codebase, it helps to:

Make ownership visible (CODEOWNERS, service catalog, clear README with “owner: X team”).
Write down expectations for cross‑team contributions: how to propose changes, who implements what, and who is on the hook for incidents.
Say “no” to patterns where you become the default person merging and fixing everyone else’s code.

Code ownership should give you leverage and clarity – not turn you into the bottleneck for every pull request.

My AWS Community Builder Experience: Second Time's the Charm?

maria tzanidaki — Fri, 09 Jan 2026 17:07:21 +0000

Hey devs and cloud builders! 👋 I'm Maria Tzanidaki, a Cloud Engineer at Mondelez in Greece with 6+ years working on AWS, EC2/RDS cost savings, and Terraform automations – all while balancing pregnancy, gym routines, and home renos.

This is my second time applying to the AWS Community Builders program. Last year, I simply didn't have time to create the required contributions amid work deadlines and life transitions. This year, I'm back stronger, ready to share my real-world journey openly.

Why I'm Applying Again
Rejection isn't failure – it's feedback (even though I didnt have any feedback the previous year). Like Sarvar Nadaf shared in his dev.to guide, AWS selects patterns of consistency, not perfection - so thats my goal. Last cycle taught me: start early, contribute genuinely. No swag-chasing; just learning in public about what I build daily.

My Recent Steps Forward
To build momentum:

Delivered two AWS meetup presentations in Athens/Thessaloniki on Terraform schedulers for non-prod EC2 shutdowns and RDS fleet optimizations – turning internal wins into public value.
Planning more activity: From now on, I'll answer re:Post questions on groups, repost AWS launches with my takes, and share weekly insights. I was shy but you know what, it is exposure for sure but I never declared expert. I don't promise groundbreaking research; just honest docs of failures, fixes, and "why this works and the other not".

Lessons from Last Year (The Reality Check)

Time is the killer: Full-time DevOps + personal life = zero bandwidth for blogs. Solution for my 2026: Block 1hr/week for "share what I learned today." Starting now with my first dev post..
Consistency > Brilliance: Two talks > zero polished perfection. AWS wants your voice, a described problem that was solved, not what is this and what is that (terminology), we can always google these.
Public first: Internal trainings don't count – GitHub it, dev.to it, YouTube the demo (this is the most difficult because most of my work is under company's resources - so not displayable).

What Success Looks Like for Me
It's amplifying women in cloud (we're sparse!), mentoring devs via hands-on posts, and scaling my meetups globally. If selected, expect:

Updates on Terraform modules on GitHub.
Brief to the point articles like "5min RDS savings."
Home-lab stories blending AWS + real life.

If You're Applying Too

Don't wait for "expert" status. Like Sarvar says: Contribute what you're one step ahead on.
Remember! Applications are NOT editable so double check everything!
Rejected? Reapply – patterns win. Drop your journey below; let's build together! 🚀

#AWS #CommunityBuilders #CloudEngineering #DevOps