Put together, they form a consistent picture – not an official ladder, but a very real one that shows how engineers grow, gain influence, and move from writing code to shaping entire systems.

Compensation reveals the real hierarchy

At its core, Adobe uses a P-level system (Professional levels) that maps engineering growth from entry-level roles to company-wide technical leadership.

Adobe doesn’t hand out impressive titles quickly. But behind the modest titles, what’s actually expected of you keeps growing at every level. The ladder looks flat from the outside. From the inside, the gap between levels is real.

If titles are understated, compensation isn’t: across multiple sources, total compensation for software engineers at Adobe ranges from roughly $150K at the entry level to well above $500K at the top of the individual contributor track.

The numbers matter, but so does the curve. Pay grows steadily through early and mid-level roles and then jumps sharply after senior. That’s where Adobe starts paying for influence, not just output.

Senior level: where leverage begins

At P10 and P20, the job is straightforward: ship code, learn the systems, and figure out how Adobe builds and scales things. The goal is to become someone the team can rely on.

By P30, something shifts. Engineers stop executing tasks and start owning problems (taking a feature end-to-end), making real technical calls, and thinking about why something should be built, not just how.

At P40, the job changes for real. Senior engineers design systems, not just features. They cross team boundaries, shape architectural decisions, and lead bigger initiatives. For many, this is a long-term home – the next step demands a fundamentally different kind of growth.

Staff: the real career breakpoint

The jump from Senior (P40) to Staff (P50) is the most important one on the ladder. Same title family, completely different job.

Staff engineers operate as technical leaders without formal authority. They define architecture, guide technical direction, and shape roadmaps across teams. At Staff, you’re measured by what others can build because of you and compensation starts to reflect that.

Beyond Staff, engineering becomes increasingly strategic. Senior Staff engineers (P55) operate across domains, aligning engineering efforts with business goals and driving initiatives that span multiple teams.

Principal engineers (P60) move to a company-wide level of influence. They define technical vision, tackle ambiguous problems, and shape decisions that impact entire product lines. At this level, engineering is less about building and more about direction-setting.

Cross-company level mapping

One useful way to understand Adobe’s ladder is to map it against more transparent systems at companies like Microsoft. While titles and expectations vary slightly, the underlying progression is broadly aligned across Big Tech. Adobe’s levels tend to appear slightly compressed in naming, but comparable in scope, especially from Staff level onward.

The important nuance is that while the mapping is directionally accurate, scope matters more than exact title equivalence. A P50 at Adobe may operate closer to a strong L6 at Google or even edge into L7 territory, depending on the organization, reinforcing the idea that Adobe’s ladder is less about labels and more about impact.

What Adobe actually values?

One pattern runs through the whole ladder: scope drives everything.

• Early levels – Can you execute?
• Mid levels – Can you own?
• Senior – Can you design systems?
• Staff+ – Can you influence outcomes across teams?

That’s the real progression. The ladder feels invisible from the outside because titles aren’t the point — expanding impact is.

Adobe’s ladder stands out for how quietly it operates. No playbook, no loud framing, just one consistent logic: as you grow, you move from writing code to shaping systems to shaping decisions. At the top, one question defines everything: how much of the company changes because of your work?

The post Let’s Take A Look Inside Adobe’s Complete Career Ladder appeared first on ShiftMag.

Top experts from global tech leaders will share how they build and scale some of the world’s most complex systems, with real-world lessons from production environments.

Across multiple stages, the program features panels, workshops, and talks focused on deep technical insight and practical experience. Speakers include Katie Gamanji (Apple), Igor Dmochowski (NVIDIA), Sven Peters, Bette Lyon Delsordo, and many others.

You don’t need silicon valley for world-class tech

Igor Dmochowski, Head of Developer Relations for Central and Eastern Europe at NVIDIA, said that Infobip Shift is already internationally recognized, and added that he is especially excited to meet local developers whose potential is increasingly visible on the global stage:

Croatia has exceptional technological talent and a strong AI community, and I’m glad to be part of an event that puts this into a global context. True tech innovation comes from connecting people and ideas, and Shift has that energy.

On the other hand, Ivan Brezak Brkan, the Director of Developer Experience at Infobip, said that Infobip Shift is rightfully the largest tech conference in this part of Europe and one of the largest in the world.

You don’t have to, especially in today’s conditions, travel to the other side of the world to exchange experiences with people whose technological solutions power the world. If you want to advance your career not only through knowledge but also through connections, you need to be at Shift.

No professional speakers and marketing presentations

“Infobip Shift is built on two foundations: high-quality content and a relaxed atmosphere that encourages networking. We ensure strong content by carefully selecting speakers who share real-world experience from people actively working in the industry,” said Stipe Cigic, Director of the Infobip Shift, adding:

We avoid professional speakers, marketing-driven presentations, and topics overloaded with buzzwords and hype. That has become especially challenging today, when roughly every second submitted topic is somehow related to AI. Our speakers are real developers – people whose knowledge our audience truly values.

He also said the second foundation of Shift is its relaxed, laid-back atmosphere – a vibe the team aims to create each year. It can’t be forced, but they work to make the event feel light, summery, and welcoming. That kind of atmosphere makes networking more natural and fun.

Meeting new people is the biggest opportunity for attendees. I know at least 2 projects that started from casual chats at last year’s Shift. High-quality content plus a summer vibe, that’s what makes it memorable.

Knowledge gets you started, networking takes you further

With increasing reports of layoffs and disruption in the global IT industry, networking is becoming even more important. Stipe says the goal is for developers to leave Shift not only with new knowledge, but also with greater confidence and reassurance in their skills, value, and future in the industry.

I believe that, when it comes to networking and professional connections, Shift has no real competition in this part of Europe within the developer industry. A junior developer can casually grab a coffee with a senior engineer from companies like Netflix. The exchange of knowledge and experience in conversations like that is something our community rarely finds at nearby conferences.

Stipe concluded that Shift is a long-term platform developers can rely on, not just to meet peers, but also potential employers, clients, and partners. It offers many opportunities, whether for networking or simply enjoying great talks, food, and drinks under the Mediterranean sun.

Interested in Infobip Shift? Explore what we have planned!

The post Infobip Shift 2026 Returns to Zadar, Bringing Apple and Nvidia to the Stage appeared first on ShiftMag.

A field that, just a few years ago, felt stable and full of opportunity now comes with more uncertainty -breaking in is harder, and staying relevant takes constant effort.

We spoke with software engineers who have more than 10 years of experience to hear how they’re navigating these changes.

Thinking back on your career, what’s helped you stay relevant as technologies and trends kept evolving?

Denis: “I was always looking for ways to improve my workflow, so I could spend more time on the interesting, creative parts of the job and less on repetitive, routine tasks. I focused on really understanding problems and possible solutions, which meant building deeper knowledge rather than relying on quick fixes from the internet. I read books, followed blogs, attended both live and online conferences, and learned from experienced people in the industry to get different perspectives and form my own conclusions.

To stay relevant, I focused on real user use cases and the problems behind them, building solutions that create real value.

I also made a point of staying close to the products, users, and solutions over time to see what actually works and what doesn’t, regardless of hype or trends.

Working in teams and collaborating closely helped a lot, as there are always tough questions and healthy discussions that lead to better decisions in the end.”

Marina: “Staying relevant over the years came down to curiosity and hands‑on learning. I regularly read blogs and watch online conferences to keep up with new technologies, but I learned the most by trying things out through small POCs. Experimenting helped me understand problems more deeply and see what really worked.  

Changing teams also played a big role. Working with people who had different backgrounds and experiences exposed me to new ways of thinking and pushed me to grow.  

Finally, working on real products in production environments (especially in larger teams) taught me lessons you simply can’t learn alone. Collaboration, shared ownership, and learning from others helped me continuously adapt as the industry evolved.”

Marko: “For me it’s a combination of continuous learning and a strong focus on fundamentals. I always tried to explore new technologies and different domains, but with an emphasis on really understanding the core principles behind them. That way, the knowledge stays useful even if my career moves in a different direction, and it becomes much easier to build on top of it later.

Just like for the other guys, another important factor was working on real products running in serious production environments, especially in larger teams. Collaboration, communication, and learning from others in a shared codebase bring insights you simply can’t get when working alone. Those experiences helped me grow not only technically, but also in how I approach problems and make decisions in the long run.

I’d describe myself as a cautious early adopter. I enjoy experimenting with new technologies, but I try to understand the fundamentals behind them first, so I can evaluate where they truly make sense and how they contribute real value rather than just following hype.

Finally, self-reflection played a big role. Regularly asking myself what skills I’m missing, how I can contribute more to my team or company, and then actively working towards that has led to many good long-term career decisions.”

Mario: “Talking to other people, watching what others build, and experimenting myself plus exploring open source projects, YouTube videos, and Udemy courses on 2x speed to quickly understand what’s possible with unfamiliar tools. I also follow Hacker News and similar newsletters.

But staying relevant isn’t just about knowing what’s new; it’s about knowing what’s actually worth adopting – and when.

Understanding the high-level concepts and the problem I’m trying to solve is what allows me to pick something that looks like the right tool. After that, trying it out and getting first-hand experience: how it feels under the fingers, and whether it really solves my problem and makes my life easier – is mostly the deciding factor for me, but not the only one. If I’m doing a quick throwaway POC, I can try anything and really find the best tool.

But if I’m working in a team environment where cognitive load is already high, I’m careful not to introduce new technologies every other day just because it’s the new cool shiny thing – even if it actually is the best tool. It’s a tradeoff, and one that needs careful consideration. And sometimes the best isn’t even needed – something that works is good enough.”

In your opinion, is long-term success more about being a deep specialist or a broad generalist? Has your perspective changed over time?

Denis: For long-term success (whatever that is), it’s generally better to develop M-shaped skills. That will take some time, but only with great collaboration and multiple deep expertise areas can you be innovative and versatile, bringing measurable value and not be easily replaceable.

Marina: Earlier in my career, I believed that being a T‑shaped developer was the ideal path and I assumed that trying to learn more than one thing deeply would only lead to superficial knowledge and that focusing on a single specialization was the safest way to grow. Over time, my view changed.

Through real-world experience, I realized it’s possible to build strong, meaningful expertise in multiple areas without losing depth. As systems became more complex, having deeper knowledge across several domains helped me understand the bigger picture better, make better technical decisions, and collaborate more effectively with others.

Today, I believe long‑term success comes from combining depth with breadth – developing strong expertise in more than one area and continuously expanding that range as technology evolves. This flexibility has helped me stay relevant and adapt as roles and technologies have changed.

Mario: I wonder if it’s possible to be M-shaped For a long time, I was a firm believer that T-shaped is the way to go – a broad overview, but with at least one area of genuine deep expertise. And I still think that’s a solid foundation for any engineer.

But over 20+ years, curiosity kept pulling me in different directions: low-level Linux internals, networking, compilers, containers, orchestration, and large-scale distributed systems, working at different layers of the stack. And each time, I went deep enough to solve a real problem. That experience adds up over time.

Understanding the problem and figuring out which layer it needs to be solved in matters more than the technology layer itself, and then it’s about stitching everything together.

Do that long enough, across enough domains, and you naturally grow more spikes. So my view has evolved – I started as a T-shaped believer, and somewhere along the way I became something closer to M-shaped. Not by design, but by following the problems. And if you ask me what I’m an expert at specifically, I’d say solving problems, if that counts as expertise. That’s at least what I currently strive for.

Marko: Today, I’d describe myself as somewhere between T-shaped and M-shaped, maybe N-shaped, still evolving. Early in my career, the T-shaped model made perfect sense, broad knowledge with depth in one area. Over time, as access to knowledge became easier and technologies evolved faster, I realized how valuable it is to develop depth in multiple areas

What ties all of this together is problem-solving. Technologies change, but problems remain. Being able to learn continuously, adapt, and apply concepts from one domain to seemingly unrelated problems becomes incredibly valuable over the long term.

If I were to advise myself 10 years ago or to others today, it would be to stay curious, keep learning, and surround yourself with people you can both learn from and teach. Also, don’t be afraid to broaden your horizons, look for ways to contribute beyond your narrow specialization, pick up complementary skills, and take some risks. Growth often happens outside your comfort zone.

How do you see AI tools impacting long-term developer careers?

Mario: AI impact is real, especially in engineering. We’re much faster at writing code, and I can smart-search unfamiliar codebases and quickly understand how things work (something that used to take a huge effort).

But there’s a price.

The amount of generated code is huge, yet humans still need to review, understand, and own it. AI isn’t the one waking up when something breaks. Creating PRs with AI is easy, being responsible for them is another story.

Our role has shifted to making sure code that looks ok is actually ok – fits the intended architecture, the broader system, the business rules, all the things AI isn’t aware of. The value is the same: understanding whether the code works as intended and preventing it from degrading into a ball of mud nobody can understand or fix at 3am.

What’s changed is how much harder that challenge has become with code being generated at this speed. Young developers are in a tight spot – suddenly expected to skip writing code by hand but still have the same depth of understanding.

And I’m not sure you can skip that part. There’s something about writing code by hand, hitting a wall, debugging it yourself, and feeling the pain of it not working that builds intuition you can’t shortcut. Even if AI is faster and easier. The best advice is to learn the concepts, fundamentals, and engineering best practices that hold regardless of AI.

You need to be able to look at AI-generated code and know whether a for loop is acceptable or a dictionary lookup fits better, that’s software engineering 101. AI can generate the code, but we still need to understand whether it actually fits.

Write as much code by hand as you can. Use AI to review it, ask for other options, and have it challenge your approach, and then actually think through the answers. That way you learn faster while still building real understanding.

And don’t skip debugging AI-generated code step by step; I do it regularly. It’s how you move from just looking at code to actually feeling it. That difference becomes obvious once you try it.

You’ll often be surprised how much you miss just by reading – sometimes it’s “this is not how I thought it worked”, sometimes it’s “I did not expect this at all.” Both are valuable, and both come from actually stepping through it.

Marko: AI tools already have a huge impact on my daily work, from writing code and understanding codebases to reviews, idea generation, debugging, and learning new topics. Overall, I see AI as a strong positive force for developers. It significantly reduces the time spent on repetitive or low-value coding tasks and frees up more space for thinking about architecture, system design, and solving complex problems that truly matter in production.

That said, some things won’t disappear. Understanding the problem and broader context, making architectural trade-offs, communicating well, and taking ownership are still firmly human. When something breaks at 2 a.m., it’s still engineers who make decisions and take responsibility. AI is powerful, but only as effective as the person using it.

For junior developers, don’t skip the fundamentals. Expectations are higher than ever, but strong foundations are key for a sustainable career. The good news is that access to knowledge and AI tools is better than ever. Use AI to accelerate learning, not replace understanding. Give yourself time, build experience, and master the basics—that investment pays off for decades.

Marina: AI tools will significantly change how developers work, but I don’t see them replacing strong engineers. Instead, they will amplify those who understand what they are building. For younger developers, the key is to learn with AI, not just watch AI work.  

It’s important to question AI output, understand why it made certain changes, and how those changes affect the system. Treat AI as a learning partner rather than a shortcut. Blindly accepting generated code can limit growth, while actively analysing and improving it builds real expertise.  

Younger developers should also focus heavily on architecture and system design. When you understand how systems are structured, how components interact, and what trade‑offs exist, AI becomes far more powerful. It’s much easier to ask the right questions (and get useful results) when you already understand the problem space.

Denis: AI tools have made coding skills almost irrelevant. Still, other skills and practices related to quality, such as trunk-based development, TDD, continuous delivery, modularity, cohesion, DDD, etc., are more valuable than before.

AI tools are a powerful amplifier, and they need guidance, so software engineers with those skills will remain relevant and in demand for a long time. Understanding of the (business) problem and the solution shouldn’t be outsourced to the AI. Software engineers still need to understand trade-offs, architecture, and code. 

The post What 4 engineers with 10+ years of experience say about staying relevant in the AI era appeared first on ShiftMag.

Digging through portals and LinkedIn profiles is a total drag. That’s why we at ShiftMag launched a handy guide that packs the career ladders of major tech corps into one place! We already tackled Amazon, and today, Microsoft is on the menu!

To build this guide, I cross-referenced multiple sources: Microsoft’s official career site, Levels.fyi compensation data, LinkedIn profiles of current and former Microsoft engineers, and publicly reported industry data including salary leaks and engineering blogs.

Where sources conflicted, I noted the discrepancy rather than picking one arbitrarily. Compensation figures reflect self-reported U.S. data from Levels.fyi and should be treated as estimates, because they vary by location, team, and negotiation.

Microsoft’s engineering levels

In Microsoft, there are a number of standard job titles. Entry-level engineers start at L59–60 (SDE I) and progress through mid and senior roles up to L67–68 (Distinguished Engineer / Technical Fellow). The ladder splits into two tracks: management (Engineering Managers) and individual contributor (IC).

L59–60 – Software Engineer (SDE I)

Entry level for new graduates or engineers with under two years of experience. Engineers implement features, write and debug code on well-scoped tasks, and work under close mentorship. The primary focus is learning systems and coding practices.

L61–62 – Software Engineer II (SDE II)

Mid-level engineers with roughly 2-5 years of experience. They own more complex features end-to-end, write scalable code, and begin mentoring SDE Is. They influence design decisions within their projects but still receive technical guidance from seniors.

L63 – Senior Software Engineer (Senior SDE)

Engineers with approximately 5+ years of experience who own multiple features or projects and set technical direction within their domain. Senior SDEs lead design discussions, ensure long-term maintainability, and partner closely with product and engineering leads.

L64 – Principal Software Engineer

A senior IC role typically reached after 8-12 years of experience. Principal SDEs lead large components or entire technical domains, architect systems, and drive technical strategy. Some external sources label L64 as “Staff Engineer,” but Microsoft’s internal title is Principal SDE.

L65-66 – Principal Engineer II / Partner-Level

Principal-level engineers with broader organizational scope. These roles sometimes straddle IC and management tracks, with titles including Senior Principal or entry-level Architect. L65 is often where the formal “Principal” designation begins internally.

L67-68 – Distinguished Engineer / Technical Fellow

Top-tier IC roles focused on company-wide innovation and long-term technical strategy. Distinguished Engineers (L67) have deep domain impact across the organization. Technical Fellows (L68) are among the most senior technical positions at Microsoft and are extremely rare. These levels are not promoted into on a fixed timeline, they are typically nomination-based and require demonstrated impact at scale.

Cross-company level mapping

The table below shows rough equivalents across Google, Meta, Amazon, and Microsoft. These mappings are approximate – scope, expectations, and compensation vary significantly by company even at equivalent titles.

Compensation

Microsoft’s total compensation (base salary + bonus + RSU grants) rises steeply with each level. The figures below reflect U.S. median total compensation as reported on Levels.fyi. These change frequently and vary by location, team, and negotiation.

Compensation data sourced from Levels.fyi. Figures are self-reported estimates and should be treated accordingly.

A note on RSUs: Microsoft grants RSUs on a 4-year vesting schedule with a one-year cliff, after which shares vest quarterly. At senior levels (L63+), RSU grants make up an increasingly large share of total compensation – often exceeding base salary at L65 and above. Annual refresh grants are awarded through Microsoft’s performance review process (called “Connects”).

The post Microsoft Engineering Levels and Salaries: The Complete SDE Career Ladder (L59–L68) appeared first on ShiftMag.

Welcome to the engineering hierarchy of one of the world’s biggest tech companies, with nearly 200K employees… and I’ll be your guide.

Since Amazon doesn’t publicly publish an official breakdown of its career levels, I reviewed various sources such as Dev.to articles and salary websites.

To start with, AWS is famous for a decentralized, high-ownership environment where engineers don’t just write code, they must run what they build. Understanding the AWS career ladder is essential for any developer looking to enter the ecosystem that powers over a third of the cloud.

The AWS leveling system

Amazon (and by extension AWS) uses a structured leveling system that spans from L1 to L12. However, most software engineers operate between L4 and L8, with higher levels reserved for a very small number of highly influential technical leaders.

While some companies hire engineers at lower levels, AWS typically starts its professional software engineering track at L4.

Level 4: Software Development Engineer I (SDE I)

The SDE I position at Amazon serves as the foundational entry point, typically designed for recent college graduates or engineers with limited professional experience. At this stage, the primary focus is on building a robust technical baseline. You are responsible for hands-on coding and debugging within well-defined tasks, contributing to the development of small features that integrate into larger projects.

While you are expected to deliver high-quality code, you aren’t expected to do everything yourself. AWS has a heavy emphasis on mentorship at this level. Because of that SDE I engineers receive significant guidance from seniors to help them navigate complex systems and understand specific development tools and practices. It is a period of incremental skills development.

Level 5: Software Development Engineer II (SDE II)

SDE II engineers are often the backbone of the company’s engineering organization. At this stage, it’s all about being fully self-sufficient. SDE IIs are expected to manage their own workloads with minimal supervision, prioritizing tasks effectively to deliver consistent, high-quality results.

Beyond just executing tasks, SDE IIs begin to take ownership of larger systems and components. They are responsible for designing and implementing solutions that specifically meet Amazon’s high standards for scalability, performance, and reliability. This is also the level where your influence begins to expand beyond your code, you start acting as a mentor to L4 engineers and begin coordinating on cross-functional projects.

Level 6: Senior Software Development Engineer (SDE III)

The Senior SDE role is an advanced position reserved for experienced engineers who have demonstrated strong technical and leadership capabilities. At this level, the scope of responsibility expands beyond individual contributions to owning larger systems and leading complex projects.

Senior SDEs are expected to design scalable architectures, make high-impact technical decisions, and guide the work of other engineers on their team and adjacent teams. Their influence is significant, though typically focused within a team or a group of closely related teams.

Level 7 & 8: Principal and Senior Principal Engineer

Levels 7 and 8 represent the elite tier of engineering talent at AWS. As a Level 7 (Principal Engineer), you move into a strategic role, shaping the technical direction across multiple teams or an entire organization. They work closely with senior leadership and are responsible for solving complex, high-impact problems that affect large parts of the business.

The Senior Principal Engineer (L8) sits at the pinnacle of technical innovation. These engineers define long-term technical vision for major areas of AWS, often influencing hundreds of engineers indirectly through architecture, standards, and strategic initiatives.

Level 10: Distinguished Engineer / VP

Beyond Level 8, the roles become extremely rare. It’s reserved for a small group of engineers with company-wide or industry-level impact. These roles focus on setting long-term technical direction, solving the most complex architectural challenges, and influencing Amazon’s strategy at the highest level.

Level 10 is reserved for world-renowned visionaries and thought leaders who have a remarkable track record of technical excellence. They are responsible for identifying future technology trends and anticipating market shifts years before they happen. They set the architectural principles and technical standards that position Amazon as a continued leader in the industry. As mentors to the company’s highest technical leaders, they foster a culture of innovation that ensures AWS remains at the cutting edge of what is technologically possible.

What makes AWS levels different?

1. Leadership Principles (LPs) as a metric

Technical ability alone is not enough for promotion. Engineers are evaluated against Amazon’s Leadership Principles, which are used as a framework to assess impact, decision-making, ownership, and long-term thinking. As engineers progress through levels, they are expected to demonstrate these principles with increasing scope and consistency. Promotion depends on how well your work maps to multiple principles, not just one.

2. The power of the “Doc”

AWS is a famously “silent” company. They don’t use PowerPoints, they use 6-page memos. Your ability to move from L5 to L6 depends heavily on your writing. Can you argue your architectural choices in a structured, data-driven document? If you can’t write, you can’t lead at AWS.

3. Total Compensation (TC) structure

AWS compensation is uniquely structured compared to Google or Meta. While they have recently increased base salary caps, a large portion of your wealth comes from RSUs (Stock) with a 4-year vesting schedule:

• Year 1: 5%
• Year 2: 15%
• Year 3: 40%
• Year 4: 40%This “back-loaded” vesting is designed to reward those who stay and grow through the levels.

AWS salary expectations (2026 estimates)

To provide an accurate picture of what these roles pay, we analyzed the latest 2026 data aggregates from Levels.fyi and 6figr.com, which utilize verified salary stubs from engineers in major tech hubs. Compensation at AWS varies significantly depending on team, location, and negotiation, but follows a consistent structure of base salary, bonus, and stock (RSUs).

Note: These figures reflect top-tier offers in high-cost US markets. For European hubs like Dublin, Luxembourg, or Berlin, expect a 15-25% reduction in base cash, though stock grants remain aggressive.

Is the climb worth it?

The AWS ladder is demanding and often associated with a high-performance culture. Engineers who progress through it tend to develop strong ownership, system design skills, and operational discipline.

While experiences vary by team, time at AWS is generally seen as a strong signal of technical capability and execution, particularly at senior levels. For those who align with its culture, the system offers a clear path for growth.

The post Inside the AWS Hierarchy: Engineering Levels Explained appeared first on ShiftMag.

I have to be honest; this path is laden with high expectations, stereotypes, and the constant pressure to prove oneself.

But it’s also a journey of resilience, empowerment, friendship, and breaking barriers.

So, you may ask, what does it feel like to be the only girl in a team or a company? In some cases, it’s not a good feeling.

Who’s going to organize a party?

Arriving at a site and noticing all eyes on you, simply because of your gender can be disconcerting.

Women in tech understand that it can take time to find friends, as there may not be many female peers who can relate to their experiences. You long for someone who can reassure you and help alleviate the stares. It often feels like a game of musical chairs in your mind, where you anticipate being the one left standing.

Therefore, women must exert additional effort, determination, and speed to establish their position in an environment where they are frequently perceived as outliers.

Also, day-to-day work life for female engineers can go beyond coding – it often entails being both voluntarily and involuntarily nominated as the diversity and non-technical-stuff champion.

In my previous jobs, I learned that being assigned certain tasks often reflects an underlying expectation for women to fulfill specific roles. Such tasks included organizing meetings and lunches, buying gifts for other employees on various holidays, arranging and preparing rooms for meetings and taking notes from them, or representing the company at external events to ensure ‘representation and diversity.’

For some reason, these requests were always the first to go to me or possibly another female colleague. It’s a delicate balance between embracing the role of a team player and ensuring I don’t inadvertently box myself into stereotypes.

But, while organizing team events and managing administrative tasks, I’ve learned the importance of volunteering for projects that push my limits, not just those that fit into stereotypical female roles.

Stand out but also fit in

The pressure to stand out while also fitting in is a constant companion for some of our colleagues.

Our actions, I’ve noticed, can be magnified – it is a double-edged sword that’s both a curse and a blessing. This means that every mistake I make can seem bigger, but it also means that my successes can be more visible.

By being “The Only One,” practically everyone around you associates your name and you alone. This makes people more likely to notice and remember your actions.

I used to feel reluctant to ask questions or clarify doubts, worrying that doing so might reinforce stereotypes about women’s technical abilities, even though seeking clarification is a normal part of the learning and development process.

This visibility has forced me to constantly confront imposter syndrome, undermining the feeling that I have to work twice as hard to be considered at least half as good. It’s a struggle in which I’ve had to learn that my worth is not diminished by my gender and that certain limitations can be created by me in my head.

My journey has been riddled with moments that remind me that I am navigating a space that was not originally designed for me. From the awkwardness some colleagues exhibited around women to being labeled as “too loud, too pushy” in discussions or conversations – whereas some male colleagues displaying similar behavior were described as “assertive” and “passionate.”

There were times when I presented some topic or joined a discussion, and I could feel the dynamics and energy change immediately – people were more skeptical, answered questions as if I had joined the team yesterday, or I got the feeling they were trying to disagree with me by force.

It’s like I was constantly being measured by a different standard that fluctuates between being too feminine and not feminine enough.

One of my biggest challenges has been integrating into teams, where I am the exception. While trying to adapt to such an environment, it can be tempting to “become one of the guys,” it’s the kind of survival tactic that, while effective, often makes you replicate these uncool behaviors rather than trying to change things for the better.

If I had to give any advice on how to find oneself in such a situation, it would be to communicate very directly with others and not be afraid to speak up for yourself. Don’t doubt yourself. If someone interrupts you or tries to take over what’s yours – speak up.

But if that doesn’t work, find a new team, the one that accepts you as a woman and as an engineer.

Embrace the uniqueness

Despite these challenges, I’ve discovered that my unique position as the only woman on the team can bring noteworthy perspectives.

My journey in navigating male-dominated spaces has honed my communication skills, enabling me to navigate and mediate complex discussions with various people quite easily. It can also positively influence team dynamics and help with conflict resolution and customer interactions.

My experiences have taught me the importance of empathy and emotional intelligence in tech – a field often criticized for its lack of understanding. These “soft skills,” which I bring to the table, partially complement the team’s technical expertise, driving us toward more nuanced and holistic solutions.

I have learned not to take failures, criticism, and differing opinions personally. In my opinion and experience, in male teams, everything is talked about much more straightforwardly, without being crude, and nobody has a problem with it. We discuss ideas and actions, not individuals. If someone says, “This idea is stupid because of …” – no harm, no foul.

Once you have experienced the situation of being “The Only One” and fully face it, you will forget that you are a “female engineer” and start to think that you are an individuated co-worker, equal to everyone else.

You will not be surprised by any similar situation in your life or future jobs. You will know your value, and you will always stick to it.

The woman who coined the term “software engineering”

Diversity and inclusion in tech require a collective effort, not an individual pursuit.

Looking ahead, I draw inspiration from pioneer women who have shattered ceilings and paved the way for others like me. Their stories are not just tales of personal achievement but beacons of what women can accomplish in the face of adversity.

If you’re not familiar with Margaret Hamilton, a name synonymous with the Apollo missions, led the software engineering division at MIT under NASA’s Project Apollo. Her groundbreaking work in developing the onboard flight software for the Apollo missions was critical to the success of landing astronauts on the Moon.

Hamilton dedicated herself to her work and innovatively approached software development, thereby coining the term “software engineering.” She pioneered this discipline at a time when the aerospace engineering community had yet to recognize the crucial role of software.

Her vision and tenacity in a field dominated by men during the 1960s demonstrate the profound impact one person can have on technology and space exploration. Hamilton’s legacy teaches me the power of perseverance and the importance of pioneering new frontiers, regardless of the obstacles.

On the other hand, Susan Wojcicki has revolutionized YouTube as CEO since 2014. Under her leadership, YouTube has not only grown into a global platform but has also become a critical space for voices from diverse backgrounds to be heard.

Her advocacy for gender equality and diversity in the tech industry is evident in her initiatives to promote female representation and inclusion. Her efforts to implement family-friendly policies at YouTube, including extended maternity leave, have set new standards for supporting women in the workplace.

These stories illuminate the path and assure me that the journey towards diversity and inclusion in tech is not a solitary one but a collective endeavor enriched by the contributions of those who dare to dream and break barriers.

I hope it continues to inspire the next generation of female developers. It’s a reminder that our differences are our strengths, and through embracing them, we can reshape the tech industry to be more inclusive, innovative, and reflective of the world it serves.

The post The journey of a lone female software developer appeared first on ShiftMag.

Picture a team arguing over whether to keep a global Redux store or roll out a context-only solution for a new React component. Minutes later, someone pushes a change that breaks the whole test suite.

A week later, another debate erupts about whether the REST API should be versioned or use a graph-based approach. And there’s always that one Git rebase that turns a quiet sprint into a full-blown firefight.

The line between brilliant innovation and productivity meltdown is thinner than you think – and ego is often the culprit lurking behind every heated Slack thread and passive-aggressive code comment.

What is egoless development?

Egoless development is not about surrendering conviction or becoming passive. It’s about letting the problem drive the solution, not the other way around. Gerald Weinberg, in his seminal work The Psychology of Computer Programming, wrote: “The most powerful learning occurs when someone produces a better solution than you had imagined.” If your ego can’t digest a “better” or “different” answer, you have no business leading a software team.

In practice, egoless engineering means:

• Staying open to new ideas – even if they come from a junior teammate or an external library.
• Focusing on the product’s value – not on proving your own architectural choices.
• Accepting feedback without defensiveness – because every line of code is a hypothesis, not a manifesto.
• Separating self-worth from code quality – your value isn’t measured by how rarely your code needs revision.

How ego shows up and undermines everything

Ego erodes trust, inflates the perception of individual contribution, and turns collaboration into a zero-sum game. The consequences ripple outward: missed deadlines, higher bug counts, knowledge silos, and ultimately, a loss of team morale that drives your best people toward the exit.

The psychology behind code ownership

When we write code, our brains treat it as an extension of ourselves. Neuroscience research shows that criticism of our work activates the same neural pathways as physical threats. This is why a simple “This could be refactored” comment can feel like a personal attack.

Understanding this psychological reality helps us build better defenses:

• Recognize the feeling – When defensiveness arises, pause and acknowledge it
• Reframe criticism as collaboration – Someone improving your code is helping you, not attacking you
• Build emotional distance – Use phrases like “the code” instead of “my code”
• Practice receiving feedback – Like any skill, gracefully accepting criticism improves with practice

Real examples of ego at work

Linus Torvalds, creator of Linux, became known for a harsh communication style on the Linux Kernel Mailing List, often going beyond technical feedback.

In 2015, during the “Brain Damage” incident, he dismissed a developer’s security proposal as “mindless security theater” and called it “brain damaged.” The developer stopped contributing, and the security concern became a real exploit two years later.

The fallout? Talented contributors left, community diversity dropped, and valid concerns were ignored based on who raised them.

After years of this, Torvalds took a break and issued a public apology in 2018, acknowledging that his ego had harmed the project and committing to a Code of Conduct.

Even brilliant technical leaders can cause real damage when ego outweighs empathy – but egoless engineering is a conscious choice.

Now let’s see egoless communication in action

This is my own example. It was 2:37 PM when my code hit production. By 3:00 PM, our monitoring  tool sent alerts all over and showed 50 errors. New users couldn’t sign up. Existing users couldn’t complete their profiles.

This is where most teams spiral. Blame gets assigned. Confidence gets crushed. Someone becomes the cautionary tale.

Not this team.

The team lead’s first message: “Okay, let’s work the problem. Ivan, walk us through what happened – no judgment, just facts. Everyone else, what do we need to stabilize right now?”

My response: “I skipped the integration test because I thought it was just an isolated signup flow change. Clearly, I was wrong. I can roll back immediately, then we need to figure out why our CI didn’t catch this.”

Ten minutes later, production was stable. The retrospective didn’t focus on my mistake – it focused on the process gap. Why weren’t integration tests enforced for all changes? How could CI catch this automatically?

System got fixed and the whole team started advocating for comprehensive testing.

Lead with purpose, not ego

The antidote to ego-driven culture is a purpose-driven mindset. Put the team first: “Ship better products. Learn together. Celebrate collective wins.”

Adopt core values such as:

• Open collaboration – Everyone’s input matters, regardless of tenure or title.
• Continuous improvement – No single person owns the ship; we all keep it afloat.
• Shared ownership – Success is a team metric, not a résumé headline.
• Blameless culture – Focus on systems and processes, not individual fault.
• Intellectual humility – “I don’t know” is a strength, not a weakness.

These values create a safety net that lets people experiment, fail fast, and iterate without fear of ego-related retribution.

How to cultivate egoless teams?

1. Morning coffee feedback sessions

Schedule a quick, informal chat with each teammate once a month.

Purpose: Surface concerns early, show genuine interest, reinforce the “we” narrative.

Pro tip: Keep it casual – grab actual coffee, go for a walk, or just sit outside the usual meeting room environment.

2. Code review as conversation

Treat every PR as a dialogue, not a verdict.

Instead of: “Why did you do that?”
Try: “I’m curious about your approach to X – what tradeoffs did you consider?”

Key practices:

• Assume good intent always
• Ask questions before making statements
• Provide context for your suggestions
• Praise the good before noting improvements

3. Process-focused retrospectives

Avoid blame, focus on improving the workflow.

Outcome: The team learns to iterate on their own practices, identifying systemic issues rather than scapegoating individuals.

Framework to try: Use “What went well? What could be better? What will we try next?” instead of “Who caused the production incident?”

4. Celebrate team wins

Highlight milestones that benefited the whole product, not individual heroics.

Effect: Reinforces that value comes from collaboration. Consider a “Team Win Thursday” where you spotlight collaborative achievements in your all-hands.

5. Rotate responsibilities

Give everyone a chance to lead a sprint, own a component, or make architectural decisions.

Result: Empowers diverse viewpoints and reduces power-centered thinking. It also prevents knowledge silos and builds empathy for different roles.

6. Create a “learning debt” board

Just like technical debt, track what the team needs to learn.

How it works: Anyone can add skills or knowledge gaps. The team prioritizes learning together through lunch-and-learns, workshops, or dedicated study time. This normalizes not knowing everything.

Purpose-driven teams really excel

The data backs up the philosophy:

• Faster problem solving – Collective knowledge surfaces solutions faster.
• Higher-quality products – Diverse eyes catch more bugs; studies show pair programming can reduce bugs by 15-50%.
• Happier teams – People feel valued beyond ego metrics.
• Lower turnover – People stay when they feel part of something bigger; psychological safety is the #1 predictor of team success (Google’s Project Aristotle).
• Innovation acceleration – When failure isn’t punished, experimentation flourishes.

In our own team, we’ve seen the difference. The “Misfit Days” workshops we introduced – short, daily stand-ups where anyone can bring a friction point- have slashed bug-backlog time by 35% and doubled the rate of new feature delivery. More importantly, our employee satisfaction scores jumped 28 points in six months.

Warning signs your team has an ego problem

Watch for these red flags:

1. Pull requests sit for days because no one wants to critique the senior dev.
2. “I told you so” moments are celebrated instead of collective problem-solving.
3. Knowledge hoarding where individuals protect “their” domains.
4. Defensive Slack threads that spiral into 47-message arguments over syntax.
5. Silent meetings where juniors don’t speak up for fear of looking stupid.
6. Resume-driven development where tech choices prioritize personal branding.
7. Hero culture where all-nighters and firefighting are glorified over prevention.

If you recognize three or more of these in your team, it’s time to intervene.

What should I do?

Ego is a silent saboteur that thrives in the quiet corners of code reviews and pull-request comments. It whispers that your solution is the only solution, that criticism is an attack, that admitting uncertainty is weakness. But the best engineering teams know differently.

By embracing egoless engineering – focusing on shared purpose, valuing every voice, and making collaboration the default – we turn potential productivity meltdowns into engines of innovation. The code improves, the products ship faster, and most importantly, people actually enjoy coming to work.

Remember: The best code you’ll ever write is the code you wrote with others. The best solution you’ll ever implement is the one that made someone else’s idea better. And the best career move you’ll ever make is building a reputation as someone who makes everyone around them better.

Starting tomorrow:

• Implement a monthly open-feedback routine – Put it on the calendar now.
• Audit your code review comments – Are you asking questions or issuing verdicts?
• Celebrate a team win – Find one this week and make noise about it.
• Try one new strategy – Pick from the list above and experiment for a sprint.

Every idea is respected. Constructive feedback is not just welcome; it’s required. Success is measured by shared achievements, not individual credit.

The post Developers, your EGO is the real bug in the system appeared first on ShiftMag.

We all agree: saying no is important – it can be liberating, support work-life balance, and is a crucial life skill.

What’s discussed far less is the cost of refusing, especially the psychological cost. That’s what I’d like to explore: the emotional toll of refusing – on ourselves and on those we ask for something, even when we reassure them, “It’s totally fine if you can’t.”

It’s hard to refuse – and all too easy to agree

Overall, saying no often carries negative connotations, which is why we tend to avoid it. We dislike being in situations where our words or actions might be perceived as negative. It becomes even more difficult to decline in person – especially when we know the person well or feel emotionally connected to them or the topic.

People are generally more dismissive online or in anonymous settings, where the perceived consequences are minimal. It’s much easier to ignore or mock a request to “like” a post on social media than to say no to your mum when she asks for help picking apples.

In a professional setting, declining becomes even more complicated.

We’ve created a work culture where declining requests too often can feel like a career risk, especially for women and members of minority groups. Declining isn’t only disappointing for the person who asked; it might also mean missing out on a promotion or an exciting opportunity. Holy carp!

Conversely, accepting is effortless.

It feels nice and positive. You’re pleasing the other person, maybe even securing a future reward for yourself. What could be better? Since humans are wired to chase immediate rewards and often overlook future pain, we tend to say yes just to see that happy twinkle in someone’s eye – consequences be damned!

If you Google “how to say no”, you’ll get a lot of results, mostly focused on the actual skill of rejecting something. If you Google “how to say yes”, you mostly get results about how to say words and phrases in different languages. Declining is a tricky soft skill; accepting is often just about language.

Turning something down is… stressful.

So, where are we with no?

• We’re not that great at saying it.
• It’s not a pleasant thing to do.
• It can have negative consequences.

As a result, it’s often stressful to refuse a request.

We tend to worry about it before, during, and after the fact. This stress can be even worse if we’re already dealing with things like burnout, impostor syndrome, or anxiety. Saying no in those situations can feel like adding fuel to the fire. If I already don’t believe I’m doing a stellar job, turning something down might only reinforce the fear that others see me as a failure.

Our tendency toward herd mentality doesn’t help either. When most of the team says yes and we’re the only ones who want to say no, we often end up going along with the group, even if we feel conflicted inside.

Many of us have experienced this in sprint planning and sprint reviews – the team takes on more work than necessary during planning to avoid refusing requests, and then feels deflated and disappointed when they can’t deliver everything by the end. Over time, this can hurt team morale and spirit, lower motivation, and even create a toxic dynamic between teams and their stakeholders.

All of this leads to a simple point: refusing comes with its own burden. Telling someone to “just say no” can be disingenuous – placing the emotional and social cost of rejection on them, while pretending it’s easy.

Expecting a simple refusal hurts the ones who care most

The people who are most invested in a project, those who care deeply about the quality of their work and their team’s delivery, often your “best performers”, are usually the ones who find it hardest to say no. As a result, they often take the initiative to pick up tasks that others might reject.

If you keep asking, they may continue to agree, depending on their situation, until they eventually hit a wall and burn out.

Be kind. Don’t act like no is just a simple word

We should be mindful of our colleagues’ workloads and, whenever possible, avoid asking them for additional tasks if we know they might already have a full plate.

It’s important to recognize that they may feel unable or reluctant to refuse, even when they want to. And even when they do refuse, it can still come at a cost to their emotional well-being or personal life.

We should also recognize that refusal comes in many forms. It can mean:

• Literally saying no.
• Taking only 5 tasks out of 10 that were offered.
• Choosing not to volunteer when most others do.
• Not attending a meeting or participating in a Slack discussion.

All of the above can be difficult to do and may lead to negative consequences down the road, for both the individual and the team.

What’s the solution?

• Talk openly with your colleagues. Be aware of the challenges they face and the workloads they carry. Don’t expect them to simply reject additional work – understand their situation through honest conversations.
• Keep expectations realistic. Avoid presenting people or teams with overwhelming wish lists they can’t reasonably deliver. Don’t assume others will just say no to unreasonable demands.
• Diversify your requests for help. Instead of always turning to the same people who tend to say yes, reach out to others and distribute the load more evenly.
• Avoid herd mentality pressure. Give individuals space and time to make decisions independently, and encourage sharing outcomes in a safe environment. This is why practices like writing retrospective points individually or revealing estimations simultaneously in planning poker are important.
• Lead by example. Show that saying no when it’s appropriate is acceptable. Recognize that you might also struggle with this and discuss it openly with your team.
• Establish fair systems and processes. Ensure workloads are distributed transparently and fairly, rather than relying on informal methods that often favor those who find it easier to say no – which can unfairly burden those who care most about the project’s success.
• Don’t reward or idolize overwork. Encourage a culture that values balance and sustainable effort over relentless hustle.

The post Saying NO is not a free action in the world of software engineering appeared first on ShiftMag.

This mythical creature moves faster than entire teams, rewrites whole systems on a weekend, and operates on raw brilliance and caffeine alone. Companies whisper about finding one, like hunters chasing Bigfoot footprints in the mud.

But Charity Majors – co-founder and CTO of Honeycomb – whose lecture I had the opportunity to attend at this year’s Craft Conference in Budapest – isn’t interested in chasing unicorns or Bigfoot. She wants you to build something stronger and less flashy: a “boring” engineering organization where shipping is safe, tools are sharp, and learning is routine.

The hero engineer is an illusion

“Stop worshipping at the altar of individual brilliance,” Charity says. “The fastest, healthiest engineering teams don’t run on heroes. They run on habits.”

We all know the “hero engineer: up at 2 a.m., fixing what no one else can, holding the whole system in their head. It’s a romantic image, but it doesn’t scale.

Here’s the uncomfortable truth: organizations built on heroes eventually break. If shipping relies on a few brilliant outliers, you’re not building a system; you’re betting they never burn out, quit, or block others.

Charity’s take? Build a world-class engineering organization that never needs heroes in the first place.

Shipping is a way of life

If there is a single non-negotiable truth in Charity’s worldview, it’s this: shipping is how engineers learn.

Not architecture diagrams. Not months of planning. Not 400-comment design docs. Shipping.

The faster your team can ship, the quicker they get feedback. The faster they get feedback, the faster they course-correct. And the faster they course-correct, the quicker they grow – not just as individuals, but as a unit.

You don’t need 10x engineers if you have a 10x feedback loop.

That’s why she champions small, continuous, reversible changes. She obsesses over reducing the time it takes to run tests, deploy, and observe production.

When shipping is slow, testing is slow, and every deploy feels like a minor act of self-endangerment, you create what she calls the “dark matter of suffering” – the invisible drag on velocity you don’t notice until your team feels like it’s wading through molasses.

This is why world-class orgs invest heavily in:

• High-quality tests that run fast enough to be trusted.
  
• Observability tooling that lets engineers see precisely what’s happening in production.
  
• Internal developer tools that remove friction from every part of the engineering cycle.

These aren’t “nice to have” perks. They’re what turn engineering from guesswork into craftsmanship and make shipping feel like breathing, not pulling teeth.

And here’s the kicker: when you make it fast and safe to ship, engineers stop worrying about breaking things and start focusing on building things.

Your org is a system (and it’s training your engineers)

One of Charity’s sharpest insights is that every engineering organization is a system, and every system produces the engineers it deserves.

If you give people slow CI pipelines, fragile deployments, and a production environment that feels like a haunted house, they will adapt by becoming risk-averse. They will fear change. They will learn to optimize for personal survival instead of team velocity.

But if you give them short feedback loops, strong tooling, and a culture that treats mistakes as learning opportunities, they will become bold, learn judgment, and ship.

This is the beauty of boring systems: they’re self-reinforcing. Every test you speed up, tool you sharpen, or friction you remove pays off every time you hire, switch teams, or learn something new.

You don’t have to go hire “world-class engineers.” You create them.

Who thrives at your company isn’t random – it’s a systems choice

During the Q&A session following her talk, I asked Charity a question that I believe lies at the core of this entire debate:

“How can managers shift their perspective on who is considered the best and who will thrive within their organization?”

You must start by observing who is thriving in your organization. Take a look. If you notice that the same narrow demographic keeps sticking around, that’s not an accident. It’s a systems issue.

She shared an example from Etsy: They fostered an engineering culture that celebrated deep care for code craftsmanship, which naturally attracted individuals who shared those values.

“You can’t do this alone as a manager,” she continued. “If you try to build a perfect little team culture in isolation, it will clash with the broader organization and likely fail. You need organizational support. But, simultaneously, you must be willing to identify the types of engineers your organization rewards – and ask yourself if that aligns with your goals.”

Charity’s “golden path” for balancing stability and innovation

I also took the opportunity to ask Charity about a challenge that many managers often find themselves grappling with:

“How do you balance fostering a “boring” engineering organization and supporting engineers’ enthusiasm for exploring new and exciting technologies?

Without hesitation, Charity provided a thoughtful response:

The more foundational your work is, the more conservative you should be.

“You cannot afford to be reckless if you’re handling databases or operating systems. These are the building blocks of your system, so ‘boring’ is essential in those areas.” She adds that if you’re working on developer tools or front-end experiments, you have more flexibility to innovate – it’s a spectrum.

She then introduced what she calls her “golden path” principle:

You define a well-supported, official stack as the “paved road”. If you venture off that path to explore something new, you take responsibility for maintaining it yourself. This ensures stability where it’s most needed while providing space for safe experimentation.

For Charity, the goal isn’t to stifle curiosity but to guide it in a way that fosters stability and innovation.

The right people, not the “best” people

This is where the “10x engineer” myth dies. Stop looking for the “best engineer” and start looking for the right engineer.

The right engineer isn’t the one who crushed every LeetCode problem in 30 seconds. It’s the one who’s excited about your difficulties, communicates, lifts the people around them, and can learn faster than the job changes.

At Honeycomb, says Charity, the interview process is built around conversations, not quizzes. Candidates walk through real-world scenarios with the engineers they’d work with:

• Why did you build this feature the way you did?
  
• What tradeoffs did you make?
  
• If you had more time, what would you change?
  
• How do you explain this to someone new?

Here’s the thing: many engineers can do the work, but those who can teach, explain, and collaborate multiply their value.

And new engineers? They’re gold. When everyone’s learning daily, no one coasts or repeats the same task on autopilot. They stay challenged, grow, and stick around.

Stop hunting unicorns. Start building systems!

Excellence at a 12-person startup differs from a 50.000-person enterprise, and both differ from open source. But one principle remains: in the long run, it’s not a few brilliant engineers but the compounding of hundreds of small, boring, unglamorous tasks that powers great companies:

• Fast, safe deploys.
  
• Clear, visible systems.
  
• Tools that remove friction.
  
• A culture where learning is normal.
  
• A hiring process that looks for the right people, not the loudest ones.

nd the result? A team that ships, learns, and grows. That’s not just sustainable – it’s unstoppable. So next time someone asks if you’re hiring “10x engineers,” smile politely and tell them the truth:

You don’t need 10x engineers. You need a 10x organization.

“And yes, it’s boring. But only in the way gravity is boring: invisible, inescapable, and the only reason anything stays standing”, Charity concluded.

The post Stop Hunting 10x Engineers: Build a 10x Organization Instead appeared first on ShiftMag.

Fast forward a couple of decades, and he’s now a Lead Developer Advocate based in the Netherlands, with a career that’s taken him through roles at Amazon, InMobi, and his current position at AuthZed.

In this interview, Sohan talks about the rise of Developer Relations, why good authorization matters, and how AI is changing the game (great for debugging, not for writing your novel).

You have more than 10 years of experience in Developer Relations. How important is it for developers today?

Sohan: I started in DevRel in 2014; it was very niche back then. Look at the evolution of tech in the decade since – there’s been a massive increase in the number of technical products, frameworks, SDKs, and APIs. There’s also been an exponential increase in developers (and I use this term as an umbrella for all hands-on technical people) during this time.

This means that companies building technical products need a Developer Relations program. It’s as simple as that. Look at companies that have strong brand recognition within developer communities -Vercel, Twilio, and AWS, to name a few – they all have really strong Developer Relations and community teams that make this possible.

A few months ago, you gave a lecture at the Heapcon conference focused on Authorization. Could you tell us more about this term?

Sohan: Let me explain it with an analogy. Imagine you want to go on a trip to another country. Among the essentials you’ll need are a passport and a visa. Your passport tells the other country who you are and provides the information needed to identify you uniquely – this is authentication. A visa, on the other hand, permits you to enter the country you’re visiting – this is essentially authorization.

To break it down more technically, authentication is the way an entity verifies someone is who they say they are. Once a person’s identity has been verified, authorization allows access to an asset.

Here’s a real-life example we’ve all encountered: when you share a Google Doc, you can select whether the recipient is a Viewer, Commenter, or Editor. This is authorization – that is, allowing a specific level of access to an object.

What benefits Authorization can bring for applications?

Sohan: The Open Worldwide Application Security Project (OWASP) is a non-profit industry standards organization that publishes an annual list of the Top 10 Security Risks for Web Applications. Guess what topped their list this past year? Broken authorization.

Our tech stacks and applications are becoming increasingly complex, yet most businesses still write their own authorization code. While this might work for smaller, simpler apps, it becomes challenging to maintain as you scale up.

Just as you’d never build your Authentication, you shouldn’t be writing your Authorization code. The benefit of using an industry standard is that you can get global-scale authorization with correctness and low latency while focusing on building your business use case.

How do you see the integration of AI technology in the development world?

Sohan: What’s surprised me the most is how quickly generative AI tools have been adopted into our daily workflows. In the past, enterprises would take their time to build proofs of concept before adopting new technology, but with generative AI, the entire industry has embraced it at an unprecedented speed. I see this as the first wave of generative AI adoption.

With any new tool or technology, there’s an inflection point where people understand its strengths and limitations. From a personal perspective, I love how generative AI helps me debug code or give feedback on a YAML file – tasks that are well-defined and structured.

At the same time, I’m not a fan of the deluge of AI-generated content we’re seeing right now – Areas that need creativity and human expression. I think (or I hope!) that in the near future, there will be some normalization of where AI is applied and where it doesn’t add value.

What tech trends should developers pay attention to in the future?

Sohan: This first wave of generative AI was largely about augmenting human workflows with AI-code snippets, text generation, information retrieval, and so on. All the tooling and SaaS products were built around this idea. I think the next trend will be autonomous agents powered by AI that can do more complex tasks.

I love thinking in terms of second-order effects, so the question becomes: what are the second-order effects of this agentic future? New infrastructure, innovative methods to authenticate and authorize your RAG stack, and deeper integrations with existing platforms will enable AI agents to carry out their operations. This is a trend I foresee emerging in the near future.

At the same time, if you zoom out of the AI world and look at the tech ecosystem, you can see a growing number of specialized tools for every need. We’re no longer in a world where a one-size-fits-all approach works.

In the quest for faster, better, and cheaper, it’s about picking the right tool for the job, and there are so many specialized tools out there for YOUR job. The trend I see is the fragmentation of tooling, frameworks, and services to suit different use cases.

What are your professional plans for the next period?

Sohan: Professionally, I’m focused on building a world-class Developer Relations program for AuthZed -an exciting space! The rapid industry change means it’s crucial to keep skills up to date.

At the same time, staying agile in thinking and decision-making is key. It’s easy to rely on past methods, but with constantly changing variables, I regularly re-evaluate my frameworks to stay open to new approaches.

The post Sohan Maheshwar: Authorization Is Key to App Security – Don’t Get It Wrong! appeared first on ShiftMag.