One that I found universal among very different manager styles...
1) Knowing, what one does not know, and be willing to admit it. (even if it is everything)
2) Recognising, and Trusting the advice and decision of those who do.
Especially in larger organisations, it is way more likely to have a non-technical manager, then a technical manger.
And if anything I learnt, that a manager mains worth is not in what they do directly, but what they to discuss / delegate / decide on.
My personal favourite tale, was one where I recently joined a small company where I was their only backend developer (they were originally more of a pure design / standalone app / frontend) for the financial industry. And their manager was also a owner. Whose main value is knowing the industry, rather then code itself.
By some "luck", the manager and sales team has landed (but not signed) a huge deal, on redesigning a major company internal sales platform. A deal so big, if signed, would have quite literally doubled or even tripled the company. They even had a list of resume's of (real) senior programmers they could immediately hire to help build this project.
Hence they were effectively giving me the requirements, as a final check.
Everything sounded perfect, except for one major downplayed requirement. All data transactions, need to be mirrored to the existing IBM DB2 database, which was stuck at some 199X build, and will not be updated (as it breaks the existing platform). The requirement was for both platform (old and new) was to be used at the same time during the transitional period of approximately 1 year.
When I saw that one requirement in the mountain of specs, and confirmed and clarified that it is mandatory.
I immediately sounded it out to the owner/manager, that it was a no-go!
Development licensing fees aside. There are way too many unknowns in the legacy build, with effectively little to no public documentation (note we were not an IBM vendor, hence we had no access to their materials). Of which we might not be able to find the needed developer who knows the quirks of that ancient build in our country, let alone through our recruitment agency. (Not to mention the giant furball of sharing a database with another application)
Or more bluntly, I, and the team do not have the tech to do this. While possible, my fear is it will lead to development hell, and drain the company to closure.
Naturally being the newer tech guy, with zero managerial, i was up against the sales-guy with some managerial experience, and technically my superior in the chain, saying its "no issue, its only a small part of the project requirements".
I in all honesty, thought I would be doomed to work on this project.
So it totally shocked me, that the next day the project was called off. As the owner said to the client : that the deal was off, if they require it to be full backwards compatible.
Much to the frustration to the salesteam, and the owner himself, as he has spent months of his own hard work getting this deal done. It certainly must not have been easy for him (as I would also learn personally in my own startup eventually)
Fast forward 1 year - and the "other vendor" which won the contract instead at a much higher quote, was stuck in development hell trying to get the system backwards compatible.
Fast forward another year - and the project was dead in the water.
Needless to say, with many projects down the line, I found that despite not "knowing or doing anything" but listening to others advice. (Even some against my advice, however it was in areas I admit I would not be the best to judge).
Sadly to many stories are of 'the other company'. Excellent job on your part picking out the minor line and knowing what it would involve. You saved your company.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
One that I found universal among very different manager styles...
1) Knowing, what one does not know, and be willing to admit it. (even if it is everything)
2) Recognising, and Trusting the advice and decision of those who do.
Especially in larger organisations, it is way more likely to have a non-technical manager, then a technical manger.
And if anything I learnt, that a manager mains worth is not in what they do directly, but what they to discuss / delegate / decide on.
My personal favourite tale, was one where I recently joined a small company where I was their only backend developer (they were originally more of a pure design / standalone app / frontend) for the financial industry. And their manager was also a owner. Whose main value is knowing the industry, rather then code itself.
By some "luck", the manager and sales team has landed (but not signed) a huge deal, on redesigning a major company internal sales platform. A deal so big, if signed, would have quite literally doubled or even tripled the company. They even had a list of resume's of (real) senior programmers they could immediately hire to help build this project.
Hence they were effectively giving me the requirements, as a final check.
Everything sounded perfect, except for one major downplayed requirement. All data transactions, need to be mirrored to the existing IBM DB2 database, which was stuck at some 199X build, and will not be updated (as it breaks the existing platform). The requirement was for both platform (old and new) was to be used at the same time during the transitional period of approximately 1 year.
When I saw that one requirement in the mountain of specs, and confirmed and clarified that it is mandatory.
I immediately sounded it out to the owner/manager, that it was a no-go!
Development licensing fees aside. There are way too many unknowns in the legacy build, with effectively little to no public documentation (note we were not an IBM vendor, hence we had no access to their materials). Of which we might not be able to find the needed developer who knows the quirks of that ancient build in our country, let alone through our recruitment agency. (Not to mention the giant furball of sharing a database with another application)
Or more bluntly, I, and the team do not have the tech to do this. While possible, my fear is it will lead to development hell, and drain the company to closure.
Naturally being the newer tech guy, with zero managerial, i was up against the sales-guy with some managerial experience, and technically my superior in the chain, saying its "no issue, its only a small part of the project requirements".
I in all honesty, thought I would be doomed to work on this project.
So it totally shocked me, that the next day the project was called off. As the owner said to the client : that the deal was off, if they require it to be full backwards compatible.
Much to the frustration to the salesteam, and the owner himself, as he has spent months of his own hard work getting this deal done. It certainly must not have been easy for him (as I would also learn personally in my own startup eventually)
Fast forward 1 year - and the "other vendor" which won the contract instead at a much higher quote, was stuck in development hell trying to get the system backwards compatible.
Fast forward another year - and the project was dead in the water.
Needless to say, with many projects down the line, I found that despite not "knowing or doing anything" but listening to others advice. (Even some against my advice, however it was in areas I admit I would not be the best to judge).
He was one of the best manager I ever had.
Sadly to many stories are of 'the other company'. Excellent job on your part picking out the minor line and knowing what it would involve. You saved your company.