What’s the worst type of project?

Sure, the term “worst” means different things to different people, but most of the engineers agree: the worst types of projects are the ones that aren’t set up well by humans, not the ones that have big technical requirements. And, as you can probably guess, human-designed flaws are much more creative.

For example, one engineer highlighted that the worst project for him was working with family members who were not familiar with software development at all, affecting expectations, realisations and everything in between.

Another situation was a client project that took four months, with progress going smooth up until the last month. Nikola Buhiniček, Engineering Manager, said:

The client changed the scope significantly without much warning. We had to abandon a lot of the work we’d already done and come up with new features and opportunities. It felt like compressing two and a half months of work into one month before the deadline.

Another type of projects that drive engineers crazy are legacy code projects without real instructions on how to approach them, as explained by Edvin Teskeredžić, Senior AI Software Engineer:

We had this old legacy project, basically 10-year-old code which needed to be maintained. It was also all internal libraries but there was no documentation. The documentation simply lived in the heads of senior engineers, so you had to kind of figure it out yourself, and you couldn’t Google it because it was all internal libraries.

What’s the best, then?

In contrast, the best projects tend to be tied to others as well, only this time it’s about great teams and good colleagues. For some engineers, the best projects are those where leadership has a clear vision and that vision is clearly shown to the teams.

Other engineeers, such as Filip Bolčić, Full-Stack Engineer, highlighted teamwork as the best part of the projects they’ve worked on. For example:

Everybody’s insight was really valuable, and I had a great mentor from whom I learned a lot. It was just a really meaningful project for us, we felt really good working on it.

On the other hand, Nikola noted that sometimes, the best projects are the most challenging ones. He explained the process of adding the automations feature to Productive was one of the more challenging and interesting ones he worked on:

It was such a different feature from what we used to do, and I was given the opportunity to build it. In the end it was one of the best features we have. The usage is growing up from month to month. I’m really happy that it was something that I built like two years ago, and it’s still growing so fast.

It all comes down to the human factor

The hardest thing to fix as an engineer might not even be software-related, according to Hrvoje Rančić, Senior Software Engineer:

My posture. I had really terrible back pain from sitting too much during the COVID era. I think this is a very dangerous job because it involves a lot of sitting, and sitting is the new smoking, so I encourage everyone to move more if you’re a software engineer.

Ergonomics aside, Software Engineer Emin Mulaimović said that some of the biggest recent challenges he had were related to LLM’s:

We had this unstable LLM prompt which basically means you ask the same question and it gives different answers, and the answers are not marginally different. To fix that you just need to rephrase the question over and over and over again until it worked. And then when it worked you didn’t learn anything, you didn’t have fun fixing it, you’re just glad it’s over. Some bugs are fun to fix; this one wasn’t.

On the other end of the spectrum, the toughness of a task comes down to a personal mistake by the engineer themselves, and there’s rarely anything you can do but to fix it. That’s exactly what happened to Filip:

I remember working on a really big-scale production application and accidentally just deleting a lot of important stuff from the database. I was really young in my career and I remember being really stressed out about this, but the project manager protected me and we were able to restore a backup of this database, so in the end everything was good, but it was really stressful for me.

And to further drive the point home, sometimes the fix isn’t even tough, but so time-consuming you think you’re going crazy, as evidenced by Olga Koroleva, Engineering Manager:

I made a bug in the code where entries to the database were written wrong, and I had to manually fix thousands of them. After that, I always double-checked and triple-checked everything.

Make sure to check out the entirety of the video to find more about the best and worst projects, and the challenges of software development!

Special thanks to our engineering colleagues at Infobip, Nikola Buhiniček (Engineering Manager, Productive) and Filip Bolčić, (Full-Stack Engineer, Ars Futura).

The post Developers are the reason behind best (and worst) parts of software development appeared first on ShiftMag.

But what does that career structure actually look like?

To answer that, we explored publicly available discussions on platforms like Reddit and Dev.to, connected common patterns, and compiled a clear overview of the Google engineering ladder.

What the Google engineering ladder looks like

Public sources generally describe Google’s engineering levels like this:

At the early stages, engineers typically focus on learning, delivering well-scoped tasks, and becoming independent in familiar problem spaces. In contrast, at higher levels, the emphasis shifts toward technical strategy, cross-team collaboration, and creating impact that extends far beyond individual contributions.

Google rewards increased scope, greater leverage, and sustained impact over time

A common misconception is that more years of experience automatically lead to higher levels. However, reality is more nuanced. Instead, Google evaluates engineers based on scope, impact, and influence.

At lower levels, engineers are expected to:

• Learn systems quickly and effectively
• Deliver tasks with appropriate guidance
• Collaborate closely with teammates
• Build strong technical independence over time

As engineers progress to mid-level roles, expectations expand. They are expected to:

• Lead complex projects from start to finish
• Make sound technical decisions under uncertainty
• Navigate ambiguous requirements
• Take ownership of systems or features
• Communicate effectively across teams and functions

Meanwhile, at higher levels, the focus shifts again. Engineers are expected to:

• Influence multiple teams and stakeholders
• Understand organizational and technical context broadly
• Define or shape technical direction
• Solve systemic rather than isolated problems
• Multiply impact through others
• Act as anchors for large-scale initiatives

Senior vs. staff

The transition from Senior to Staff is often considered one of the most significant jumps in the entire ladder.

A Senior Engineer typically:

• Works independently on complex problems
• Leads major features or components
• Understands architecture and trade-offs
• Mentors other engineers
• Delivers impact primarily within a single team or domain

Senior Engineer is a strong individual contributor whose influence remains largely within a defined area.

However, a Staff Engineer operates differently.

A Staff Engineer:

• Focuses on the broader system, not just one team
• Connects multiple teams and initiatives
• Identifies and resolves systemic issues
• Drives cross-organizational projects
• Aligns people, processes, and architecture
• Produces impact that extends beyond direct output

Therefore, the shift is not about doing more work. Instead, it is about expanding influence and creating long-term, scalable impact across systems and teams.

Outcomes matter more than job titles

Google’s leveling decisions are usually shaped by three major factors.

1. Interview Performance

During interviews, candidates are evaluated on:

• Technical depth
• Problem-solving ability
• Analytical thinking
• Role-specific knowledge
• Leadership signals

However, strong coding skills alone are not enough. Candidates must demonstrate they can think like engineers who design and maintain large-scale systems.

2. Previous Experience and Projects

Experience matters, but it is not the only factor.

More importantly, Google looks at:

• What you actually delivered
• The impact of your work
• The complexity of your projects
• Whether you led meaningful initiatives
• Evidence of ownership and responsibility

3. Skill Set and Ability to Create Impact

In addition, Google values engineers who can:

• Learn quickly in new environments
• Make informed risk assessments
• Operate effectively under ambiguity
• Communicate clearly and consistently
• Influence others through credibility and mentorship
• Take responsibility beyond formal assignments

As a result, seniority reflects not only technical ability but also influence and leadership without authority.

How much do Google engineers earn?

Based on public reports, approximate annual compensation ranges often look like this:

For L9 and above, public data is limited, and discussions tend to focus more on rarity and impact than exact numbers.

Overall compensation depends on several factors

It is important to remember that these figures are estimates based on public sources, not official salary disclosures. Actual compensation varies depending on:

• Location
• Level
• Base salary
• Bonuses
• Equity (stock grants)
• Performance
• Team and product area

For this reason, professionals in Big Tech usually refer to total compensation (TC) rather than base salary alone.

What is above L6?

As engineers advance beyond Staff level, their responsibilities become increasingly strategic.

L7: Senior Staff

At this stage, engineers influence multiple teams and broader domains. Rather than solving isolated problems, they help shape how entire groups of teams operate.

L8: Principal Engineer

Principal Engineers define technical direction across large areas of the organization. This role requires long-term thinking, strong systems design skills, and the ability to align complex technical decisions.

L9+: Distinguished Engineer, Fellow, Senior Fellow

Only a very small number of engineers reach these levels. Their influence can extend across:

• Entire organizations
• The company as a whole
• The broader tech industry

At this stage, the focus shifts from implementation to shaping the future direction of large-scale systems and platforms.

What is Google Career Dreamer?

Google Career Dreamer is a career exploration and guidance tool designed to help users better understand their skills and career options.

It helps users:

• Identify transferable skills
• Define their professional identity
• Explore potential career paths
• Prepare for career transitions

Main Features

1. Career Identity Statement
This feature helps users summarize their professional profile for use in resumes, LinkedIn, portfolios, and introductions.

2. Explore Career Possibilities
It suggests roles aligned with a user’s experience and skills.

3. Relevant Jobs Near You
Users can discover job opportunities that match both profile and location.

4. Gemini Support
The tool also integrates AI support for:

• Cover letters
• Resume improvements
• Career planning

In conclusion, the Google career ladder is not defined by a single dimension but by the scale of problems you solve, your influence across teams, your ability to handle ambiguity, your leadership without authority, and the multiplier effect of your work.

The post Google Careeer Ladder for Engineers Explained appeared first on ShiftMag.

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.