Asim Suvedi’s Post

“The Engineering Manager will need to have experience with our tech stack” Is what I hear a lot from clients when I am asked to help find a “hands on” functional Engineering Manager. I think every Engineering leader from Management up to C-Suite should still be able to code. Even though the higher up one progresses, one’s role inevitably becomes more strategic and hands off, there should just generally still be enjoyment from building stuff. At Individual Contribtuor level, I can absolutely see the rationale in complete alignment with the tech stack of a company. However, I’m not convinced there has to be an exact alignment with technology stacks at the management/leadership level. Keen to understand the general consensus from my engineering network, what do you think? comment below and let me know your thoughts 🤔👇🏻

How to stand out as an Engineering Manager or Director: - Experience integrating best-in-class engineering teams and processes. - Demonstrate how you translate business/product requirements into actionable engineering tasks. - Ability to manage upwards, sideways, and downwards. - Building high-level teams and attracting world-class talent. - Demonstrating high levels of emotional intelligence. - Focusing on the why, not just the how and what. - Being able to capture the value of engineering across different stacks, etc. - Keeping senior sponsors engaged by highlighting the strategic engineering vision. - Demonstrating a strong legacy from previous roles. Clearly articulate your overall impact to the company and product, providing comprehensive detail wherever possible.

As an engineering executive, it's easy to get caught up in the day-to-day operations of the company. But ask yourself this: Are you focusing on the right things? If you're not actively working to improve the company's engineering best practices, then you're not doing your job. Here are some ways you can improve your focus: - Prioritize time for team growth - Set clear objectives and goals - Encourage and listen to feedback - Invest in technology and innovation - Hire top-tier talent and be a mentor Don't get bogged down in the small details. Focus on what truly matters and watch your company's engineering team thrive.

Engineering leaders that want their teams to move faster or produce better results should do one specific activity - invest 2-3 weeks with your team time tracking each day and then do a retrospective: 1 - How much time was spent in meetings vs value-added engineering work? (Equally important to define what constitutes the latter!)  2 - How many hours of meetings should have been skipped? Make a guess before you collate the results 🙂 I bet you’ll be surprised. Before you go hiring more people or cost cutting - kill more meetings! Folks that aren’t familiar with Dovetail Product Development may doubt that the value is worth the cost. Yes - we do have best practices, experienced engineers, and specific tools and know how to amplify the effectivity of our work. But even more fundamentally, our team is spending just under 90% of their time focused on engineering, building or testing hardware and doing so in large blocks of time. How do we know? We’ve tracked all our time spent the last 8 months. And we know we win in this category. Plus - why are great engineers talking to us about joining? Because we are hiring great engineers to do engineering 🤯

What differentiates a senior engineers from leads? 🌍 Scope: Senior engineers focus on technical problems within projects. Leads oversee project management and strategic planning across projects. 💻 Experience: Senior engineers have deep technical skills. Leads use their experience for guiding technical strategy and team health. 🤔 Decision Making: Senior engineers decide on technical solutions. Leads make broader team and project decisions. 🗣 Communication: Senior engineers communicate complex technical ideas within their team. Leads communicate across teams and with stakeholders, balancing technical and non-technical language. 💰 Salary: Senior engineers earn high salaries for their expertise. Leads’ salaries reflect their leadership and broader impact. Do you agree?

There isn't just one career path in software engineering. Most engineers or aspiring engineers think the default path is that you'll work your way up to management and hopefully to a CTO. Tons of engineers prefer to have some sort of engineering as a part of their responsibilities throughout their career - after all, it is fun to build things! On top of that, not everyone out there is cut out for management - great companies want the right people in their management ranks and a mutual desire to be in a management role. As you go through your first few years as an engineer, your path will become more clear to you. Regardless of if you go the management route or not, you'll still have to learn the ins and outs of mentorship, people skills, technical communication, and dealing with external teams. At what level you want to do this is up to the path you choose. Engineering managers, leaders, and directors will deal more with the people aspect of the job and will spend most of their time leading and setting direction of the team. Senior, Staff, Distinguished (etc - whatever you may call it) Engineers will spend less of their time than managers on leading and more of their time on engineering, setting the technical direction of the team, leading individual projects and initiatives, architecture, and mentoring other engineers on their team in technical skills. Choose the path that works best for you and what you want - not the path that you think you're required to do.

Elevating this from a comment I made. Here's how I think about building and maintaining strong relationships with my engineers: Meet every week, take thoughtful notes, follow through with things I say I'll do, apologize when I make mistakes and try to do better, share the human side of things, don't make it just work, and keep learning how to be a better manager. There is some nuance there, but if you take 1 thing away: Make your people your focus. If I could pick only 1 thing I do as an engineering manager, it's the 1:1s I have with my team. Best way I can understand and help my team grow, make an impact, be happy, etc.

A great engineering manager is not: - Cancelling 1-1s all the time. - Busy and nowhere to be found. - A bottleneck for team decisions. - Disconnected from the team's work. A great engineering manager is: - Need to talk? I'm available for you. - Need autonomy? I trust you with your decision. - Need guidance? Let me share my experience. - Need support? Tell me what to do. - Need security? Don't worry, I'll lead the way. I've seen hundreds of engineering managers. Most are always busy, skipping lunch, looking exhausted. And I've seen great engineering managers - always there for their people and their team. And they look energized. Great engineering managers are not busy. Why? Because they build their teams to be strong.

Has anyone here ever worked as a/ or with a fractional CTO, or a kind of fractional Engineering Manager, fractional Engineering Director? I've been talking to a few smaller companies, that aren't able to bring someone like that fully onboard. The idea arose, what if you could bring in someone on a limited amount of time that can help prepare your company for growth, manage engineers, set up process, lay the foundation for career growth, help with product <> engineering processes, etc. Just thinking out loud. There are probably downsides to this, I am sure of it. But I could also see how in small companies this could actually be feasible. Any thoughts, comments? Mainly doing some research here 🤗

There are only two options, as an engineering manager: - you're the constraint - you're finding the constraint What do I mean? Any kind of leader, but especially in technical roles, is tempted to do the work. But if you're routinely doing the work, then there's no one else doing the things that only a manager can and should do. And one of the primary things you should be doing is ensuring that all of your direct reports aren't blocked. If you have a lot of them waiting on you, because you're working on a feature, you are blocking them. You are the constraint.