Leonid Toshchev’s Post

I resisted becoming a manager for a really long time. I thought adding hierarchy was always bad, I scoffed at "people work", and I overvalued lines of code. Below are some reflections on those. RE: Engineering Managers adding unnecessary hierarchy. I think this is often true but not always. Engineers like to build things, and they often don't understand how a manager provides value. What an engineer might be missing is how miserable their lives would be if they had to deal with the information overload for how many paths a business might be considering at any given time. Hierarchy is a useful abstraction to reduce the amount of information engineers have to deal with, allowing them to focus and perform better. RE: "People work". The misconception here is that "technical" and "people" work can be separated. Software engineering in a company is a team sport, and successful engineers have to do "people work" whether they like it or not. You want engineers to do work besides code. Before becoming an engineering manager, I was already doing the following: - Interviewing candidates - Project management - Running team meetings - Code reviews - Architecture discussions - DevOps work So why make a role distinction? Because it massively reduces context switching for engineers. The larger the company gets, the more those non-coding tasks take. It is an optimization for everyone involved. RE: Lines of Code. Writing lots of code doesn't necessarily make you productive or valuable. It's all waste if you're not working on the right things. I've been put to work on projects that were poorly thought out and led to unnecessary stress. In those cases, even though I was writing lots of code, I was actually providing negative value. An engineering manager isn't the only person responsible for making sure teams are productive, but they are important. What actually makes teams productive is making sure they're working on the right things, with the right resources, with the right amount of technical challenge, and that unpleasant labor like on-call duty and support tickets are equitably distributed. If you don't have those problems, then adding a manager is a bad idea. But I bet most people do have those problems and that's the value the manager adds. #engineeringmanagement #softwareengineering

Not Sure If Engineering Management Is Right for You? These 7 Questions Will Give You Clarity! I still remember when I first thought about transitioning into Engineering Management - it wasn’t an easy choice, but it was definitely exciting! If you’re a Software Engineer or Lead and thinking about making the leap to Management, here are 7 critical questions you need to ask yourself before taking that step. Take a few moments to think through these questions, and see what resonates with you the most! 1 | How do you handle stress and multiple priorities? ↳ Managers often juggle multiple responsibilities - meeting deadlines, managing stakeholders, and supporting team members. 2 | Can you handle difficult conversations with empathy and clarity? ↳Engineering managers often have to address performance issues, provide feedback, and navigate conflicts. 3 | How well do you adapt to the success of others being your primary success? ↳As a manager, your achievement is measured by how well your team performs, not just your individual contributions. 4 | How comfortable are you with making tough decisions that might not always be popular? ↳Managers must make difficult choices, sometimes affecting team morale, project direction, or individual roles. 5 | Do you enjoy empowering others to find solutions rather than solving problems yourself? ↳As a manager, your role will often involve guiding others to find their own solutions instead of jumping in to fix things yourself. 6 | Can you balance short-term deadlines with long-term vision and team development? ↳Management requires juggling immediate deliverables while also focusing on team growth and strategic goals. 7 | How well do you handle ambiguity and making decisions with incomplete information? ↳Management often involves making calls when not all the data is available. Being comfortable with uncertainty is key. 💬 Which question made you stop and think the most? Drop your thoughts in the comments below! 👇 If any of these questions resonated with you or gave you pause, let's have a conversation. I’ve been where you are, and I can help you gain clarity on whether this transition is right for you. Feel free to message me. I’d love to help you navigate the next step in your career! 🚀 #EngineeringManagement #TransitionToEngineeringManager #SoftwareEngineerToManager

Is it just me, or is the human side of Engineering Management being overlooked lately? Job descriptions this year seem to focus heavily on technical skills, with little mention of people management. The hiring processes, resembling those for developers, additional proof of this trend. In his book "CTO the Toolbox," Sergio Gago defines the clear distinction between a tech lead and an engineering manager. He notes that some companies merge these roles either by design or necessity and that can be okay. However, it seems companies are now combining multiple roles into one and calling it Engineering Manager. This often means being a technical lead, handling architecture, doing a bit of people management, some scrum master duties, and also project management. I chose the managerial path early in my career and have loved being a team builder and helping others see different perspectives. However, I now feel stuck as I don't fit the current market demand. I don’t want to give up my passion for both people and technology. I hope the tide changes soon and companies open more people-focused roles. I'll be ready when that happens! By the way, I highly recommend Sergio’s book. It offers great reads, practical tips, and frameworks, with 100% of proceeds going to various NGOs. #EngineeringManagement #TechLeadership #PeopleFirst #CareerGrowth #CTOTheToolbox

Why Should You Hire Me? Allow me to present my case, backed by a blend of experience, skills, and passion: 1.     Expertise: I bring a wealth of knowledge in IT Project and Program Management. My track record includes successfully steering complex projects from inception to delivery. 2.     Strategic Vision: I don’t just manage tasks; I craft roadmaps. My ability to align technology initiatives with organizational goals ensures impactful outcomes. 3.     Agile Champion: Agile methodologies are my compass. I thrive in dynamic environments, adapting swiftly to change while maintaining focus on results. 4.     Risk Mitigator: I’m not afraid of dragons (read: risks). I assess, strategize, and slay them, ensuring smooth project journeys. 5.     Team Whisperer: My leadership style is collaborative, empowering teams to unleash their full potential. Together, we build castles of success. 6.     Tech Enthusiast: From AI to Linux, I’m fluent in tech dialects. My passion fuels innovation, whether it’s optimizing code or securing networks. 7.     Quality Crusader: QA isn’t an afterthought; it’s my creed. I ensure deliverables meet the highest standards. 8.     Global Navigator: Across continents, I’ve led multicultural teams. My compass points toward effective communication and shared victories. 9.     Business Acumen: I speak both tech and business. ROI, KPIs, and P&L—my lexicon extends beyond code. 10. Adaptability: The tech landscape evolves faster than a quantum particle. I thrive on learning, staying ahead of the curve. In summary, hire me because I’m not just a manager; I’m a project driver, catalyst for growth, a guardian of excellence, and a seeker of innovation. Let’s build something remarkable together! 😀

"It will be done when it's done" If you ask your software team often enough about project timelines, you might eventually get this answer. But let's be honest - all the cross-functional teams depending on the outcome of your software project won't be thrilled with such an open-ended response. One of the biggest challenges any software team faces is accurately answering this question. There are tons of ways to approach it, and experienced leaders will tell you that if you want a definite answer, you must either adjust your scope or have additional resources at your disposal. With that said, a great team also simply executes better. How? By ensuring precious resources are spent on the right things, catching issues early on, and maintaining excellent communication within the team. This is challenging, as it often requires engineering leaders (both managers and tech leads) to spend significant time overseeing their teams. That's why I am creating a project assistant that acts as a silent partner for your team, gently guiding them towards efficient execution and clear communication.By reducing the cognitive load on your engineering leaders and empowering every team member, MeetAndy helps turn the dreaded "when will it be done" question from a source of stress into something that teams can answer confidently. https://meetandy.ai

Once upon a time a Lead PM asked me if she should hire a project manager or a delivery manager to help her with a specific project because she has too many meetings already and was too busy.. Sounds legit until you ask, what happens then? => the new “manager”, let’s call them extra-man (short for extra manager), gets to go to #Project related meetings and my friend still has to go to all the #Product related meetings => extra-man adds a weekly meeting with my friend the Lead => extra-man sets up meetings with everybody else to get to know them and catch up with them My friend possibly saves less than an hour a week and everybody pays for the communication overhead.. It’s gets worse when you think that this project is supposed to last just another year.. after which you have to find extra-man another role or they might just invent some work for themselves.. Let’s be honest, a lot of firing in tech is avoidable, if managers think through their real needs and the actual benefits of adding “enabler” roles.. Luckily a bit of meeting hygene turned out to be a better course of action in this case but the automatic pull to delegate was very real! Seen teams growing too fast and inevitably firing? What would you advice? #hiring #productmanagement #enabler #jobs #avoidable #crisis

Great project managers are much harder to come by than great engineers. If you have a large team, they’re the most crucial element to the team’s success. A PM can either make your life as a dev hell or a blessing. Becoming a great engineer is straightforward: get really good at programming + work on your soft skills = you’re good to go. For a PM - not so simple. The reason why there are way less good PMs, I think, is because there is a big misconception what a great project manager should be. I have a feeling that when upper management interviews PMs they pay more attention to how much the PM can promise to deliver, rather than what tools / methodologies / approaches or technologies they will be using. Usually, this leads to having a PM that puts all of the pressure on developers and starts micromanaging. They can’t “defend” devs cause they already made their promises, so they never push back to the upper management. Project managers should have a really good understanding what methodology or approach is applicable in each of the scenarios. They should have outstanding communication skills. And most importantly - they should be able to keep their cool. If you’re hiring a PM - please make sure you test these somehow. There is nothing worse than a PM that’s constantly trying to bug you or call you asking “Is it done yet?! Have you tried X?! But you promised! No bugs this time, please!”. If you’re a dev and have a good PM on your project - write a “thank you” to them today ;) Usually they do a lot of things “behind the scenes” to make your life easier. Or, they’re not micromanaging and trust you - which is also a good thing. I’m curious to hear your thoughts on good PMs in the comments. #projectmanagement #pm #softwaredevelopment

About 15 years ago, I thought my team could deliver a complex software solution quickly because I believed everyone could work as I did. This overconfidence led to hurried development, causing many bugs, and we had to work very hard to deliver everything on time and with good quality. This happened because I, as a manager, was trapped by my оverconfidence bias. This bias means that someone thinks too highly of their abilities or how accurate their knowledge or predictions are. I was sure about the success of my plans, not considering possible problems and uncertainties enough. These and other cognitive biases can become a big problem for a manager because they affect our decision-making processes. In future posts I will look at several types of cognitive bias. By the way, I learned to be realistic about the team's capabilities and not to measure everything by myself. #projectmanagement

Recently I had a very interesting discussion with an ex-colleague. This person knows me from the time when I started my career as a developer and knows my skills. He asked me that since I am now in market looking for a role and there seems to be a huge demand for the niche developers and engineers, if I had a chance, would I do anything different? I said, no I wouldn't. I didn't choose the path of project and program management because I did not enjoy technical landscape. I chose it because I loved it so much that I wanted to bridge the classical gap between technical teams and business teams. Since I have trained myself to be in the sweet spot, I would choose to do it again. May be I would like to explore more industries but I will still choose to be a project manager. I feel I contribute and solve problems best in that capacity as I then see the bigger picture with a micro lens. To all the project managers reading this, what do you think? Why do you love your role in the industry? #projectmanagment

Engineering Management - Beyond Technical Projects & People Management Engineering managers are doing different things in different organizations. What should they do? Do we have one answer? How did the role evolve in past years? As Eng Manager, the role extends beyond overseeing technical projects. The role should be a bridge between innovative ideas and their successful implementation. A few points I have learned to ace the EM roles: 1. Clarity and Vision: Your job is to make things clear within your team. You should be good at making your team understand not just the "WHAT" but the "WHY" behind their work. 2. Empower, Empower & Empower your Team: Trust in your team's abilities and give them the autonomy to innovate. Encourage open dialogue and create an environment where every idea is valued. 3. Strategic Prioritization: Balancing short-term goals with long-term vision is crucial. Prioritize tasks that align with your strategic objectives, but stay flexible to adapt as needed. 4. Technical Proficiency: While you don’t need to code daily, understanding your team's challenges enhances decision-making and credibility. 5. Data-Driven Decisions: Use Metrics and analytics to provide insights into performance and highlight areas for improvement. 6. Effective Communication: Transparent and consistent communication fosters trust and keeps everyone aligned. 7. Continuous Learning: Encourage a culture of continuous learning and professional growth within your team. Like most fields, successful management requires leadership, technical knowledge, and strategic thinking. What strategies do you find effective in engineering management? Share your thoughts and experiences in the comments! #EngineeringManagement #Leadership #Innovation #TechLeadership #ProjectManagement __________________________ Thanks for reading the post. If you like the post: - Follow Sanjeev Thapa for more. - Like & Share the post. Hi, I am Sanjeev Thapa, a proud husband & dad living in Germany. I drop content on #TechLeaderShip, #SoftwareEngineering, #StartUps & more. __________________________