One thing I've noticed over the years is the correlation of the effectiveness of a team and the source of authority of their management.
Software development teams managed by MBAs who have no hands-on experience writing software are hit and miss. If the managers are engaged and proactive, this often works really well, especially if the team is large; formal training in managing large projects is absolutely worthwhile, especially for being able to better peg far-off deadlines or complex integrations.
The problems can occur when management wants to go in a different direction than the coders believe is correct. Maybe it's a heavy lean towards new features (with too little maintenance), or it's time spent polishing, but not making the system more robus, or any number of things; management needs to have the team believing they're working on the most important part of the software for the business. (If that's improving reliability so that the coders aren't woken up at 4 AM on a page, that's what it takes to keep those coders coming in to work.)
Software development teams managed by software developers who willingly took a promotion away from development have a different set of benefits. It's often far easier for these managers to motivate the team; they have the same mental wiring for weighing rewards, and the same wiring for feeling good about building things in general. Teams follow these managers more easily.
Peter's Principle can bite a manager here; if they were a phenomenal coder promoted to their first level of incompetence, they could be a terrible manager, misprioritizing tasks and leading the team into a hole they're not going to escape.
Overall:
- If you have an MBA, realize that relating to the developers is important.
- Have a developer you check things by from time to time.
- If developers seem to be burning out, prioritize fixing the issue.
- A $100 cash bonus might go a lot less far in their heads than taking them out to a $50 dinner. *Ask*, and don't waste money.
- If you were a developer, realize that the developers don't always have the context of the big picture.
- Look longer term.
- Spend a bit of time reading up on what you don't know from experience.
- Gant charts and other management tools for long term goal prediction and managing complex integrations are always wrong... but you'll know you're wrong *sooner* than if you were flying without these.
Engineering Elixir Applications, in print
1 week ago
2 comments:
Hi
I read this post 2 times. It is very useful.
Pls try to keep posting.
Let me show other source that may be good for community.
Source: Product development engineer interview questions
Best regards
Jonathan.
I have no doubt to read this helpful feedback.I am writing a research paper and collecting information on this topic. Your post is one of the better that I have read.
lucky hat
Post a Comment