Athar

🙋‍♂️ #Entrepreneur | co-founder of @savahapp #aws - Help companies to build better software. Agility and improving ways of working

[Athar @atharmajeed]

As an experienced software engineer, I am often asked whether an Agile engineering team should run 2-week, 3-week, or longer sprints.

Here’s a quick take based on what I’ve observed across teams:

🕒 2-Week Sprints
💚 Fast feedback loops
💚 Keeps product and engineering tightly aligned
💔 Can feel rushed; more frequent ceremonies

🕒 3-Week (or 4-Week) Sprints
💚 More room for deep work and bigger features
💚 Less overhead; less ceremony fatigue
💔 Feedback is slower; focus can fade mid-sprint

💡 My take?
If you’re shipping UI features, iterating quickly, and incorporating customer feedback to reprioritise the backlog, then 2 weeks works great. If you’re building infrastructure, working with long-lived feature teams, handling business-as-usual type projects, or doing heavy backend work, 3 weeks (even 4 weeks) might serve you better.

Don't overthink it. Just start from anywhere and be open to optimising and adapting (but avoid too much change).

What’s worked best for your team, 2 or 3 weeks?

Drop your experience in the comments. I’d love to hear how you are balancing speed vs focus.

#Agile
#EngineeringLeadership
#SoftwareEngineer

[Athar @atharmajeed]

After 10+ years as a Software Engineer, the most common question I get is about system design. And with AI changing everything, it's more critical than ever.

Because here's the truth: AI can tell you what to do. But it can't show you've actually done it.

Most people think system design interviews are about drawing pretty/complex diagrams.

They're not.

They're about solving real engineering problems, bottlenecks, concurrency, scalability and communicating them in a way that excites stakeholders.

From my point of view, it's all about helping teams see the bigger picture within their context.

And proving you understand the specific challenges of that industry.

Take tech debt. Every company has it.

But can you talk about how you've tackled it before with real examples?

That's what makes interviews effective and productive.

Here's what works better:

Don't try to design entire systems. Focus on specific components.

Why?

📌 It forces deeper conversations:
You can dig into trade-offs instead of staying surface-level.

📌 It shows yours thinking process
Anyone can draw boxes and arrows. Problem-solving under constraints? That's what separates candidates.

📌 Explain work with real examples with passion (most people explain in a boring way)
You're never designing Netflix from scratch. You're fixing a caching layer or optimising a queue.

Because hiring managers need to know you can execute. Not just understand the theory (AI and co-pilots wins explaining theory).

They need proof you've taken solutions all the way to production.

AI can give anyone the playbook. Your past examples show you can actually run the play.

What specific challenges do you focus on in system design?

#SoftwareEngineering #CareerAdvice #AgileTeam #EngineeringLeadership

[Athar @atharmajeed]

I've built microservices for government departments, major banks, and startups. The gap between theory and reality is massive.
Greenfield projects?

Pick your stack, ship fast, iterate. Your biggest enemy is yourself!

Over-engineering kills more projects than bad code.

Regulated environments? Different game entirely.

In government, every deployment went through security reviews that would make your code run through complicated CI/CD pipelines. In retail banking, compliance gates stretched 3-6 months before production.

The real constraints hit hard:

→ Deploy pipelines with multiple approval stages
→ Tech stack limited to pre-approved tools (forget that shiny new framework)
→ Audit trails for every config change
→ Government projects? Open-source by default

Here's what the blogs won't tell you:

You can't "move fast and break things" when breaking things means parliamentary questions.

But constraints breed the best engineering. Some of my cleanest architectures came from government projects where I had to bake compliance into the design, not bolt it on later at the time of deploying to production.

The lesson? Stop cargo-culting Netflix's approach. Your microservices strategy must match your reality, not someone else's blog post.

What's your experience like working with Greenfield or regulated projects?

#SoftwareEngineering #Microservices #DevOps
#CloudArchitecture #EngineeringLeadership

[Athar @atharmajeed]

You don't need Kafka.
There, I said it.
At the AdTech company, we built a platform for TfL's outdoor advertising. We started with APIs. It worked. Then we migrated to Kafka with event sourcing.

Honestly? It slowed us down.

Don't get me wrong, Kafka is phenomenal. But here's what happened:

A handful of people managed the system and deeply understood the architecture. When new engineers joined, they struggled. Not because they weren't capable, but because the cognitive overhead was massive. Kafka clusters, streams, consumer groups, partition strategies, and exactly-once semantics took weeks before anyone could confidently support systems.

We'd introduced infrastructure designed for LinkedIn-scale problems to an internal tool with a relatively small team.

LinkedIn built Kafka because they process billions of events daily across a distributed global platform. That's not most companies. That's not even most "big" companies.

Before reaching for Kafka, ask yourself:

→ Could SQS/SNS handle this with proper retry logic?
→ Is RabbitMQ sufficient for your messaging patterns?
→ Do you actually need event replay, or is that a "nice to have"?
→ Can your team realistically operate and debug this out of the hours?

The best architecture isn't the most sophisticated one. It's the one your team can understand, maintain, and iterate on quickly.

Sometimes the boring choice is the right choice.

What's your experience like?
Have you seen Kafka introduced where simpler alternatives would've worked?

#SoftwareEngineering
#EngineeringLeadership
#AgileTeam
#Kafka

[Athar @atharmajeed]

Some people say PI Planning is just waterfall in disguise.
Too many ceremonies. Too much noise. Too slow.
"Agile should be flexible. Why are we planning a whole quarter?"

But here's what they're missing:

PI Planning forces teams to stop. To step back. To see the bigger picture.

And in 2026, that's more valuable than ever.

Here's what I say:

√ Alignment is harder than ever
• Remote teams. Multiple time zones.
• Getting 50+ engineers aligned on what they're building and why! It is nearly impossible without structured face-to-face time.
• PI Planning forces that conversation.

√Dependencies get exposed
• You can have the prettiest Jira boards and Slack channels in the world.
• But nothing surfaces hidden blockers faster than putting teams in a room and asking them to commit publicly.

√ Commitment creates ownership
• When teams commit together, they own together.
• This shifts culture from finger-pointing to collective problem-solving.

PI Planning isn't perfect. No framework is.

But at its core, it's a tool that helps Agile teams stay aligned and deliver.

And sometimes, slowing down to plan is the fastest way to move forward.

What's been your experience with PI Planning? 👇

#EngineeringLeadership
#Agile
#PIPlanning

[Athar @atharmajeed]

New year, same question:

After a decade as a software engineer, mostly contracting, I find myself asking this every January.

When you're hands-on, as I've been, building event-driven systems for banks, modernising government platforms, and delivering greenfield projects for retailers, you measure success by what you ship. That's been my competitive edge.

But permanent senior/lead engineer roles are different. You're suddenly doing one-on-ones, sprint planning, coordinating between platform and product teams, and working on team health and strategy, all while trying to stay technical and deliver value.

Here's what I've seen happen: lead engineers who try to stay deep in the code while taking on leadership responsibilities end up context-switching constantly. Team members wait for feedback. Strategic work gets pushed to "next week." Neither the coding nor the managing gets done well.

The uncomfortable truth: less is more.

The senior/lead engineers I respect most have made a choice. Either commit to being deeply technical and let someone else handle the people and process work, or lean into leadership and accept you won't be shipping features at the same pace.

Both paths are valuable.
Both are respectable.

Trying to excel at both at the same time is often where burnout starts.

For me, staying hands-on is the preferred option, but I've been spending tons of time learning about engineering leadership and helping teams adopt agile ways of working to improve predictability and deliverability.

I've learned to respect that for others, stepping back from the code to enable an entire team might be the bigger contribution.

What is your take?
Have you found a balance that actually works?

#softwareEngineering #agile #engineeringleadership

[Athar @atharmajeed]

I've spent years jumping between codebases from government systems, banking platforms, greenfield projects. The pattern is always the same:

the readable code gets maintained, the clever code gets rewritten.

Three things that actually work:

📌 SOLID principles aren't academic theory. They're survival tools when you're integrating multiple teams or onboarding new engineers mid-sprint.

📌 Variable names matter more than you think. `customerPaymentStatus` beats `cps` every single time. (remember clean code principles)

📌 Keep functions small. If I'm scrolling to understand what one method does, it's doing too much. Break it down.

The real test? Hand your code to someone on a Friday afternoon. If they don't curse your name, you've probably done alright. 😅

What's one coding practice you've changed your mind about over the years?

#SoftwareEngineering #SoftwareDesign #AgileTeam

[Athar @atharmajeed]

I've worked with engineers who couldn't explain what they did without using 10 abbreviations in one sentence. That's not expertise. That's gatekeeping.

On greenfield projects with security clearance, we had a simple rule: use the full name first. Always. Why? Because when you're building systems that matter, clarity beats cleverness.

I've seen this across banking, retail, and public sector projects:

📌 Teams that speak plainly ship faster.
📌 Teams that love acronyms spend half their time explaining themselves.

New joiners shouldn't need a dictionary to understand stuff. The same goes for stakeholders, who shouldn't need a translator to understand your updates. Just say what you mean.

It takes 2 extra seconds to type "Kubernetes" instead of "K8s." Those 2 seconds save 20 minutes of confusion later.

What's one acronym you're dropping this week?

#Engineering #AgileTeam #SoftwareEnigneer

[Athar @atharmajeed]

I once joined a greenfield-ish project where everyone was obsessed with automation with things like code-pipelines, automated tests, deployments etc.

But when I asked “What problem are we solving?” or “What value does this automation bring?” … silence.

The team had great intentions. They wanted speed and efficiency.
But without a clear foundation, automation amplified confusion like builds failed, environments drifted, and leadership wondered why progress was slow despite “so much automation.��

In my experience, starting a project without a proper plan and alignment across teams is one of the biggest mistakes leadership can make.

⚡Define the problem first. What are you optimising for -> speed, quality, security, developer experience?
⚡ Lay the right foundation. Architecture, standards, and environments should be shared understanding, not assumptions.
⚡ Then automate with purpose. When automation supports clarity, not chaos, it truly delivers value.

Getting this right early creates a foundation where teams can move fast and deliver effectively; it's not just about building pipelines, but pipelines that actually mean progress.

What has been your experience with starting on the greenfield-ish projects?

#SoftwareEngineer #AgileTeams

[Athar @atharmajeed]

Are test automation silos holding you back? Hard lessons from the field!

I once worked on a team where we thought we had testing figured out.

We had microservices, a legacy web app, and a dedicated automation engineer who built an impressive test suite using Java + Cucumber + Gherkin. The tests ran against our web application giving us confidence with every production deployment.

It was perfect. Until it wasn't.

When our automation engineer's contract ended, something interesting happened. The test suite began to decay. Slowly at first, then rapidly. Within months, what was once our safety net became irrelevant noise that everyone ignored.

The uncomfortable truth? We had created a silo within our own team.

Developers never wrote or maintained these automated tests. When tests failed, it was "someone else's problem." When new features broke existing tests, developers had no ownership or understanding of what went wrong.

Here's what I learned:

📌Acceptance tests should be owned by the Agile teams (including developers):
√ They understand the implementation details.
√ They can fix failures immediately.
√ They maintain the feature files and tests as the code evolves.

📌Shared ownership creates accountability:
√ When you break it, you fix it.
√ Faster feedback loops.
√ No knowledge silos.

The most sophisticated test suite is worthless if no one maintains it. The simplest test suite, owned and maintained by the entire team, is invaluable.

My take: Make acceptance test ownership part of your team. Every feature, userstory and piece of code should come with tests that the team owns and maintains.

Have you experienced similar challenges with test ownership in your Agile teams?

#SoftwareEngineering #TestAutomation #EngineeringLeadership #AgileTeam

[Athar @atharmajeed]

I was part of an Agile team at a UK supermarket with an ambitious goal: to design, build, and launch a pilot (microservice api) for online grocery orders, a full live order processing system within 6 months.

That kind of timeline usually tempts shortcuts. But I've seen what happens when teams prioritise speed over structure, you end up paying "interest" on that debt in every future sprint.

So I took a different approach. Instead of chasing features, I focused on setting strong foundations early:

⚡We designed an event-driven architecture on AWS that actually made sense, keeping services loosely coupled so teams could work independently without stepping on each other's toes.

⚡I pushed hard for automated pipelines from day one. GitHub Actions and Terraform (where possible) meant we could deploy confidently without the usual "let's manually test everything" bottleneck before releases.

⚡TDD and BDD weren't optional. Yes, it felt slower at first, but it saved us from the dreaded "it works on my machine" conversations or the need to check the data manually after deploying to prod.

The result? We delivered the pilot to live stores across Scotland within six months on time, stable, and ready to scale.

That experience reinforced something I've believed for years: the fastest way to deliver is to build it cleanly from the start.

You can't eliminate technical debt, But you can stop it from controlling your velocity.

How do you balance delivery pressure with building for sustainability in your teams?

#SoftwareEngineering
#AgileTeam
#Microservices
#EngineeringLeadership

[Athar @atharmajeed]

Every Agile team I work with or get involved in talks about technical debt, but few truly track it. I’ve seen teams focus on code smells or test coverage, yet the most painful debt isn’t always visible in SonarQube.

It’s hidden in architecture decisions, manual processes, and integration shortcuts we make to hit deadlines.

From my experience working within cloud-native and event-driven projects in government digital services and retail tech, I’ve learned to look at debt across three layers:

1️⃣ Code-level: readability, coverage, mutation testing (we used PIT to enforce quality gates).

2️⃣ Architecture-level: service coupling, outdated dependencies, and lack of observability( metrics and alerting) .

3️⃣ Process-level: manual release pipelines, missing automation, complex structure, unclear ownership.

When we started treating process and architecture debt the same way as code debt, delivery actually sped up so this helps with fewer incidents, faster releases, happier engineers.

So I’m curious! how do you track technical debt in your teams?

Is it through metrics, retrospectives, or just gut feel?

#softwareEngineering #techleadership #agileTeam

[Athar @atharmajeed]

Microservices aren’t one-size-fits-all. Context is everything.

After building microservices across government departments, banks, and startups, I’ve learned that the approach changes dramatically based on the environment.

Greenfield projects? Pick your stack, move fast, and iterate. The main challenge is avoiding over-engineering (very common among tech leaders).

Regulated environments? Completely different. At Govt and Banks, every PR faced scrutiny months of compliance checks, limited tech choices, and public repos for government work.

But constraints breed innovation, so our microservices strategy should match reality, not your ideals.

How do regulations shape or stifle your architectural choices?

[Athar @atharmajeed]

AI assistants (likes for co-pilots) in software engineering spark much debate. Some view them as a threat, while others see them as a powerful tool.

As an experienced engineer, I find them invaluable. They challenge my old habits, validate ideas, and accelerate learning without the need to sift through endless documentation and resources.

These tools won't replace engineers, but they can enhance our capabilities by allowing us to concentrate on more complex, impactful, and meaningful work.

[Athar @atharmajeed]

Over the past 10+ years across multiple sectors, one key lesson stands out:

Technology is easy, but managing people and processes is challenging.

In the Public Sector and FinTech, I've learned that true digital transformation isn't about chasing the latest AWS services or architecture, but it's about nailing down the problem you need to solve.

From my observations, every successful-ish project typically includes three essential elements:

1. Clear alignment among stakeholders
2. Gradual, measurable improvements
3. Team ownership of the solution

One of the biggest surprises for me was discovering that legacy systems often contain decades of business logic that are often difficult to replicate quickly.

Currently, I’m focused on helping teams navigate the complexities of cloud-native adoption while ensuring business continuity.

I'd love to hear from you: What has been your most valuable lesson from working with digital transformation projects?

#DigitalTransformation #SoftwareEngineering

[Athar @atharmajeed]

Why I stopped fighting software estimates (and what I learned instead)

Early in my career, I used to resist giving estimates. "Software is unpredictable!" I'd argue. "Requirements change, integrations break, and stakeholders don't know what they want until they see it."

I wasn't wrong about the challenges. But I was missing the point.

Here's what 10+ years of working with digital transformations at MoJ and major banks taught me:

Estimates aren't about precision—they're about conversation. When a stakeholder asks, "How long will this take?" they're asking:

- What are the risks we should know about?
- How should we prioritise this against other work?
- What assumptions are we making that might be wrong?

Now I approach estimates differently:

🔍 Break work into smaller, more predictable chunks.
📌 Be explicit about dependencies and unknowns.
📅 Use ranges, not false precision ("2-5 days" not "3.2 days").
🚀 Plan for continuous delivery of incremental value.

The real breakthrough? Making estimation a team sport. When developers, testers, and product people estimate together, we catch blind spots early.

Yes, requirements will still evolve. Yes, that third-party API will go down at the worst moment. But honest conversations about uncertainty build trust, not destroy it.

Fellow engineering leaders: How do you handle the estimation challenge?

#EngineeringLeadership #SoftwareDevelopment #AgileDelivery #SoftwareEngineer

[Athar @atharmajeed]

Is the party over for software engineering?

After 6 years of studying computer science and landing my first professional role, I learned something crucial: the fundamentals never go out of style.

While headlines scream about AI replacing developers (or software engineers) and market saturation, I see a different reality. The engineers thriving today aren't the ones chasing every new JavaScript framework or jumping on the latest tech bandwagon.

They're the ones who invested time mastering:

⌘ Data structures and algorithms
⌘ System design principles
⌘ Core programming concepts
⌘ Problem-solving methodologies

In my years working with engineering teams across digital transformations at DWP, MoJ, and Santander, the developers who excelled weren't necessarily the ones with the most trendy tech stacks. They were the ones who could architect scalable solutions, debug legacy systems, and adapt quickly when requirements changed.

Here's what I tell every engineer I mentor:

Stop worrying about whether the next hot framework will replace React. Instead, understand how event-driven architecture scales, how microservices communicate, security and why certain data structures perform better in specific scenarios.

When I transitioned from monoliths to cloud-native microservices, my computer science foundation, including the boring university coursework and my years of experience, made the transition smooth.

Build projects that solve problems. Understand the "why" behind the tools/tech you use.

Is Software Engineering's party over? Drop your thoughts in the comments!

#SoftwareEngineer #AgileTeam #EngineeringLeadership

[Athar @atharmajeed]

This one mindset shift changed everything for me as a Software Engineer!

When I began my career as a Software Engineer, I focused on:

-🤓 Mastering major coding language
- 🤹‍♂️ Perfecting my skills in both front-end and back-end development (aka full-stack)
- 😱 Comparing with all the other developers/engineers in the field

I worked on PHP, .net, and Java-based projects for different employers at the start of my career. I did this for a few years and it wasn't fun. It was mentally draining. Not because I wasn't working hard, but because I was trying to juggle so many things, and they were all the same but different at the same time.

What's the best way? It's to concentrate on one thing at a time and give it your all.

I realised I was focusing on the wrong things.

Now, I focus on:

√ 🌟 Specialising in one (Java) or two languages
√ 🛠️ Building quality, scalable software
√ 📚 Continuously learning and growing in my unique path

My perspective shifted from "I should do this too because all the other Software Engineers are doing this" to "Is this adding value to me or the projects? And is this making an impact and delivering value to our users/customers?"

The moment you start focusing on the impact and value, not on vanity metrics or comparisons, everything starts to come together in your career.

What has been the most valuable lesson you've learned in your career as a Software Engineer or Developer? 💡

#SoftwareEngineering #CareerGrowth #MindsetShift
#EngineeringLeadership

[Athar @atharmajeed]

🚨 The hidden cost of test automation silos: A lesson learned the hard way

I once worked on a team where we thought we had testing figured out.

We had microservices, a legacy web app, and a dedicated automation engineer who built an impressive test suite using Java + Cucumber + Gherkin. The tests ran against our web application and REST APIs, giving us confidence with every production deployment.

It was perfect. Until it wasn't.

When our automation engineer's contract ended, something interesting happened. The test suite began to decay. Slowly at first, then rapidly. Within months, what was once our safety net became irrelevant noise that everyone ignored.

The uncomfortable truth? We had created a silo within our own team.

Developers never wrote or maintained these tests. When tests failed, it was "someone else's problem." When new features broke existing tests, developers had no ownership or understanding of what went wrong.

Here's what I learned:
√ Acceptance tests should be owned by the developers
- They understand the implementation details
- They can fix failures immediately
- They maintain the tests as the code evolves

√ Shared ownership creates accountability
- When you break it, you fix it
- Faster feedback loops
- No knowledge silos

The most sophisticated test suite is worthless if no one maintains it. The
simplest test suite, owned and maintained by the entire team, is invaluable.

My take: Make acceptance test ownership part of your team. Every feature, every story, every piece of code should come with tests that the implementing developer owns and maintains.

Have you experienced similar challenges with test ownership in your teams?

How did you solve it?

#SoftwareEngineering #TestAutomation #DevOps #EngineeringLeadership #AgileDevelopment

[Athar @atharmajeed]

🚀 Why Engineering Leadership is Buying into Kafka

I've worked on multiple projects across AdTech, Retail and SaaS where Kafka was the difference between a system that crawled and one that soared.

Many organisations, especially in legacy-heavy sectors, have accumulated mountains of data with complex workflows that feel like digital spaghetti.

They're turning to Kafka as a core part of their digital transformation strategy.

Here's what I've seen firsthand.

The reality I witnessed
At one of the AdTech companies based in London that I worked with, they had built an impressive event-sourced architecture using Kafka and MongoDB to store and replay events. Every microservice operates & deploys independently.

The transformation journey!
They were running a mix of RabbitMQ and AWS SQS, but as part of their long-term digital transformation, they consolidated on Kafka. The difference was remarkable:

• Teams feel independent, no more waiting for other squads
• Data flowed seamlessly between microservices
• As long as team contracts were aligned, everyone could move at their own pace

Why Leadership gets excited!
It's not just the tech, it's the organisational impact:
• Team Autonomy: No more cross-team bottlenecks slowing releases
• Reduced Complexity: One unified streaming platform instead of multiple queue solutions
• Future-Proof: Event sourcing means you can replay and reprocess data as business needs evolve

The ecosystem advantage!
The commercial support has matured in recent years. Whether it's AWS MSK, Confluent, or Conduktor, the tooling around Kafka has made it enterprise-ready. No more 'build everything from scratch' nightmares.

The reality check!
Kafka isn't magic. It requires investment in skills and architectural thinking. But when you're juggling multiple queue solutions and teams are constantly blocked by dependencies, Kafka becomes a strategic enabler, not just another tool.

What's been your experience with event-driven architectures?

Have you seen similar transformations from mixed messaging solutions to Kafka?

#SoftwareEngineering #Kafka #DigitalTransformation #EngineeringLeadership #Microservices #AWS

[Athar @atharmajeed]

After working with many Agile engineering teams over the years, I’ve seen a few consistent patterns around pull request reviews.

Some teams require one reviewer per PR. Others insist on two.

On paper, two reviewers sound great so more eyes, better collaboration, stronger safety net. But in practice, I’ve seen it slow teams down significantly.

I worked with one team where most PRs sat in “In Review” for days. Small changes would get stuck because someone was always waiting on a second reviewer. It reduced velocity and created friction!

Compare that to another team I worked with: they had one reviewer. Reviews happened quickly, feedback was meaningful, and work kept flowing.

The result? Better momentum, more ownership, and less overhead.

That’s when it hit me that sometimes, requiring two reviewers isn’t just about quality.

It’s a trust signal.

If every line of code needs two sign-offs, do we really trust each other? Or are we protecting against internal doubts?

Trust doesn’t mean cutting corners. It means believing your teammates will do the right thing and holding each other accountable in a healthy way.

Curious? What’s been your experience? Has the review policy helped or hurt your team’s flow?

#EngineeringLeadership
#SoftwareEngineering
#AgileTeam