--- title: "Great Coders Deserve Great Managers" url: "https://osherove.com/blog/2004/9/3/great-coders-deserve-great-managers.md" canonical: "https://osherove.com/blog/2004/9/3/great-coders-deserve-great-managers.html" published: "2004-09-03T07:53:00" updated: "2004-09-03T07:53:00" tags: ["Project Management"] author: "Roy Osherove" description: "I totally agree with Johanna on this one : Great coders do need great managers. I know I've often wanted demended of my workplace to invest in me just as much as I invest in my work. There are several points:…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Great Coders Deserve Great Managers By Roy Osherove September 3, 2004 In [Project Management](https://osherove.com/blog/category/project-management) **Historical article** · Originally published September 3, 2004; technical details may be outdated. I totally agree with [Johanna on this one](http://www.jrothman.com/weblog/archive/2004_08_01_mpdarchive.html#109292260386983949): Great coders do need great managers. I know I've often ~wanted~demended of my workplace to invest in me just as much as I invest in my work. There are several points: - Professional developers are craftsmen, and just like any craftsmen, they need good tools to do their job. In this case good tools can be a good mouse and keyboard,  a reasonable sized screen (but two screens or a big screen is a better tool and leads to better productivity - there are facts on this one), good hardware, knowledge sources,(books, internal knowledge base, good technical team or team lead..), productivity Add-ins for Visual Studio and other things like that. So - if you're a manager and your best coder comes over and asks for a mouse that has four buttons - trust them. they. if they say that their machine is too slow for them to do debug and build efficiently, listen to them. If they ask for that add-in that helps them do that "refactoring" work you have no idea what it means, listen to them, and ask them to show it to you and explain. They are (usually) not spoiled - they are flagging you that you have a chance to improve your worker's productivity with a small investment - and generate (or save) lots of money off of that.  - Great coders know what to do once they have a target in sight. Learn to leave them alone and not check over their shoulder every few minutes. Just help them be productive, remove any obstacles that are in their way (they may be right when they say that they'd rather code than go to the 10th meeting today about the product..) and get out of their way. - Great coders need to have unlimited knowledge resources: The Internet is one - but a lot of times books and magazines are a great way to keep them in mental shape. Don't worry if books disappear every once in a while, either. Take it as a complement and purchase more. Or maybe make a library. In any case - let them learn what they need to. And let them learn it on \*your\* time, not their's. they are probably learning on their own time anyway. Respect their quest for knowledge - and you'll get respect and a boost of productivity and loyalty in return. - Great coders need respect. When they say something, listen to them. They may have a point you didn't think about. They may have sat all of last night researching that little corner of the area you're talking about and eve though they may sound a bit crazy - listen to them. - Spoil them. Really. Make them feel important. But them stuff. Give them a small club room to relax. They maybe spoiled but good people are really \*really\* hard to find. - Share them in decisions that affect them. either tell them exactly why some of the hard decisions were made .don't hold back - they can smell fear and lies. If you give them the truth - they will understand. or maybe they'll have a better alternative... If you can - share them in the decision making process as people who can influence the decision. - Let them decide how to build the damn feature you requested - unless you have a specific way you think is best. In that case - confer with them and make the design decision together. - Make them review each other's code. they will learn a lot and you'll benefit from better knowledge dispersed through out your team. I bet there are more things I just can't think about right now will update as needed. **Update**: In response to [James' post on this issue](http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3271650490): In my view, a great manager is also a good enough politician and will "convince" IT on the needs of the developers. in other words - he's there to do fighting for those who can' speak - his/her team. Sometimes that won't work. As a purist I'd say - "Don't stay where they don't trust you enough to listen to your expert advice". Not too realistic - but a good point to think about when you find out there's just no way in hell that anyone's is going to spend 2$ more for each of your 10 devs to get a mouse that actually has a scroll wheel \*shudder\*. ## More in Project Management [All posts in Project Management](https://osherove.com/blog/category/project-management) - Dec 29, 2004 ### [My interview with Johanna Rothman goes live on ITConversations.Com](https://osherove.com/blog/2004/12/29/my-interview-with-johanna-rothman-goes-live-on-itconversatio.html) - Dec 8, 2004 ### [Chatting with Johanna Rothman](https://osherove.com/blog/2004/12/8/chatting-with-johanna-rothman.html) - Jun 17, 2004 ### [It's healthy to be scared of new projects](https://osherove.com/blog/2004/6/17/its-healthy-to-be-scared-of-new-projects.html) - Jun 17, 2004 ### [Communicating Project Progress with a white board](https://osherove.com/blog/2004/6/17/communicating-project-progress-with-a-white-board.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/