<story><title>How to fail as a new engineering manager</title><url>https://blog.usejournal.com/how-to-fail-as-a-new-engineering-manager-30b5fb617a</url></story><parent_chain><item><author>sytelus</author><text>I as a manager “kept coding” and it made me a better manager 100% of the time. It allowed me to understand low level issues team had been facing that I couldn’t have from 35,000ft. Team members didn’t felt need to dumb down complex concepts so I “get it”. People didn’t had to prep PowerPoints all the time because I could only grasp pretty pictures. I much better understood the complexity of workitems, costs, collaboration opportunities, scheduling and skills required which allowed me to do much better estimates and task assignments. I didn’t had to find “deputy” who I delegate everything while I am just busy in meetings and emails. Ancient Greeks like called this type of management as “leading from the front”. Chinese called it working shoulder to shoulder with your team mates instead of trying not to get your hands dirty because, you know, you are too “busy” and a level up high. Being able code (not in just imagination, but &lt;i&gt;really&lt;/i&gt; code) puts “Engineering” in the “Engineering Manager”.</text></item></parent_chain><comment><author>lmm</author><text>I&amp;#x27;d be interested to see whether your subordinates agree with that assessment. One of the better programmers I&amp;#x27;ve worked with was promoted to our manager and tried to &amp;quot;keep coding&amp;quot; and it made her one of the worse managers I&amp;#x27;ve had: the team was constantly blocked because her tasks got delayed when she (as is the nature of management) was pulled away for meetings with higher-ups or other unexpected work. In turn that meant there was pressure not to interrupt her when she was at her desk so it was hard to bring problems to her, even though that&amp;#x27;s a manager&amp;#x27;s primary responsibility.</text></comment>
<story><title>How to fail as a new engineering manager</title><url>https://blog.usejournal.com/how-to-fail-as-a-new-engineering-manager-30b5fb617a</url></story><parent_chain><item><author>sytelus</author><text>I as a manager “kept coding” and it made me a better manager 100% of the time. It allowed me to understand low level issues team had been facing that I couldn’t have from 35,000ft. Team members didn’t felt need to dumb down complex concepts so I “get it”. People didn’t had to prep PowerPoints all the time because I could only grasp pretty pictures. I much better understood the complexity of workitems, costs, collaboration opportunities, scheduling and skills required which allowed me to do much better estimates and task assignments. I didn’t had to find “deputy” who I delegate everything while I am just busy in meetings and emails. Ancient Greeks like called this type of management as “leading from the front”. Chinese called it working shoulder to shoulder with your team mates instead of trying not to get your hands dirty because, you know, you are too “busy” and a level up high. Being able code (not in just imagination, but &lt;i&gt;really&lt;/i&gt; code) puts “Engineering” in the “Engineering Manager”.</text></item></parent_chain><comment><author>jon-wood</author><text>My experience of moving into engineering management has very much been that I need to keep writing code to truly understand what people are facing, and ensure I&amp;#x27;m not coming up with crazy ideas that will be a pain to implement.&lt;p&gt;The only caveat I&amp;#x27;d add to that is that I can&amp;#x27;t keep on working on things in the critical path, at least as the sole developer picking up those tasks, because I&amp;#x27;m hugely more likely to have things come up that prevent me from doing those things in a timely manner. That then leads to other people being blocked on my work.&lt;p&gt;The best balance I&amp;#x27;ve found is for me to either pair with a developer who&amp;#x27;s able to remain focused on a task when I&amp;#x27;m inevitably dragged away to do something else, or for me to pick up non-urgent tasks like refactoring, or developer tooling. The latter is probably my favourite as it means I&amp;#x27;m applying my experience to tools and libraries that can then be used in widely applicable circumstances to make the rest of the team more productive.</text></comment>