Timeline for How technical should a Project Manager be?
Current License: CC BY-SA 2.5
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 19, 2015 at 10:44 | comment | added | Quandary | And that the system is written in a maintainable fashion. Technically documented (I'm not talking about dOxygen or similar things). Otherwise there will be no more quick changes (and a good project manager should know that there is no such thing as a "quick change"). A project manager should also know the points that are most-likely going to go wrong. Especially if you have junior members in the team. So a PM is also kind of a supervisor. If he doesn't have those technical skills, he cannot execute that function. And it's not the job of other people to do that job, they have enough to do. | |
| May 19, 2015 at 10:38 | comment | added | Quandary | So for example, that you need to have one database structure for 5 customers, not 5 completely different for 5 customers... That you need one set of forms for everyone, not several. That the components are easily interchangable, without having to update the entire product. That the speed of the system is acceptable. That there are no severe rounding errors. That you don't have to do a lot of lenghty calculations to do more complex reports. That the database schema and constraints enforces the data correctness. That you don't use soft deletes, and properly historize via bug-free triggers. | |
| May 19, 2015 at 10:33 | comment | added | Quandary | Forthermore, if you put an incompetent person in charge, that's the fastest way to demotivate good people. That will demotivate the team, severely lower productivity, and lead to a bad "climate". What's more important, it will lead to bad long-term decisions, which might severely dampen the economic outlook of your company, and lower it's competitiveness. If you're an IT manager, you have to understand that (economies of ) scale is everything, and that building a system begins with carefully building the data-structure, and not the input forms. | |
| May 19, 2015 at 10:24 | comment | added | Quandary | Furthermore, if the project manager has no clue about technology, he's not in a position to make any conceptual "technical" decision, which, among other things, is the job of a project manager. You can't go to the customer, promise/sell him something, and then when you're back in the company, your engineers have to tell you that this is technically impossible... Furthermore, if you don't understand things, you might give your team wrong technical requirements, and in the end, the product will either not work, and require a year of "fixing", or you could have done it in half the time. | |
| May 19, 2015 at 10:18 | comment | added | Quandary | @Pawel Brodzinski: This doesn't really have something to do with trust. Just with competence and honesty. And even if you could be 100% certain that a person is honest, that would be no guarantee he/she is competent. If you have no clue, you cannot tell who is competent and who isn't, and worse, you might think you do, but get it wrong. You're also not able to tell if a time estimate is even the slightest bit realistic. A silly developer can severly overestimate the time (for him doing other things instead), and a young and inexperienced developer might not grasp the consequences of an action. | |
| Feb 8, 2011 at 20:17 | comment | added | DaveParillo | I like the trust comment | |
| Feb 8, 2011 at 7:09 | history | answered | Pawel Brodzinski | CC BY-SA 2.5 |