Forem: maria tzanidaki

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

Comments 1

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