While AI coding tools have become a daily routine for most engineering organizations – and 90% of leadership teams cite them as a top priority investment – their impact is still not clear.

A recent LeadDev Engineering Leadership study collected feedback from over 600 engineering leaders globally, and 60% of them reported no meaningful productivity improvements, and 54 % see no headcount reductions from AI use this year.

The tools most frequently adopted are AI coding assistants and productivity analytics platforms, which again confirms what some industry leaders have been saying lately – companies don’t need faster code typers; they need reshaped workflows. Early coding gains often expose systemic bottlenecks.

Interestingly, 51% of leaders believe AI will have a negative long-term impact on the industry. Top concerns include code maintainability (49%) and the impact on junior developers entering the field (54%).

Leadership Must Shift Too

The role of engineering leadership is evolving fast. With tight budgets and the rise of generative AI, priorities are shifting: leaders are reorganizing teams, navigating DEI and burnout concerns, and reevaluating what qualifies as performance and value. Communication, strategic clarity, and empathy now rank alongside technical expertise in leadership skill sets.

Also, burnout is on the rise, especially in shrinking teams asked to do more with less. Engineering managers’ positions have been hit hard in these changing times.

The post No engineering productivity gains, and no jobs lost due to AI appeared first on ShiftMag.

But you know it’s not nearly as simple, and it can all end up surprisingly disappointing.

Why you went with a senior hire probably seems clear: You wanted someone with experience who would require less onboarding and could start solving problems faster, someone who can work on more complex tasks. Someone who can understand and bring your system – maybe even your organization – to the next level. 

So, you do a shorter onboarding (it’s a senior, right?) and start throwing some tasks at them. You probably start with simpler tasks and expect them to gradually build up to more and more complex stuff until they reach their full potential.

Everyone wants a senior but loves a mid

This approach works well with mid-level engineers, as they are expected to learn more, and if they learn well, you can shape them into what you need quite easily. Let’s be honest – everyone loves a good mid since they do most of the actual work. But you probably didn’t hire a senior engineer to turn them into a code monkey. 

The challenge of hiring a senior is that it implies great expectations, but great expectations can lead to great disappointment if managed poorly. And that disappointment may be felt on both sides – yours and your hire’s.

The senior comes with experience – which is why you went for a senior – but this experience comes with a burden that is often overlooked. The amount of experience is directly proportional to their attitude on how to do things the “right” way. And in different companies, a lot of things are done differently, often for a good reason. And often for bad reasons as well. 

The question is how much you really want them to un-learn – and how much you’re ready to un-learn yourself.

How to let seniors be seniors – from the start

It’s normal to expect that a new employee needs to learn, especially in the initial period, but it is easy to forget that this is an opportunity to learn from them as well. This is one of the reasons you went for a senior engineer, isn’t it?

So here are a few ideas you could try out with a new senior hire:

Giving them a challenging task early on

Instead of gradually increasing the complexity of tasks over an extended period, let the senior take on a challenging larger task, like proposing an architecture for something new. Have them pick a narrower domain they feel comfortable in, and give them space and time to show what they can do. 

Review their proposal with other seniors or architects in an open discussion, letting them present their solution. Of course, their first try might not be a perfect fit, but use that as an opportunity for discussion and coaching with other senior staff. That way, you’re also allowing them to connect with other seniors in the company.

Research work

Similar to giving a larger task, let them do a research-type task early—something that requires trying out different approaches to the problem, digging through documentation, or trying different technologies. 

Let them present and discuss their findings in front of the team. This is the type of work you hired a senior engineer for.

Comparing architecture and approaches

Relatively early after initial onboarding, once they have an overall picture, have them compare your company’s architecture and processes to those in their previous job(s). 

Whether they worked in a much smaller system or a completely different domain, you may still find some good ideas and details that apply to you.

Even if there is no direct comparison or advice they can offer at that point, just letting them explain their understanding will help them grasp your architecture earlier—as you truly understand something only once you can explain it to someone else.

Listening to their experience and opening such a discussion will move your relationship closer to the one you’d want to have with your senior.

Let them suggest improvements

After they feel somewhat settled, a few months in, let them write a list of suggestions on improvements they see from their perspective. You may be surprised by the fresh perspective.

If some of their ideas are applicable, let them drive the change. You will benefit from the improvement, and they will start feeling useful since they’re making meaningful contributions.

Good people do slip away from good companies

What all these suggestions have in common is that they try to act on expectations on both ends of a hiring agreement. You expected someone to behave like a senior, and they expected to be treated as a senior. If you are both reasonable, there is an understanding that this takes time. 

But I’ve seen many cases of seniors either giving up in the first year, as the position doesn’t live up to the promises, or because of unsatisfied employers who expected more from that senior hire. And I’ve seen good people slip away from good companies.

So don’t let the senior drown in your company before they learn to swim through your structures.

Set up the onboarding so that they can start delivering small chunks of senior behavior early on, with a close feedback loop. In the process, don’t forget that the learning opportunities are mutual from the beginning, especially in the beginning.

The post How not to waste a senior engineering hire appeared first on ShiftMag.

He also explored the dynamics between engineering teams and product management, offering practical strategies for feature development. Peric highlighted instances where aligning with the product team’s perspective can lead to successful outcomes.

How to build a bridge between Product and Engineering?

If we want to build this bridge, it’s essential to focus on the following pillars:

The dynamic between product and engineering: Ante stresses the importance of fostering a collaborative relationship between product and engineering teams.

It’s important to move away from the mindset of competing priorities.

For developers, this means clearer communication and more aligned goals

Product Backlog Refinement (PBR): To streamline collaboration, Ante introduces PBR as a biweekly process where both teams prioritize tasks. This regular alignment ensures developers are focused on delivering the most impactful features, reducing bottlenecks and improving efficiency.

Product context: The discussion centers on ‘Conversations,’ but the strategies shared can apply to any development project where multiple communication channels and complex workflows are involved

Everyone needs a seat at the decision-making table

Using Infobip as an example, in 2018 the company was a market leader in SMS services and sought to expand by building new products on top of their existing communication channels. To achieve this, the team engaged with customers to gather requirements, with the goal of creating a scalable, real-time, and user-friendly product.

As the product gained traction, the company encountered challenges related to scalability and service stability, highlighting the risks of over-reliance on third-party services.

Balance between features: Ante emphasizes the need to strike a balance between developing customer-facing features and technical improvements that enhance system performance.

Utopian engineering pitfall: Ante also warns against what he calls “utopian engineering,” where teams focus solely on adding new features without considering the impact on performance and reliability.

In large IT projects, it’s essential to prioritize what truly matters, given their complexity and the high expectations of users.

Collaboration and decision-making: It is crucial for everyone (product, engineering, leadership) to collaborate in decision-making to address technical issues and feature development effectively.

The power lies in collaboration and staying proactive

So, what lessons did Ante and his team pick up along the way?

First of all, keep it real and ensure that engineering and product teams are in sync, working hand in hand towards common goals. It’s all about collaboration!

And don’t forget to regularly check in on growth trajectories and any challenges that pop up along the way – especially during those exciting growth spurts. Staying proactive will help you tackle issues before they escalate and keep the momentum going strong!

The post This is how to boost Product and Engineering collaboration appeared first on ShiftMag.

Many engineers prefer writing code and view performance reviews and career management as distractions. However, Kazakov, Engineering Director at Canonical, introduced a new perspective that makes performance and career management exciting and valuable.

Rethinking Performance Management

During his recent talk at the Shift Conference, Kazakov addressed the familiar disgust engineers’ feelings toward performance management. He acknowledged that many see it as an unmanageable process but asserted that engineers can find value.

Engineers can enjoy these processes by refining performance management and integrating it with career development.

Kazakov introduced a Performance and Career Management Framework for engineers and engineering leaders. This framework redefines performance oversight, transforming it from a chore into a growth opportunity.

The Career Management Framework

Kazakov’s framework connects performance evaluation with career goals. Here’s how it works:

Clear Expectations: The framework stresses the importance of setting clear performance metrics directly related to career aspirations. With defined expectations, engineers gain a clearer understanding of how their performance drives future opportunities.

Regular Feedback: Continuous feedback is crucial to personal and professional growth. Kazakov’s framework promotes frequent check-ins to keep engineers aligned with their career objectives and address performance concerns promptly.

Career Development Integration: Kazakov merges performance evaluation with career development rather than isolating it. This approach helps engineers link their day-to-day tasks with long-term career goals, making performance reviews more impactful.

Flexibility and Adaptation: The framework encourages engineers to remain flexible, acknowledging that career goals and industry demands evolve. Developers stay in sync with their career trajectories by adjusting the performance management process to fit these shifts.

Not a Bureaucratic Formality

Making performance evaluation part of career development makes the process more relevant. Engineers are set on their current performance and invested in reaching their future career plans.

This framework promotes a culture where performance management is seen as a useful tool for growth rather than a bureaucratic formality.

The post Healthy Performance Management for Engineers? It’s Possible! appeared first on ShiftMag.

James Samuel, a seasoned software engineering team manager from Reddit, provided key insights into building high-performance software teams at the Shift developer conference. After over a decade of experience leading engineering teams across different industries, James shared five strategies to transform underperforming groups into top-tier performers.

Create Clarity

Confused teams need help achieving their goals. As James emphasized, clarity is essential for any high-functioning team. This begins with a clear sense of purpose — understanding the “why” behind the work. A team must know its mission and how its contributions align with the company’s broader goals.

The second pillar of clarity is having a well-defined plan:

Teams need direction from point A to point B, which requires a strategic plan that everyone can rally behind.

The plan should clearly outline the tasks’ priorities, trade-offs, and motivation. Finally, clarity of responsibility is crucial. Every team member should understand their role and how it contributes to the project’s success. Leaders must continuously communicate this clarity — not as a one-off but as a constant guiding force throughout the team’s journey.

Compose a Strong Team

Building a solid team goes beyond just hiring talented individuals. While talent is essential, leaders must also consider the optimal size and stability of the team. James pointed out that an undersized team might need help with workloads, while an oversized team could face communication breakdowns and miscoordination.

Stability is key. Frequent changes within the team—such as rotating members in and out—disrupt cohesion and performance.

It takes time for a team to set up, and James recommended that teams work together for at least 4 to 6 months to achieve optimal collaboration.

Create Synergy

Synergy allows a team to outperform even its best individual members. James compared this to a rowing team, where synchronized efforts lead to better performance.

As a leader, your role is to create an environment where everyone is aligned and moving toward a common goal.

Setting well-defined shared team goals and breaking down communication barriers is essential to build synergy. Transparency in communication fosters trust and allows the team to operate as a cohesive unit. James also highlighted the importance of trust, both compelling (emotional) and cognitive (based on competence), to ensure strong team collaboration.

Empower

Empowering a team means creating an environment where individuals can take ownership and drive their work forward. James shared his experience of initially trying to solve every problem for his team, which led to dependency and hindered others’ growth.

Authentic leadership is about empowering others to take the lead. Inherent motivation plays a crucial role in this empowerment.

James emphasized the need for autonomy, where team members have control over approaching and solving problems. Leaders should coach and develop every team member, ensuring they grow into leadership roles.

Continuous Improvement

Finally, fostering a culture of continuous improvement is critical to sustaining high performance. James stressed that teams should constantly reflect on their processes and outcomes. Regular retrospective meetings offer an opportunity to discuss what worked well, what didn’t, and what can be improved.

Open communication is vital in creating an environment where team members feel psychologically safe to voice their concerns and suggest improvements.

Flexibility is essential, too — processes that work today may not work tomorrow, and teams should always be ready to adapt.

James wrapped up his session with a notable takeaway: high-performing teams don’t just happen; they are deliberately built through clarity, collaboration, empowerment, and continuous improvement. Following these strategies can help build high-performance software teams that consistently deliver exceptional results.

The post 5 strategies to turn underperforming groups of engineers into top-performing teams appeared first on ShiftMag.

A software project being at least a little bit late is almost an unwritten rule. For a highly intricate software project to be delivered on time seems almost impossible, but to be delivered ahead of the deadline? That’s unicorn territory!

Well, according to Nelly Sattari, Senior Engineering Manager at Atlassian, it’s not. At the Infobip Shift conference in Zadar, Nelly shared her first-hand experience and valuable lessons learned from delivering a highly intricate project ahead of schedule.

Setting and maintaining the momentum

It is achievable, provided that leaders sustain the momentum.

She explains that this involves setting clear goals, consistently communicating about risk, progress, and expectations, and celebrating every small success to keep the team motivated. Additionally, offering support, encouraging an open mindset, and being innovative in addressing team challenges are essential for maintaining momentum.

What is a complex engineering project?

What makes certain projects especially challenging and prone to becoming turbulent and out of control?

A complex engineering problem involves multiple interrelated factors, making it challenging to solve due to technical difficulties, risk, uncertainty, interdependencies, and resource constraints.

In her experience, several factors contribute to the complexity of a project that leaders should be aware of:

1. Technical Challenges and Customer Impact: A complex engineering problem that comes up when designing a solution is tough, and legacy issues make it even harder. For example, when technical debt piles up, the code gets messy, and every change risks causing serious issues. This means we have to be super careful and plan everything out.
   
2. Risk and Uncertainty: When your team is building something or using a new technology for the first time, there are many unknowns. Plus, with so many factors to consider—like cost, performance, and simplicity—it can be overwhelming to manage all the trade-offs.
   
3. Interdependencies: Complex projects often involve cross-organizational collaboration, which introduces additional challenges in synchronization and managing dependencies. The more teams involved, the harder it is to align efforts and ensure that everyone is moving in the same direction.
   
4. Time and Expertise Limitations: A tight timeframe makes it more challenging to deliver. 
   
5. Priorities: When your team has to handle multiple parallel workstreams, it becomes much harder for everyone to stay focused.

It is exactly these challenges that make complex engineering problems difficult to manage, requiring careful coordination, clear communication, and strong leadership to navigate successfully.

4 steps leaders must take

Leaders’ role is crucial, and Nelly advises several steps leaders can take to help their teams manage complex projects.   

She emphasizes that it’s not enough for leaders to declare the principles of managing such projects or even formalize the process—these steps must be implemented properly and effectively; otherwise, they may not be very beneficial:

• Clarify Ownership and Commitment: Ensure that teams understand the project’s value and their role in its success. Clear communication about the project’s importance and the expected outcomes helps align the team’s efforts and fosters accountability.
  
• Adopt Agile Practices: Use agile methodologies to manage projects more flexibly. This includes prioritizing tasks, deferring or scoping down aspects when necessary, and focusing on iterative progress. Emphasize effective planning and regular updates to keep track of project milestones.
  
• Ensure Focused Execution: Limit multitasking and context switching by prioritizing projects and making trade-offs where needed. Maintain team focus by shielding them from non-essential tasks and creating dedicated times for project-related activities.
  
• Maintain Team Health and Culture: Preserve team well-being and culture during intense project phases. Implement practices that support a healthy work environment, celebrating success and regular reflections on team dynamics.

Leadership starts before you earn the title

After a few years as an engineer and a tech lead, Nelly became interested in moving to a leadership role herself because she wanted to make a broader impact.

A few years ago, I formally stepped into the role of Engineering Manager, though I firmly believe that true leadership starts way before you earn the title; it’s about influencing decisions, leading by example, and being the change you seek.

In her role of senior engineering manager her days are packed with guiding both individuals and teams of technical leads, ensuring they have the tools and support they need to succeed. She also coaches engineers for their next steps and fosters a collaborative, high-performing team.

As a senior engineering manager Nelly oversees technical decisions, balancing trade-offs to maintain operational maturity and produce high-quality software. She is also responsible for the reliability, resiliency, and security of our products, managing incidents, and driving continuous improvement.

Despite being in back-to-back meetings, I manage to juggle project planning, budgeting, and stakeholder communication.
It’s almost like being a magician!

The post Delivering a complex engineering project ahead of schedule with Nelly Sattari from Atlassian appeared first on ShiftMag.

You see a car parked by the side of the road. Passengers are gesticulating wildly, and you hear the engine failing to start repeatedly. “Damn, their car battery is dead! I better run and help!” you think to yourself, being the good Samaritan your mother taught you to be.

Reflecting back, my career began with a slightly anarchistic approach as a software developer. I did not think much of hierarchy. I was not a fan of “corporate culture”. The idea of someone telling me what to do was alien to me.  

Despite this attitude, I quickly moved from software development to management. One of the first things I told myself and held on to was the simple rule of “I will not tell people what to do.” 

It took me many years of experience to realize this slightly dogmatic approach is not always a way to go. There are valid reasons to push people to do something.  

However, like with most things in management, knowing who to push, when, and into what, is crucial for success. Misjudge the situation and the price you pay for failure can be steep indeed. 

To push or not to push?

Without a second thought, you break into a run. You grab the car trunk and start pushing. The people in the car look back at you in surprise, and the driver opens her mouth in a big O. “Another good deed done!” you think to yourself with satisfaction as you feel the vehicle starting to move on its own. Moments later the car and its occupants disappear as the terrain suddenly drops away. You hear a loud bang.  

So what does it mean to push someone as a manager?

In simple terms, it means directly asking someone to do something that they would not sign up to do by themselves. You are forcing them to get outside of their comfort zone! If you do this correctly, the benefits for the person pushed are numerous: 

• They can acquire a new skill, 
• They can gain confidence and be more willing to engage in similar activities in the future, 
• They can get recognition, 
• They can eliminate internal mental barriers or dogmas, 
• They can gain a new perspective or widen their horizon, 
• Even if they ultimately fail, they can learn from the failure. 

Your best bet for pushing someone is to identify strong points that the person has but is not aware of or is not utilizing fully. That way, you set them up for success from the get-go. But this is easier said than done. 

If you make a wrong decision at the wrong time, disaster can strike.  

People you push can become frustrated, even to the point of quitting their jobs. They can fail at the task you pushed them to do, sometimes with serious consequences for the project or the company. This can also lower their self-confidence and cause them to avoid this type of work in the future.  

Ultimately, they can blame you for the whole thing without learning anything. And they would not be wrong. 

Get to know your colleagues

Luckily for you, this is a time-traveling story. You rewind the clock 10 minutes back and you find yourself facing the car again. This time you do not run. You do not push. You take a few breaths and approach the car slowly. “Hey, you folks are having some problems?” you ask. 

You need to know someone’s circumstances before you can push. Every person is different, so you do what good managers do. Get to know your colleagues! Build a relationship and trust via the time-tested framework of one-on-ones, working together, being present, and following up. This takes time. As you go, make sure you understand what makes the other person tick. Ask yourself (and ask them!): 

• What motivates them at work and in their lives? 
• Where do they feel their current limits are? 
• What are their strong and weak areas? Which ones can be improved? 
• Are there areas where the person might benefit from a new experience or perspective?

A relatively common occurrence during my career was working with folks who tend to avoid communication but do a good job communicating once they did do it. Another would be a colleague with strong technical skills and a natural talent for software architecture, who was for a long time unable to step outside of the shadow of a more senior team member.  

These are great examples of people who might need a bit of encouragement or push to move to the next level of their careers. As a manager, you need to learn how to spot opportunities and take advantage of them. 

As you ask your question, you feel the multiverse split off into several branches. In one, the driver looks at you in surprise. 

“What problems? We’ve just arrived and plan to have a picnic right here. There is a cool cliff up ahead, and we want to enjoy the view!”  

“But didn’t your car just fail to start? Do you need a push?” 

“I hit the ignition with my knee by mistake. I am way too tall for this car.” 

You nod and slowly back away. These people have it under control. 

Sometimes, people are just OK. They are in a good place at their job and grow at their own pace. All you need to do is give them space. And sometimes, people are just not OK. The last thing they need right now is a push. Maybe they have problems in their personal lives, or they are already struggling at a new position or in a new team. Perhaps they have solid reasons why they cannot do what you are asking them to do.  

Learn and respect. 

Build your case and then act 

In the other branch, the driver looks at you with relief. ”Oh, thanks for stopping by! You know, today is pretty cold, and I guess our old battery could not take it anymore. A little help would be nice. We need to be in the town by noon.” And so you roll up your sleeves and get behind the trunk. It’s time to push some folks to success! 

Once you determine you are ready to push, the next step is to build your case. You should not just out of the blue and without context shout orders at people.  

Use your 1-on-1 to explain what is going on and why their involvement might be beneficial. Explain what you see as their strengths and why you believe they have a good chance to succeed. Explain how the process will work and provide a safety net in case of failure. 

• “This is as much about delivering the feature as it is about you learning the ropes. We can manage the client in case things don’t work out.” 
• “You will not be alone in this. Claire has done this before and she will be your mentor throughout the process”. 
• “Before you even start, there is a week-long workshop to give you all the basics you need.” 
• “I will have regular 1on1s with you to help out and act in case you need it.” 

Often, as part of these conversations, the person will decide to sign up themselves and no push is needed at all! Those are the best times. But if that does not happen and you do need to give them a nudge, make sure you are direct and explain why you are picking them. 

• “I believe you are the best person for this job. Not only is it the logical next step in your career, but you have all the right skills. You did a lot of work in native development and have already designed complex UI components that were well-reviewed. You will get a chance to work with seniors outside of your team and learn a lot about designing larger UI systems. The deadline is tight, but I’ve seen you work under pressure, and you always deliver.” 

And there you have it! As with most things when working with people, the key to success is taking your time, understanding the context, communicating regularly and clearly, and being direct when needed.  

Good luck! 

You watch as the car takes off and approaches the town in the distance. The sun is slowly setting behind the horizon, and you get lost in thoughts for a while until a lonely call of an eagle above drags you back to reality. Well, it’s time to get back to work. You rewind the clock a couple of millions of years back and push those early homo erectus folks to play with fire a bit more actively. After all, they have what it takes. 

The post The subtle difference between pushing developers to start their engine and pushing them off a cliff appeared first on ShiftMag.

If there’s one thing we’ve all heard, it’s that “Data is King.” But, as Engineering Managers, how can we truly harness this power to guide our teams? How do we transform data into action to make the right decisions at the right time?

I’m going to share four critical data points that every Engineering Manager should track to drive their team’s performance.

Using these data points to guide your decisions will make you a beacon for your team. They’ll know that the path you’re showing them lies on a firm foundation of factual data. 

So, let’s turn on our analytical minds and dive in.

Attrition Rate

How many people leave under your watch?

The attrition rate—the number of people leaving your team—is critical. High attrition could indicate issues like insufficient promotions, low salary adjustments, or unpopular changes in direction. Addressing these issues right away can increase your team’s stability and satisfaction.

Consider a scenario where your attrition rate spikes following a restructuring within the team. This might indicate that the changes have unsettled your team members, necessitating clear communication and reassurances about their roles.

Lead & Cycle Time

If you’ve never invested in understanding your lead and cycle time, the time is now.

• The Cycle Time is how long your team spends working on an item.
• The Lead Time is broader, measuring how long it takes since a customer requests a feature until that feature is delivered.

Both give you a great understanding of how painful your customer’s interactions are with your team and a lot of information about possible optimization.

For example, if your lead time is disproportionately high compared to your cycle time, it may indicate inefficiencies in how you prioritize work or how the team handles customer requests. 

Addressing these areas could significantly improve your service quality and customer satisfaction.

Happiness Levels

Team morale is a crucial yet often overlooked aspect of team performance. I learned that asking simple and anonymous questions effectively and effortlessly gave me the necessary data.

At the end of each retrospective, add a little anonymous survey:

How did you feel about this sprint?

Happy | OK | Sad / Grrr

The goldmine is not one or two surveys but the data that consistency brings along the several months. I’ve only truly understood what I had after nine months of data.

For instance, consistently low happiness levels could suggest a stressful work environment, leading you to implement measures to address work-life balance or internal communication.

Give it a try, and let me know how it feels.

CFR & MTTR

It’s not about how hard you hit. It’s about how hard you can get hit and keep moving forward. How much you can take and keep moving forward. 

Rocky

Incidents are inevitable in every team, but understanding their frequency (CFR) and your team’s recovery time (MTTR) can inform process improvements and enhance resilience.

For example, a high CFR might point to issues in your testing or deployment processes, while a long MTTR could suggest a need for better incident response strategies.

Start tracking these data points, and let me know about the transformations you observe in your team dynamics and results.

TL;DR

• Attrition Rate: How many people leave under your watch.
• Lead & Cycle Time: How long it takes for you to deliver features.
• Happiness Levels: How happy your team truly is.
• CFR & MTTR: Incidents happen. It’s all about how you react.

The post The 4 metrics every engineering manager should track appeared first on ShiftMag.