Common Mistakes of New Engineering Managers
I disagree about &#x27;Still doing much technical work&#x27; being a problem. The author incorrectly infers that a manager writing code is going to take away developers&#x27; freedom. It&#x27;s the opposite.<p>The way I manage developers is I design the system into small projects with separate concerns and which can be easily integrated together. With the participation of the team, we discuss and iterate over the design of interfaces between those components&#x2F;projects.<p>Then when it comes time to implement, I assign &#x27;ownership&#x27; of each project to a  developer (with consultation with them). Then with the exception of a few basic guidelines, they can implement it however they want. We just do regular peer reviews of each other&#x27;s work. We tolerate code style variations between different projects but each project must be internally consistent.<p>So far all our projects never needed more than 2 people to implement (each one having 1 developer as the project owner). At the end, we integrate maybe 10 different projects into the final working product (which gets its own repo).<p>This approach to development is extremely fast and robust (very few bugs which are easily caught and fixed). We don&#x27;t even need special tools or programming languages. We just use plain JavaScript; never had the need to use TypeScript, the code is very easy to follow so it&#x27;s not a problem.<p>All you need is to have small projects with clear separation of concerns. The trick is to not invent new abstractions; all technical abstractions should come from the specification and be understood by non-technical people. Also all components&#x2F;projects should have simple interfaces between each other (only basic types that can easily be serialized into a JSON string). Different projects&#x2F;components should never pass &#x27;live instances&#x27; to each other; that would indicate poor separation of concerns.