<story><title>Coding as an Engineering Manager</title><url>https://nemethgergely.com/coding-as-an-engineering-manager/</url></story><parent_chain><item><author>nodefortytwo</author><text>For me I have always found the best projects to work on are Developer Experience projects.&lt;p&gt;In most companies its hard to dedicate the time to DevEx but as a manager I can rock out a few features for our cli in a couple hours. If i&amp;#x27;m delayed it doesn&amp;#x27;t really hurt the status quo but when I succeed my developers love it because I make their lives easier (the (almost) entire point of being a manager). It scratches the coding itch too although I have lost many evening and weekends getting carried away.</text></item><item><author>JimDabell</author><text>I think a lot of organisations (and people) fall into the trap of thinking of an engineering manager as a more senior tech lead, when in fact they are very different jobs with very different modes of working.&lt;p&gt;As soon as you start taking on managerial work, your development productivity starts to fall rapidly.  I&amp;#x27;ve never found a happy medium, nor have I seen others achieve it.  People who try to do both quickly settle on ~80% of one and ~20% of the other.  Which is fine if you acknowledge that you can only do ~20% of the other, and that the shape of it is likely to look very different to when you were spending 100% of your time on it.&lt;p&gt;As others have mentioned, if you are an engineering manager and you still want to dedicate some of your working time to development, you have to take yourself out of the critical path.  Nobody wants to hold up a release because you were working on an important part of it and you&amp;#x27;ve been constantly interrupted all week with managerial work and meetings.&lt;p&gt;Instead, pick things that are either tiny or decoupled from the release process.  Things like refactoring, non-critical bug fixes, documentation, tests, spikes.  These are the kinds of things that won&amp;#x27;t fall apart if your development productivity is unpredictable and the kinds of things that are easy to put down and pick up again.  As an engineering manager, you&amp;#x27;re interrupt-driven which is incredibly disruptive for focus.  If you do write code, then it has to be the code that works within those constraints, or you&amp;#x27;ll end up being a blocker for the rest of the team and your managerial work will suffer as well.</text></item></parent_chain><comment><author>ojn</author><text>As others, I 100% agree with this and it&amp;#x27;s what I&amp;#x27;ve also been focusing on as a manager.&lt;p&gt;Someone told me: Once you have 10 people on your team, if you spend 100% time coding, you increase amount of coding by 10%.&lt;p&gt;Instead, either spend time finding that next hire (increase by 10%), or work on other things that improves the team&amp;#x27;s productivity even more.&lt;p&gt;For me, the hard part is when the team size is ~5-8 people. Too big for me to be 80% technical, but usually not quite such that managing is 80% either. This is when it&amp;#x27;s easy to sign up for critical tasks and get interrupted due to manager stuff, and as a result work 160% total. Once the team grows it usually gets easier.</text></comment>
<story><title>Coding as an Engineering Manager</title><url>https://nemethgergely.com/coding-as-an-engineering-manager/</url></story><parent_chain><item><author>nodefortytwo</author><text>For me I have always found the best projects to work on are Developer Experience projects.&lt;p&gt;In most companies its hard to dedicate the time to DevEx but as a manager I can rock out a few features for our cli in a couple hours. If i&amp;#x27;m delayed it doesn&amp;#x27;t really hurt the status quo but when I succeed my developers love it because I make their lives easier (the (almost) entire point of being a manager). It scratches the coding itch too although I have lost many evening and weekends getting carried away.</text></item><item><author>JimDabell</author><text>I think a lot of organisations (and people) fall into the trap of thinking of an engineering manager as a more senior tech lead, when in fact they are very different jobs with very different modes of working.&lt;p&gt;As soon as you start taking on managerial work, your development productivity starts to fall rapidly.  I&amp;#x27;ve never found a happy medium, nor have I seen others achieve it.  People who try to do both quickly settle on ~80% of one and ~20% of the other.  Which is fine if you acknowledge that you can only do ~20% of the other, and that the shape of it is likely to look very different to when you were spending 100% of your time on it.&lt;p&gt;As others have mentioned, if you are an engineering manager and you still want to dedicate some of your working time to development, you have to take yourself out of the critical path.  Nobody wants to hold up a release because you were working on an important part of it and you&amp;#x27;ve been constantly interrupted all week with managerial work and meetings.&lt;p&gt;Instead, pick things that are either tiny or decoupled from the release process.  Things like refactoring, non-critical bug fixes, documentation, tests, spikes.  These are the kinds of things that won&amp;#x27;t fall apart if your development productivity is unpredictable and the kinds of things that are easy to put down and pick up again.  As an engineering manager, you&amp;#x27;re interrupt-driven which is incredibly disruptive for focus.  If you do write code, then it has to be the code that works within those constraints, or you&amp;#x27;ll end up being a blocker for the rest of the team and your managerial work will suffer as well.</text></item></parent_chain><comment><author>hinkley</author><text>In a lot of organizations a Lead Dev is still a coder, but keeping an eye on the long game.&lt;p&gt;Personally, I think that the sort of code you&amp;#x27;re talking about here is a big part of the mix of things that a Lead should be working on, or at least championing.  You don&amp;#x27;t actually want these people to have too much code with their name on it for the same reason you don&amp;#x27;t want Managers to do it:  It gets treated as a sacred cow whether you want it to or not.&lt;p&gt;For myself, I&amp;#x27;d estimate it&amp;#x27;s about a 40-40-20 split between DevEx code, the most safety-critical functions in libraries, and example code respectively.  &lt;i&gt;But&lt;/i&gt;, I&amp;#x27;d aspire to flip the last two numbers (on a high functioning team I should be able to trust other people to do bits I barely trust myself to get right).&lt;p&gt;And unless you enjoy bottlenecks (some people do because it makes them feel special), you should be trying to get most of the code written by people of average skill (the peak of your employee bell curve).  So if I&amp;#x27;m writing even half as much code as they are, things aren&amp;#x27;t going well at all.  You want a light touch.</text></comment>