Engineers know best - follow-up
A while back I wrote the post, Engineers know best. As a follow up to that post, it turns out I made the right decision. The engineer who had promised the completion of his tasks on time put in long hours and did in fact complete all of his work on time. This was the case of an engineer who wanted to complete his tasks and who knew the challenge ahead of him better than anyone else.
Similar to this common lesson is to listen when the engineer feels the assigned tasks cannot be completed in time. As a software engineer I was always able to complete my tasks on time-but the tasks were not always done right. When pushed to complete an unrealistic schedule, corners will get cut. These corners might not show on the surface, but under the hood the code might be an unmaintainable mess.
A quick YouTube video, “How developers fix bugs”, is a satirical explanation of how software developers can cut corners.
The lesson to learn here is an experienced engineer needs to be trusted when it comes to planning schedules. As a project manager we know project management, budgeting, resource management, customer requirements, and we might even have many years of engineering experience. But the engineer knows his or her skills, abilities, and the hidden coding obstacles he or she will need to overcome. Listen to your engineers and trust their recommendations. The success of your project’s success depends on it.
3 comments:
You have better faith in the engineers you work with than I do. I think eventually this will bite you in the ass. The benefit of being a manager with a software engineering background is being able to utilize your experience and know when engineers are over exaggerating or being too gun hoe. Don’t be afraid to push back on their estimates if you disagree.
I’d like to share my story with you all.
I became a manager about 7 years ago. Like most managers, I was promoted not because of my management abilities but for my success as an engineer. At first I was helping my engineers design and write their code. I was in every engineers’ cubical at least twice a day. I thought I was being a good manager but I came to find out, that I was becoming known in my company as a micromanager. Engineers did not want to work with me at all. It was then that a senior manager explained to me that my job description had changed. I was now in a position where I needed to be more of a manager and less of an engineer.
I have seen this situation play out many times in my career. Brian, you seem to be heading down the same path I once did. Michael seems to be figuring this dilemma out on his own and has been so gracious to share it with us all. But Brian, I see myself in you and you need to learn that your engineers want to succeed as much as you do. Become more understanding or you will find yourself a manager without anyone to manage.
Brian, I agree with your point that having an engineering background does have its advantages as a manager, but Mountain is right. Pushing back on an engineer’s estimations will not help the situation. In the end, it is the engineer who is actually going to “do the work”. If his or her estimations are ignored and if the project is not finished on time or at the quality required by the customer, it falls on your shoulders. Empower your engineers and give them ownership of their work. They will surely enjoy their work more and make sure their deadlines are met.
Thank you both for your comments.
Post a Comment