DEV Community: Aidas Petryla

Cost of Delay

Aidas Petryla — Mon, 08 Jun 2026 07:06:35 +0000

The Cost Nobody Tracks

A team needed feedback from users.

The proposed solution was technically sound:

flexible question types
flexible answer types
reusable APIs
future-proof database design
dynamic frontend rendering

It would have handled almost any questionnaire we might ever need.

Instead, we hardcoded a single question in the frontend and backend and stored responses in one simple table.

The decision felt wrong, the implementation looked ugly, one engineer even said “I want this out ASAP”.

But there was another cost nobody was discussing.

Every extra day spent designing, building and testing a generic solution is another day without user feedback.

If we optimize for future development speed, we ignore present learning speed.

Cost of delay.

Months later, we still haven't needed a second question.

The interesting part isn't that we avoided overengineering.

The interesting part is how often organizations optimize for hypothetical future work instead of reducing uncertainty today.

A question I use now:

"Who is the second customer of this abstraction?"

If nobody can name one, there is a good chance we're solving an imaginary problem.

Looking back, where have you seen the cost of delay exceed technical debt?

Team over ego

Aidas Petryla — Mon, 01 Jun 2026 06:39:35 +0000

Once, I found myself in a heated discussion with my team about our startup's marketing plan.

The question was simple: should we continue publishing two posts per week, or reduce it to one?

I was convinced we could sustain two. There were plenty of topics to cover, and I saw reducing the pace as a step backward. Others were more cautious.

As the discussion went on, I started feeling frustrated. I felt unheard. I felt my arguments weren't being understood. I saw myself as the one pushing ambition and momentum while others were settling for less.

Then I caught myself.

I stepped away from the keyboard and gave myself time to cool down. Once the emotions settled, I started challenging my own position.

What if we don't actually have enough content?
What if maintaining the schedule hurts quality?
What if the pressure I'm creating becomes a burden for the team?

The more honestly I examined the situation, the more I realized the discussion was no longer about posting frequency. It had become about being right.

And that's where ego had entered the room.

The team's concerns weren't perfect. Some arguments were weak. But that wasn't the point. A team doesn't succeed because one person wins every debate. It succeeds when people feel safe to speak up, challenge ideas, and move forward together.

I copied the conversation into Claude and asked a simple question:

"What am I missing as a leader?"

The answer gave me several perspectives I hadn't considered.

After reflecting on them, I returned to the team, acknowledged that I had been pushing too hard, apologized, and agreed to move to one post per week.

Not because I became certain it was the right decision.

But because preserving trust, alignment, and collaboration was more important than winning an argument.

Leadership isn't about eliminating your ego.

It's about noticing when it takes the wheel—and having the discipline to take it back.

When no one believes, but you do

Aidas Petryla — Mon, 25 May 2026 06:12:25 +0000

Early spring, 2020.

I was a first-year acting student, preparing for a student theatre premiere that was less than a week away.

Then COVID hit.

Lithuania entered its first lockdown. The school closed. The theatre closed. The director said, “my hands are tied.”

Nobody knew for how long.

The expectation was simple: stay home and wait.

But there was one colleague from theatre I often trained movement with. Earlier that year we had started exploring the basics together and got hooked.

Two-person meetings were still allowed.

So I suggested: let’s meet and train.

We met once.

Then again.

Two or three times a week.

Officially, we were just doing movement.

Unofficially, I already had an idea.

One day I smiled and said:

“This would be funny if it turned into a performance.”

The reaction was immediate.

We’re in quarantine. We lost our actual show. No director. No stage. No material. No point.

Fair objections.

So I didn’t argue.

Instead, I went home and kept working.

I recorded every session. What worked. What failed. Hand placement. Timing. Balance. I watched hours of contact improvisation, acrobatics, partner work, acroyoga. Replayed seconds of footage frame by frame.

When we met, we weren’t just training anymore.

We were preparing.

Building strength.

Building trust.

Learning to catch each other before attempting harder things.

Moves impossible two weeks earlier slowly became normal.

And every now and then I would drop a small comment:

“This part could already work on stage.”

Meanwhile, I called our director. First just to check in. Mentioned we were training.

Later:

“We’re rehearsing.”

Not because it was true yet.

Because I wanted us to start acting accordingly.

Next rehearsal I brought an old mattress from a basement.

We found another one at the theatre.

Now we could try more.

Individual movements became sequences.

Sequences became scenes.

Themes appeared.

Characters appeared.

Restrictions slowly lifted.

We invited the director.

Got feedback.

Kept refining.

I even started capoeira training to expand what we could do.

Eventually we returned to rehearsing our original show.

But we didn’t stop.

And in the end we had two premieres.

One of them was born during quarantine.

Nobody assigned it.

Nobody expected it.

Nobody really believed it would happen.

Until slowly… people did.

What stayed with me wasn’t “never give up.”

It was something simpler:

Belief by itself changes nothing.

But belief combined with repeated action can become evidence.

And evidence is contagious.

What do you believe is possible today that others see as unrealistic?

Healthy systems are not the same as resilient systems

Aidas Petryla — Mon, 18 May 2026 06:50:21 +0000

A few years ago, before I even knew the term “chaos engineering,” I accidentally practiced it.

We had a small container orchestration cluster running several applications. Nothing huge. A couple of nodes. Everything looked healthy most of the time.

But there was one annoying category of issue nobody could fully explain:
occasionally, some applications would fail in strange ways after deployment.

The failures looked random.
Transient.
“Probably flaky.”

One day I got curious and started doing something very simple:
manually killing nodes and restarting workloads to see what actually happened.

From the outside, it probably looked pointless.

“If the cluster is designed for failures, of course it should recover.”

But something interesting happened.

Certain applications consistently broke only when scheduled onto one specific node.

The “random” bug suddenly became deterministic.

The cluster wasn’t truly homogeneous. One node had a subtle configuration difference that only revealed itself under failure and rescheduling conditions. Under normal operation, the issue stayed hidden long enough to be dismissed as noise.

That experience stayed with me because it changed how I think about systems.

Healthy systems are not the same as resilient systems.

A system can look perfectly stable right until the moment reality forces it into an unusual state.

And I suspect many organizations avoid these kinds of experiments for understandable reasons:

fear of disruption,
fear of blame,
fear of discovering uncomfortable truths.

But production environments eventually run chaos experiments on their own schedule anyway.

The only real choice is whether you participate intentionally.

No Bad Teams, Only Bad Leaders

Aidas Petryla — Mon, 11 May 2026 06:38:38 +0000

There was constant frustration in one engineering team.

Slow builds. Failing pipelines. Broken deployments. Developers blocked for hours waiting for someone to “fix infrastructure”.

A pretty classic situation:

A DevOps engineer had introduced CI/CD, containerization and deployment pipelines — then left the company. The team had very little prior experience with these technologies, documentation was minimal, and delivery pressure was intense. Long days and overtime were normal.

And at that point, it becomes very easy to say:
“weak team”
“lack of ownership”
“people don’t understand the system”

But the real problem is often something else entirely.

Not lack of intelligence.
Not lack of motivation.
Not even lack of capability.

The real problem is that nobody enabled the team.

After joining, I quickly realized the bottleneck wasn’t the technology itself. The team was young, curious and fully capable of learning.

What was missing was support and knowledge transfer.

So I started organizing short weekly knowledge-sharing sessions.

We began with Linux fundamentals, then moved into containerization, CI/CD and pipeline architecture. Not just theory — hands-on workshops where people could actually touch the systems, troubleshoot problems themselves and understand what was happening under the hood.

A few months later, the situation looked very different.

The team was no longer dependent on a single “infrastructure person”. Developers were optimizing pipelines, diagnosing issues, handling deployments and improving build performance on their own.

And that was the biggest lesson for me:
A lot of “bad teams” are simply teams that were never properly enabled.

Leadership is not just pushing for results.
Leadership is creating an environment where people can become capable without you.

So if your team keeps struggling, before blaming people, ask yourself:
Where am I the bottleneck?

People Problem or a Culture System Problem?

Aidas Petryla — Mon, 04 May 2026 06:31:22 +0000

Many companies say people are their greatest asset. Then hire mostly for skills, urgency, and short-term delivery. And later act surprised by friction:

• Brilliant people who are hard to collaborate with
• Knowledge hoarding
• Free-riding or disengagement
• Misaligned motivations (team mission vs personal incentives)
• “Heroes” who solve problems but weaken the system around them

Often these get treated as individual performance problems. But often they are culture problems.

Culture is not the values poster in the hallway. It is the operating system underneath behavior — how people handle disagreement, how risk gets surfaced, how credit gets shared, how people act when deadlines tighten.

That’s why I think culture should be treated less as HR decoration and more as strategic infrastructure.

And yes — companies talk about “culture fit.” But too often that means one of two things:

It is declared but not actually practiced.
It quietly becomes “people like us.”

Neither creates a stronger system.

What interests me more is culture add.

Not “does this person fit here?”
But “How does this person make us better?”

A cautious thinker can balance fast movers. An empathetic operator can improve customer alignment. Principled dissent can lower error rates.

Not sameness. Complementarity.

And this doesn’t begin in HR.

It begins wherever someone asks:

What behavior am I rewarding?
What tradeoffs am I normalizing?
What standard am I modeling?

Because culture is built by what people practice — and by what they tolerate.

What does your team practice and tolerate?

Extreme Ownership

Aidas Petryla — Thu, 30 Apr 2026 06:42:02 +0000

I’ve been reading “Extreme Ownership”, and I want to reflect on some ideas through my own experience.

Starting with the first principle itself.

Extreme Ownership.

Years before I had the term, I think I had already wrestled with it.

I joined a company and by day three I was dealing with production incidents with almost no onboarding. Firefighting was normal.

But what struck me was not the fire itself.

It was that people kept fixing consequences while causes were left standing.

So I started treating my role differently.

Not as “close the ticket in front of you,” but as: where are the bottlenecks, why does this keep breaking, what could be improved so the same incidents stop repeating?

That led me into uncomfortable places.

There was a password management solution defended because it was “free,” while its maintenance risk was quietly pushed into operational work. I argued that economics made no sense.

There was critical automation written in ways I believed were deeply unmaintainable, yet heavily relied upon. I offered to take it over and improve it. I was told no.

Developers were constantly bombarded, context switching all day. I suggested acting as a buffer and improving prioritization. Again, no.

Then I pulled rough numbers from Jira.

For every ticket I closed, several more were coming in.

I remember thinking: this does not end in hard work. This ends in collapse.

That was the moment I escalated.

I built a presentation and showed the data to a larger IT group, including skip-level leadership.

Afterward, my department head asked me for the reference.

Nothing changed.

Later I raised concerns to a C-level leader directly, explaining that too much was breaking and the model was unsustainable.

His answer stayed with me.

He said, that’s what firefighters do — you take an axe and a helmet and go into the fire.

And I remember thinking:

No.

A firefighter also tries to stop the building from burning down again.

That was when my understanding of ownership deepened.

I had been taking ownership of my tasks, my systems, my standards.

Now I had to take ownership of my environment.

Because if initiative is suppressed from manager to leadership, and impact is structurally blocked, staying is not perseverance.

Sometimes staying is avoidance.

So I left.

And I never saw that as failure.

I saw it as refusing to outsource responsibility for my values.

And strangely, leaving also forced others to own what they had been ignoring.

Once people started leaving — including strong people the company valued — it became harder to dismiss the problems as individual complaints. Questions started being asked. Leadership started investigating. Another person was brought in. The management setup was reshuffled.

None of that happened because I “won” an argument. It happened because consequences became harder to ignore. In that sense, my leaving did force ownership back into the system.

That changed how I interview to this day.

I probe for red flags.
I challenge vague answers.
I test whether people want ownership, or merely obedience.

That lesson came from pain.
But it stayed.

Extreme ownership, for me, is not only taking responsibility for what is yours to fix.
Sometimes it is recognizing when the responsible act is changing the battlefield.

What ownership are you still avoiding taking?

Ownership starts before anyone asks

Aidas Petryla — Mon, 27 Apr 2026 06:18:51 +0000

I used to think helping meant doing what I was told.

Hand me the tool.
Hold this board.
Cut here.

Task completed.

But I’ve come to see a different form of contribution:

Seeing what will be needed before being asked.

Bringing the tape measure while someone reaches for the wood.

Preparing the saw while they’re still marking the cut.

Steadying the ladder before anyone thinks to ask.

Not because it is “my task.”

Because I care about the work succeeding.

And I wonder what would happen if teams operated this way.

Not as collections of people completing assigned tasks —
but as people actively removing friction for one another.

Anticipating risks.

Protecting the mission.

Helping others succeed before they struggle.

How different would organizations feel if people optimized not for task completion, but for stewardship?

Many teams don’t fail because people avoid work.

They fail because ownership often stops at the edge of responsibility.

And maybe the deepest part:

This kind of ownership often goes unnoticed.

When problems never occur, no one applauds the problems prevented.

Things just… work.

As the Tao Te Ching says:

“When the work is done well, the people say: we did it ourselves.”

No credit.
No spotlight.

Maybe that is the point.

Not acting for recognition.

Acting for the people, and for the goal.

And perhaps culture starts exactly there.

As the Bhagavad Gita puts it:

“Whatever the best among people does, others follow.”

If we want ownership around us,

maybe we start by quietly bringing the measuring tape.

We Almost Didn’t Launch — Until We Cut the Product in Half

Aidas Petryla — Mon, 20 Apr 2026 13:12:28 +0000

🚀 We almost didn’t launch.

Not because the product was impossible.Not because the team wasn’t capable.

Because the scope kept growing… while our capacity didn’t.

A year ago, launching soci.lt felt like chasing a horizon:– People had jobs, studies, life– Capacity was unpredictable– “Just one more feature” kept sneaking in– Timeline kept slipping

And the worst part?Until launch — nothing moves. No users, no feedback, no signal. Just… waiting.

So I did something uncomfortable.

I cut.

Hard.

Users could register… but not delete accounts.You could create data… but not delete it.Some profile fields? Not editable.Logout? Not critical.

If it didn’t block the core flow, it was gone.

The rule became simple:If this can be done the day after launch — it’s not a launch requirement.

That’s when things changed.

Progress became visible.The backlog started shrinking for real.Energy shifted.

But the real challenge wasn’t the backlog — it was discipline.

“Must-have” features kept coming (from everywhere, including my own brain).Each one had to go through the same filter:

Is this truly blocking us from going live?

If not → Day 2.

Another move that helped:We aligned development with business reality.

When it looked like we needed ~3 weeks to finish, and onboarding would also take ~3 weeks — we overlapped them.

Started onboarding before we were fully done.

Risky? Yes.Worth it? Absolutely.

We launched earlier than expected.

And here’s the funny part:

Some of those “critical before launch” features…are still not built today.

Turns out:Doing something manually 1–2 times a yearis cheaper than a week of engineering time.

A lot of projects don’t fail because they’re bad.

They fail because they never cross the line.

Like ships stuck in the harbor, endlessly polished, upgraded, prepared…but never allowed to sail.

What helped us actually launch:

Define a real feature list for launch
Next day — cut it again (ruthlessly)
Map dependencies, estimate, timeline (basics, but done properly)
Protect priorities when chaos hits (because it will)
Align with business timing — not just engineering readiness

And one more, which I learned the hard way:

Prefer reversible decisions early (features)Be careful with irreversible ones (architecture)

This approach is not universal.

Sometimes you should start fully manual — spreadsheets, forms, emails — and evolve from there.

But if you’re stuck in “almost ready” for months (or years)…you might not need more effort.

You might need less scope.

Harsh truth: Many products die in the shadows of perfection.

Better to launch something imperfect that breathesthan something perfect that never lived.

The Opposite of Loneliness

Aidas Petryla — Mon, 14 Jul 2025 09:41:10 +0000

After 30+ years of feeling lonely, I've been thinking about what's missing.
Yes, there are apps for meeting people—Meetup, Bumble BFF, and others. But they don't quite capture what I'm searching for: a space to find people who share our passions, our curiosities, a desire to build RC aircraft or to have that Harry Potter marathon we've been putting off.

I'm searching for (or dreaming of building) a platform that:

Puts community over profit — No subscription tiers hiding basic features. No algorithms designed to keep you scrolling instead of connecting. A place where you can message interesting people instantly without hitting 3-messages-per-day limits (you don't have limits saying "hello" to people on the street, right?). You can search for people by location, interests, etc. without limits!
Connects through shared purpose — Find people who want to collaborate on projects, learn together, or simply share genuine interests. Not just "swipe right if you like hiking."
Builds lasting relationships — Success means people forming real friendships, not deleting the app after a single match.
Respects authenticity — No pressure for perfect photos or curated personas.
Grows organically — Ideally open-source, built by the community it serves.

I believe loneliness is one of humanity's biggest challenges—one that money, fame, or even AI can't solve. We're social beings. We need each other.

If you relate, or know any tools that already do this well, I'd love to hear from you. If you're interested in building something like this together — I'm more than happy to grab a cup of tea and jump on a call to connect and discuss more. ^^

Concurrent and Parallel Programming in Python (course)

Aidas Petryla — Mon, 22 Jul 2024 07:02:00 +0000

Just finished an excellent course on Concurrent and Parallel Programming in Python, and I'm excited to share my experience!
As a lead engineer, I'm always looking for ways to optimize performance and expand my knowledge. This course by Max S on Udemy was a fantastic refresher on async programming, parallel computing, and threading.

What stood out:

Clear explanations of complex concepts
Practical, real-world examples
Hands-on coding opportunities

The instructor breaks down threading, multiprocessing, and asynchronous programming in Python with ease. We built a multi-threaded program that fetches data from the internet, parses it, and saves it to a local database - a common scenario many of us face in our daily work.

Key takeaways:

Optimizing IO-bound operations with multi-threading and async programming
Leveraging multiprocessing for CPU-bound tasks
Combining async and multiprocessing for maximum efficiency

Whether you're looking to speed up data processing, improve API performance, or just refresh your understanding of concurrent programming in Python, I highly recommend this course.

Have you taken any courses lately that improved your coding skills? Let's discuss in the comments!

Docker log rotation

Aidas Petryla — Mon, 15 Jul 2024 14:25:46 +0000

Today, I deleted 130 GB of logs. I don't know who started those Docker containers, but let me share a valuable concept: log rotation.

For example, one can define it in daemon.json:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
  }
}

or directly when starting a container:

docker run \
  --log-driver=json-file \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  my-image

or even as an Ansible script:

- name: Start Grafana loki
  docker_container:
    name: my-container
    image: my-image
    state: started
    log_driver: json-file
    log_options:
      max-size: "10m"
      max-file: "3"

There's no need to store 130 GB of logs. Really. :)