7 things enterprise architects can learn from the “I was laid off by Atlassian” video

Vasilios Syrakis spent 8 years building core infrastructure at Atlassian.

After being laid off, he didn’t post a rant. He published a 40-minute technical retrospective explaining what he built, the architectural decisions behind it, and what he learned along the way.

It’s one of the better public examples of platform thinking I’ve seen recently, and a lot of it applies directly to enterprise architecture.

Here are 7 things that stood out:

‍

Key takeaways

• Good interviews test reasoning, not just knowledge. Atlassian’s process focused on understanding unfamiliar information, troubleshooting, and explaining technical thinking.
• You do not need to know everything before taking on a problem. Strong fundamentals and confidence in your ability to learn can be enough to get started.
• Great platforms reduce cognitive load. Developers should be able to describe what they need without understanding every infrastructure detail underneath it.
• Architecture evolves with the problem. The platform expanded from self-service load balancing into Envoy, dynamic configuration, infrastructure as code, and centralized edge services.
• Centralization creates leverage. Common concerns like authentication, authorization, rate limiting, and logging can often be solved once at the platform layer instead of repeatedly by individual teams.
• Maintenance is harder than building. Code churn, coupling, onboarding, observability, and long-term ownership become the real challenges as systems age.
• Senior engineering is increasingly about people. Communication, diplomacy, mentoring, teaching, and conflict resolution can become as important as technical depth.

‍

After spending about eight years at Atlassian, engineer Vasilios Syrakis was affected by the company’s layoffs.

Instead of focusing only on the layoff, he used the moment to reflect on what he had built, how the systems evolved, what became difficult over time, and what he learned from working inside a large engineering organization.

What makes the video especially useful is that it does not just cover infrastructure. It starts with the interview that got him hired, moves into platform engineering and architecture, and ends with maintenance, conflict, mentoring, and the realities of long-term software ownership.

Here are seven lessons that stood out.

1. Good interviews test how you think, not just what you know

Watch: ⁠01:33

Syrakis’ interview process at Atlassian was not just a standard coding test.

He first completed a HackerRank coding exercise, but the more interesting parts came afterward.

In one technical interview, the interviewers gave him a Cloudflare white paper on custom domains, left the room for about 10 minutes, then came back and asked him to explain the paper and answer questions about it.

In another interview, he was given a real troubleshooting scenario and had to ask the interviewer for the right information in order to diagnose the problem.

He even describes getting one technical question wrong, but working through it from first principles rather than pretending to know the answer.

That is probably the most interesting part of the interview story.

The process was testing whether he could absorb unfamiliar information, reason through a system, troubleshoot under uncertainty, and explain his thinking.

“They gave me a white paper and asked me to read it while they sat out of the room for about 10 minutes.”

01:40 →

There is also a useful lesson in one of the questions he asked the interviewer.

He asked them to imagine looking back 12 months later and explain what he would need to have achieved for them to consider hiring him a good decision.

Their answer was that Atlassian needed an internal application for self-service load balancing.

That answer would shape his first major project at the company.

The lesson: Strong engineering interviews should test learning, reasoning, troubleshooting, and communication, not just memorized technical knowledge.

2. Confidence can matter when the problem is unfamiliar

Watch: ⁠03:39

The system Atlassian wanted him to build was something he had never worked with before.

It was a framework for internal self-service load balancing, similar in experience to using a cloud provider’s application load balancer, but designed for Atlassian’s own developers.

Syrakis says he was not familiar with the framework.

But he believed he could build it because he already knew how to build web applications in Python.

“I said I could build it because I had confidence in building web apps with Python at that time.”

04:02 →

That confidence was enough for Atlassian to hire him.

Once he joined, he describes the onboarding experience as “drinking from the fire hose” because of how much information new employees had to absorb.

But rather than waiting until he understood everything, he made the application he had discussed during the interview his first major task.

That application became an Open Service Broker.

“My very first task, at least the task that I gave myself, was to build the application that they had told me that they wanted.”

04:34 →

This is a useful engineering career lesson.

Senior engineers rarely enter a project already knowing every technology or implementation detail. What matters is having enough foundational knowledge to reason about the problem and enough confidence to learn the missing parts.

The lesson: You do not need to know every technology before taking on a problem. Strong fundamentals and the ability to learn can be more valuable than prior familiarity.

3. Good platforms hide infrastructure complexity from developers

Watch: ⁠04:58

The first system Syrakis built was an Open Service Broker: an API that allowed developers to provision infrastructure resources through a common interface.

The important idea was abstraction.

Developers did not necessarily need to know exactly how the resource underneath was provisioned.

He illustrates this with databases.

“You’ll get something that’s SQL compatible, but that’s abstracted away for your internal developers.”

05:32 →

Atlassian’s developers would ultimately request infrastructure through configuration files committed to version control, which were then processed as part of the deployment workflow.

The same principle applied to load balancing.

Developers could request the capability they needed while the platform handled the details behind the scenes.

That is one of the core ideas behind platform engineering.

The platform should not expose every possible implementation detail. It should give developers a simpler and safer interface for expressing intent.

The lesson: The best internal platforms reduce cognitive load by letting developers describe what they need instead of forcing them to understand how every infrastructure component works.

4. Architecture evolves as the real requirements become clearer

Watch: ⁠09:57

The Open Service Broker was only the beginning.

As Syrakis worked on the project, the requirements became clearer.

“I built it through necessity of essentially I began to understand and unravel the requirements more as I went along.”

10:00 →

One important requirement was replacing Atlassian’s existing enterprise load balancers, which had licensing costs, with an open-source, cloud-native proxy.

The team chose Envoy.

But replacing one technology with another was not enough.

The new system also needed to be self-service.

“We wanted to replace the enterprise load balances we had, make them self-service so that devs effectively didn’t have to talk to us to go set up their load balancing.”

10:48 →

That requirement led to another architectural component: an Envoy management server, or control plane, that could dynamically change proxy configuration.

The architecture emerged from the problem.

It was not fully designed upfront.

The lesson: Good architecture is often discovered iteratively. Build enough to understand the problem, then let new requirements shape the next layer of the system.

5. Turn complex infrastructure into simple, validated inputs

Watch: ⁠22:55

As the platform matured, the team created a system where developers could provide relatively simple inputs and have those inputs converted into much more complicated Envoy configuration.

“We’ve got this groundwork of being able to take basic inputs from a developer and to turn that into templated configuration.”

22:55 →

That abstraction became increasingly important because Envoy itself supported a large configuration surface.

Routes could match different conditions, manipulate headers, redirect requests, select clusters, and control many other behaviors.

The platform validated developer parameters and used those values as context for templates that generated the underlying proxy configuration.

Developers therefore did not need to become Envoy experts.

The same philosophy appeared in the infrastructure layer.

Atlassian used CloudFormation to create infrastructure and Packer plus SaltStack to build standardized machine images. Syrakis describes configuration management as a way to automate machine setup and make the process declarative.

At one point, he estimates the system at roughly 2,000 proxies across around 13 regions.

That scale would be extremely difficult to manage manually.

The lesson: Platform engineering works best when complex systems are controlled through small, validated, declarative inputs.

6. Centralization creates leverage across hundreds of teams

Watch: ⁠25:53

Once Atlassian had centralized edge infrastructure, the team realized they could use it to solve more than load balancing.

They could move common concerns into the platform itself.

“We created opportunity to centralize logic and to handle concerns early in the chain of requests.”

25:53 →

Those concerns included authentication, authorization, DDoS protection, rate limiting, and access logging.

Instead of implementing each capability independently across hundreds of backend services, the edge platform could provide them once.

Syrakis captures the scale problem directly:

“Can you imagine if a thousand dev teams needed to deal with all this stuff plus more on their own service?”

27:49 →

His argument is simple.

If every team solves the same infrastructure problems independently, the company spends more money, features take longer to ship, and customers wait longer.

The alternative is shared platform infrastructure.

“Thus the platform and centralized management of resources and centralized implementation of these features.”

28:07 →

That does not mean everything should be centralized.

But when hundreds of teams need the same foundational capability, centralization can create enormous leverage.

The lesson: Platform teams create value by solving common problems once so application teams do not have to solve them repeatedly.

7. The hardest engineering problems appear after the system is built

Watch: ⁠31:47

The final part of the video shifts away from architecture.

And in many ways, this is where the most important lessons appear.

After eight years, Syrakis says some of his biggest areas of growth were not technical.

“I have grown tremendously in my diplomacy skills, conflict avoidance, probably conflict resolution as well, being able to persuade, propose ideas, being able to teach, educate and mentor.”

31:47 →

He also talks extensively about maintenance.

New systems require documentation, onboarding, observability, and training.

Engineers need to know where to look when something breaks, which logs matter, what metrics to inspect, and what happens when dependencies such as AWS or SQS fail.

But over time, another problem appears.

Code changes.

People leave.

New engineers bring new opinions.

Certain areas of the codebase start changing repeatedly.

Syrakis describes this as code churn.

“Once you notice that there is some churn, it’s sort of a smell.”

34:26 →

He argues that repeated churn can signal that a section of the system is becoming increasingly complex.

And then he makes one of the most relevant observations in the video for the current AI era:

“It’ll be interesting with all these vibe coded apps and AI assisted apps to see how we handle that when we have people that are not really familiar with what they’ve created.”

34:46 →

The problem is that maintenance costs do not appear immediately.

“The maintenance burdens appear. They don’t appear at the beginning.”

34:59 →

Then comes perhaps the best summary of the entire video:

“Building something is easy. Changing it and making sure that you can still change it over time is difficult.”

35:05 →

As systems evolve, components become coupled. A seemingly small change in one area starts affecting another, and engineers spend more time understanding and untangling those relationships.

The same applies to people.

Syrakis talks openly about learning how to work with different personalities, anticipate conflict, develop self-awareness, and maintain productive relationships with colleagues.

He also learned that teaching and mentoring are different skills.

One of the things he became good at was:

“Break down complex things into simple terms so that they can build a mental model of the system that they’re working on.”

37:19 →

By the second half of his time at Atlassian, helping colleagues understand systems and work through problems had become a major part of his role.

The lesson: Senior engineering is not just about building increasingly complicated systems. It is about keeping those systems understandable, maintainable, and operable while helping the people around you work effectively with them.

The bigger takeaway

What makes this video interesting is the progression.

It starts with an interview.

A candidate is given an unfamiliar white paper and asked to understand it.

He is asked to troubleshoot a real incident.

He is then asked what success would look like 12 months after being hired.

The answer becomes his first project.

That project starts as a relatively simple self-service load balancing application.

Then it becomes an Open Service Broker.

Then an Envoy control plane.

Then dynamically generated configuration.

Then infrastructure as code.

Then standardized machine images.

Then thousands of proxies across multiple regions.

Then larger Atlassian products such as Jira, Confluence, Bitbucket, and Statuspage move onto the platform.

Eventually, though, the biggest challenges are no longer about getting the system to work.

They become:

Can another engineer understand it?

Can someone safely change it five years later?

Can a new person debug it at 2 a.m.?

Can hundreds of teams use it without understanding every detail underneath it?

Can engineers disagree without the disagreement damaging the work?

That is probably the strongest lesson from Syrakis’ eight years at Atlassian.

Great engineering is not just building something that works. It is building something that can continue to work, change, and be understood long after the original engineer has moved on.

⁠Watch the original video

‍