DEV Community: Aidas Petryla

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. :)

Discovering the Power of Atlassian Resources

Aidas Petryla — Sat, 29 Jun 2024 09:21:49 +0000

Recently, I explored the extensive resources provided by Atlassian on Agile, DevOps, and more. Their comprehensive material not only refreshed my understanding of Agile and Scrum methodologies learned at Red Hat, but also expanded my knowledge on critical topics like various Git workflows, DevOps culture, and the Scaled Agile Framework (SAFe).

Practical Tips from Atlassian

Consider Gitflow for Large, Complex Projects: Atlassian's guide on Git workflows offers valuable insights into enhancing your version control strategy. The Gitflow model, in particular, is useful for managing larger projects, ensuring a streamlined and efficient development process. It might become The Solution if your current workflow isn't scaling well.
DevOps Best Practices: Their insights into DevOps culture emphasize the importance of continuous integration and continuous deployment (CI/CD). One key takeaway for me was how crucial it is to address the cultural aspects of DevOps. Even the best processes won't yield results if the team culture isn't supportive.
Scaled Agile Framework (SAFe): For organizations looking to scale Agile practices, Atlassian’s resources on SAFe provide practical advice on aligning multiple teams towards common objectives. This can greatly improve overall productivity and cohesion. It's worth exploring if you're finding it challenging to maintain alignment as your team grows.

I'm interested in Your experience with Agile, DevOps and innovation in the organizations. Any stories to share or tips to suggest? :)

🎉 Just completed the "Kubernetes Fast Track" course on Udemy! 🚀

Aidas Petryla — Mon, 24 Jun 2024 09:28:29 +0000

This course has further solidified my Kubernetes skills and broadened my understanding of container orchestration. It was a great, easy to understand, and fast-paced course, which I'm recommending to people new to Kubernetes or those who haven't worked with it for a while and would like to refresh the basics.

Combining this with my extensive OCP experience and my current role managing multiple Nomad-Consul-Vault clusters, I'm more equipped than ever to tackle complex DevOps challenges. 💪

Kubernetes Fast Track

Understanding S3 Bucket Replication vs. CloudFront

Aidas Petryla — Sat, 15 Jun 2024 12:39:05 +0000

If you're diving into AWS, understanding when to use S3 Replication versus CloudFront is essential.

Amazon S3 Replication allows you to replicate objects across different regions, providing near-real-time sync. This is beneficial when you need:

Data redundancy: Ensuring high availability and disaster recovery.
Compliance requirements: Storing data in multiple geographical locations.
Low latency access: For applications where data access speed is critical across different regions.

AWS CloudFront is a global Content Delivery Network (CDN) designed for:

Fast content delivery: Reducing latency by caching content at edge locations.
Improving user experience: Quick load times for websites, videos, and APIs.
Enhanced security: Features like DDoS protection.

When to Use S3 Replication:

You need reliable, scalable storage for replicated data.
Data redundancy and compliance are priorities.
You require low-latency data access in specific regions.

When to Use CloudFront:

Speed and performance for delivering content globally.
Improving user experience with low latency.
Security and performance enhancements for web applications.

Combining S3 and CloudFront can leverage the strengths of each: use S3 for storage and replication, and CloudFront for efficient, global content delivery.

Making Meetings Matter

Aidas Petryla — Mon, 10 Jun 2024 04:29:00 +0000

In today's fast-paced work environment, productive meetings are essential to keep everyone aligned and moving forward. Yet, too often, meetings can become unproductive, leaving participants feeling unheard and unclear about the next steps. Here are some tips to ensure your meetings are efficient and effective:

Set Clear Objectives: Before the meeting, define what you aim to achieve. Share the agenda with participants in advance to ensure everyone comes prepared.
Active Listening: It's not enough to just speak; active listening is crucial. Make sure everyone feels heard by rephrasing and summarizing key points during discussions. This helps confirm understanding and align perspectives.
Encourage Participation: Foster an inclusive environment where everyone feels comfortable contributing. This not only enriches the discussion but also ensures that diverse viewpoints are considered.
Utilize Templates: Tools like Confluence offer a variety of templates designed to streamline meeting processes. These templates can help structure your meetings, keeping them focused and productive.
Action Items and Follow-Up: Conclude meetings with clear action items and assign responsibilities. Ensure there is a follow-up plan to track progress and address any issues promptly.
Time Management: Respect everyone's time by sticking to the agenda and managing the meeting duration effectively. If necessary, schedule follow-up meetings rather than extending beyond the allocated time.

By implementing these strategies, you can transform your meetings into productive sessions that drive results. Effective communication and structured processes are key to ensuring that everyone remains on the same page, both during and after the meeting.

What are your tips for holding productive meetings? Share your thoughts and let's learn from each other!

Unlocking the Power of AWS Auto Scaling: A Game-Changer for DevOps

Aidas Petryla — Sat, 01 Jun 2024 09:41:21 +0000

In the dynamic world of cloud computing, staying ahead of the curve is crucial. As I delve deeper into AWS, I've discovered a transformative feature that significantly enhances how we manage our infrastructure: AWS Auto Scaling.

What is AWS Auto Scaling?

AWS Auto Scaling is a powerful service that allows you to automatically adjust your application's capacity to maintain steady, predictable performance at the lowest possible cost. It provides a hands-off approach to scaling your instances, eliminating the need for manual intervention and constant monitoring.

Key Capabilities of AWS Auto Scaling

Automatic Scaling

AWS Auto Scaling automatically adjusts the number of EC2 instances in response to changes in demand. Whether you're experiencing a sudden spike in traffic or a lull, Auto Scaling ensures your application always has the right amount of resources.

Dynamic Scaling Policies

With AWS, you can define dynamic scaling policies based on various metrics like CPU utilization, memory usage, or custom CloudWatch metrics. These policies allow your application to respond to real-time changes efficiently, scaling up during peak times and scaling down during off-peak periods.

Scheduled Scaling

For predictable traffic patterns, AWS allows you to schedule scaling actions. This means you can pre-define scaling activities to align with anticipated load changes, ensuring optimal performance without the need for manual adjustments.

Predictive Scaling

AWS Auto Scaling uses machine learning to predict future traffic patterns and proactively adjust your resources. This cutting-edge feature minimizes response times and maximizes cost efficiency by forecasting demand and preparing your infrastructure accordingly.

Integrated Monitoring and Alarms

AWS integrates with CloudWatch to provide comprehensive monitoring and alerting capabilities. You can set up alarms to notify you of any unusual activity, ensuring you're always in control and informed about your application's performance.

Why AWS Auto Scaling is a Game-Changer

Cost Efficiency: By scaling down during low demand periods, you save on unnecessary infrastructure costs.
Enhanced Performance: Automatic scaling ensures your application remains responsive and performant, even under varying loads.
Reduced Operational Overhead: Eliminates the need for constant manual adjustments, freeing up your team to focus on more strategic tasks.
Scalability: Easily handle traffic spikes and growth without any manual intervention, providing a seamless experience for your users.

Real-World Impact

Imagine running an e-commerce site that experiences a surge in traffic during holiday sales. With AWS Auto Scaling, your infrastructure can automatically scale to handle the increased load, ensuring a smooth shopping experience for your customers. Post-sale, it scales down to save costs, maintaining efficiency.