Robert Sahlin’s Post

I recently met with a young software engineering manager we’ll call Eric. Eric is a first-time manager who is stuck in a vicious cycle of firefighting and micromanagement because he feels unable to let go of the reins and let his team focus on the details of execution. He is getting feedback from his cross functional peers that he’s missing out on the bigger picture by getting too bogged down in the weeds. This is an all-too-common pitfall that many new EMs fall into: the irresistible urge to stay hands-on with coding. Here’s the thing: while coding is a critical part of our profession, the role of an engineering manager extends far beyond just writing code. The real challenge (and opportunity) lies in driving business value and ensuring that your team is delivering solutions that genuinely satisfy customer needs. Your primary role as an engineering leader is to align your team’s efforts with the company's strategic goals. This means understanding what the business needs and ensuring that the engineering work directly contributes to those goals. It’s not just about getting features out the door but about how those features impact the bottom line. Through my own journey as a leader and people manager, I’ve found a few keys things to be extremely helpful in developing the mindset needed to be a truly impactful manager: Delegation: Empower your team to take ownership of the technical details and stay out of their way. Your role is to be a guide and to offer advice and suggestions, but you should avoid doing the work for them. Facilitate Communication: Foster open lines of communication between your team and other departments. It can be easy for teams to stay in their technical bubbles, so it can fall to us as leaders to pull them into conversations that highlight the value prop of the software they’re building for both the business and customers. Focus on outcomes: Shift your attention to the outcomes of your team’s work. Are you meeting customer needs? Are your solutions aligned with business goals? Regularly review success metrics and feedback to ensure you're on track. While writing code might always hold a special place in your heart, the true value of an engineering manager lies in driving business outcomes and customer satisfaction. Remember, it’s not about choosing between coding and managing—it’s about balancing the two to create the greatest impact. So, step back from the keyboard occasionally, and keep your eyes on the prize: delivering real value for the business and delighting your customers.

As an engineering manager, you have one main goal: Your team needs to deliver. Not you. That means less focus on implementation, more focus on delivering. And this is reflected in the EM technical hiring criteria. So you don’t always need to be an expert, But you do need to be competent in: 𝟭. 𝗦𝘆𝘀𝘁𝗲𝗺 𝗱𝗲𝘀𝗶𝗴𝗻 & 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 Do you understand the impact & trade-offs of technical decisions? (Decreased costs by 30% by moving to on-prem from cloud) 𝟮. 𝗞𝗣𝗜𝘀, 𝗢𝗞𝗥𝘀, 𝗺𝗼𝗻𝗶𝘁𝗼𝗿𝗶𝗻𝗴 How do you measure your team’s/product’s success? (Improved team velocity by 25% by switching to Kanban from Scrum) 𝟯. 𝗣𝗿𝗼𝗰𝗲𝘀𝘀𝗲𝘀, 𝘀𝘆𝘀𝘁𝗲𝗺𝘀, 𝗖𝗜 How do you reinforce the continuous integrity of the product? (Release cycle went from days to hours by introducing CI strategy) 𝟰. 𝗦𝗶𝗺𝗽𝗹𝗲 𝗰𝗼𝗱𝗶𝗻𝗴 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀 Can you get your hands dirty if necessary? (How do you reverse a string?) You don’t need to be the smartest person on the team to lead the team. And this is reflected in the EM hiring process. Because your job as a manager is to empower the team to produce… The right features, with the right quality, with faster velocity, in a more efficient manner. And look, being smart helps. But it won’t be enough. You need a different skillset - a level above implementation. You need the skillset of a technical leader. === There's no playbook on how to become an engineering manager, and there's simply no substitute for experience. But being prepared can certainly help you hit the ground running. DM me “Mission” and I'll get you bootstrapped for the EM hiring process with the "Engineer to Manager" strategy.

Ever wondered what makes a high-performing software engineering team? It starts with clear, role-specific objectives. Software Engineers (Day-to-Day) • Complete tasks on time. • Maintain code quality. • Debug and fix issues quickly. • Ensure robust testing. • Collaborate with team members. • Keep learning new tech. Lead Engineers (Medium to Long-term) • Oversee project timelines. • Provide technical guidance. • Ensure scalable architecture. • Enforce coding standards. • Align with business goals. • Optimize performance. Managers (Long-term) • Develop and train the team. • Align efforts with company goals. • Manage resources effectively. • Improve development processes. • Communicate with stakeholders. • Manage budgets. • Mitigate risks. • Track performance metrics. Clear objectives ensure everyone knows their role and contributes effectively. #SoftwareEngineering #TeamGoals #Leadership #EngineeringManagement #DevTeam #TechLeadership #ProjectManagement #CodeQuality

As an engineering manager, you have one main goal: Your team needs to deliver. Not you. That means less focus on implementation, more focus on delivering. And this is reflected in the EM technical hiring criteria. So you don’t always need to be an expert, But you do need to be competent in: 𝟭. 𝗦𝘆𝘀𝘁𝗲𝗺 𝗱𝗲𝘀𝗶𝗴𝗻 & 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 Do you understand the impact & trade-offs of technical decisions? (Decreased costs by 30% by moving to on-prem from cloud) 𝟮. 𝗞𝗣𝗜𝘀, 𝗢𝗞𝗥𝘀, 𝗺𝗼𝗻𝗶𝘁𝗼𝗿𝗶𝗻𝗴 How do you measure your team’s/product’s success? (Improved team velocity by 25% by switching to Kanban from Scrum) 𝟯. 𝗣𝗿𝗼𝗰𝗲𝘀𝘀𝗲𝘀, 𝘀𝘆𝘀𝘁𝗲𝗺𝘀, 𝗖𝗜 How do you reinforce the continuous integrity of the product? (Release cycle went from days to hours by introducing CI strategy) 𝟰. 𝗦𝗶𝗺𝗽𝗹𝗲 𝗰𝗼𝗱𝗶𝗻𝗴 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀 Can you get your hands dirty if necessary? (How do you reverse a string?) You don’t need to be the smartest person on the team to lead the team. And this is reflected in the EM hiring process. Because your job as a manager is to empower the team to produce… The right features, with the right quality, with faster velocity, in a more efficient manner. And look, being smart helps. But it won’t be enough. You need a different skillset - a level above implementation. You need the skillset of a technical leader. === This is what I dive deep into with 8 software engineers on June 19th. It‘s an intensive course where I personally help you break into the leadership role of your dreams (even if you don‘t have any leadership experience). DM me “Mission” for more details.

How to Be a Better Software Engineering Leader

Why Being Realistic in Software Engineering Project Planning Matters In software engineering, optimism is the enemy of timelines. You may think you’ll hit every milestone. But the reality? Projects get delayed, bugs pop up, and features need reworking. The solution? Be realistic. Here’s how you can do that: 1. Buffer your timelines – Add 20% more time than you think you’ll need. 2. Account for the unknown – Unexpected bugs or issues will arise. Plan for them. 3. Prioritize deliverables – Not all features need to be shipped at once. Focus on the essentials. At the end of the day, realistic planning prevents overpromising and sets your team up for success.

My 7 biggest struggles as a first-time Engineering Manager were: 7. Letting go of coding but trusting the team to do it. 6. Thinking I needed to have all the answers 5. Wanting to be Liked by the Team 4. Earning the trust of the team 3. Delivering critical feedback 2. Effective delegation 1. Time management If you’ve just transitioned into a management role and you’re struggling, Here's my tried and tested advice. 1. It’s a new role, so be kind and compassionate to yourself  ⮑ admit if you don’t know something  ⮑ show the curiosity to learn  ⮑ get support from your:        - manager & peer groups        - your team leads and your engineers 2. Invest in your learning:  ⮑ read good management and leadership books  ⮑ observe other leaders and learn  ⮑ attend management trainings  ⮑ reflect on your experiences 3. Develop & Support your team ⮑ be genuinely interested in knowing your team  ⮑ give clear and timely feedback but with empathy  ⮑ don’t be afraid to delegate. Learn to trust your team  ⮑ give career growth support and set clear expectations  ⮑ In 1-1s, focus on their agenda and practice active listening 4. Build a good work culture  ⮑ assign level-appropriate projects   ⮑ don’t make drastic changes in culture and processes  ⮑ don't give them an answer every time. Guide them to it  ⮑ plan some team lunches and fun activities for bonding 5. landing projects rather than just launching them. Always pay attention to  ⮑ good design, code quality  ⮑ testing, monitoring, and maintenance Don't bend the other way to be liked at the cost of your responsibilities. What are you struggling with as a tech lead or engineering manager? – P.S: I’m doing a free webinar on how to transition to Engineering Management. If you’re a Sr. Engineer, Tech lead or a new Manager, join in. Here’s the form to register ↓ https://lnkd.in/gZ7VcqMD

This question comes up all the time. But, let’s think about this question (and my response) a little deeper. - Why shouldn’t the tech lead manage the team? - Why shouldn’t the engineering manager perform code reviews? Like everything in technology, the answer depends on the situation. Here I attempt to answer the perennial question of “Why should the TL not lead the team and why should an EM with a team of sufficient size not review code?” We consider three aspects when answering this question: role definition, team communication complexity, and team size. Engineering manager and technical lead are two different roles with different skill sets. Someone might be good at one role but not the other (and vice versa). For example, the best programmer on the team is not always the best person to organize all the stuff. However, the team needs both roles to operate optimally. https://lnkd.in/gKhSjeQ9

The most productive, innovative, and fulfilled engineering teams I've worked with have a common trait: Everyone wears multiple hats… In small teams, typically 5-8 people, everyone dives into all aspects of the end-to-end process, from requirements analysis and design to planning and forecasting, to governance, development, testing, etc. and even production releases. A dynamic and collaborative environment where each team member contributes across the board, not just within their traditional role. So why do I constantly push for this and why does it matter? It fosters a sense of ownership, engagement, accountability and shared success. When people step out of their comfort zones and get involved in different stages of the work, they gain a broader understanding of the products, methodologies and the business. This kind of cross-functional collaboration breeds creativity, growth mindsets, agility and, from what I’ve observed, innovative teams and ultimately better results. What surprises me though! I observe too often how engineers, and even professionals in other fields, choose to limit themselves by saying, “I only want to focus on X” or “I don’t touch Y.” While it's important to respect individual strengths and interests, boxing yourself into a narrow specialisation can stifle growth, limit your potential, and reduce your impact. I believe that in today’s fast-paced world, adaptability is a superpower. The most innovative solutions come when people are willing to stretch beyond typical roles, learn new skills, and contribute to areas outside of their expertise. My takeaway and advice: Don't just ask, "What's my job?" - ask, "How can I help move the team forward?" Embrace a mindset of curiosity and flexibility. I accept it may be controversial to many, but I genuinely believe this is the future we’re heading towards. In the field of Software/Data/Platform Engineering, you’ll either be an Engineer or a Product Owner of some sort, with no other (or very minimal) roles in-between like Tester, Analyst, Architect, Scrum Master, etc. The future belongs to the cross-functional, growth-oriented teams. Let's keep pushing boundaries together…