By the way I don't want to just be critic on that point. In general I found the talk very interesting on some aspects, specially those related to encouraging and empowering the young people, and supporting their good ideas and approaches and don't tearing down people when they are failing because all of us have failed at a certain time.
31:20 oh man....sorry, I had to turn it off... If you want to have a chance on making a software project to succeed, use people that are enough experienced on the technologies you will use and are able to teach/mentor the people of the team that do not have experience. If you are talking about making a commercial project succeed, never. I repeat, never, try something just because you are curious about it.
@architectureweekly Companies should pay training time (most of them already do) for employees (1/2 weeks a year?) and employees should be allowed to choose in which topics they want to be trained. Doing successful projects involve being efficient and effective. Both things can't be achieved when you pick something so important as a technology just because you are interested on it. As I said, you can do it partially if you have core people in the project that are experienced and will be able to mentor/train a small group that might not know it. But such a decision should never taken because people are 'curious and interested on it'.
Avraham here. I certainly see your point, and the way you state your good point makes me realise that I might have overstated my case. I agree that the successful delivery of quality software is the most important objective of the organization, and that we can't satisfy our curiosity at the expense of the business. However, I still hold the position that the interests of the team are valid considerations that should not be ignored. People perform better when they are given a chance to learn and explore. A good manager will know how to balance the team's need for learning and for expanding their horizons with the need to use solid knowledge they already have. Maybe allow for curiosity in a "controlled" or low-risky part of the project. Do you think you can see some merit in my position? Or do you really feel that it is "never" appropriate to try something new on a commercial project? Thanks for your good comment - sorry you had to stop in the middle.
@@apoupko1 I was kidding about stopping in the middle. I watched in detail the full video because it was in essence absolutely worth it. I totally agree on your further nuance and it also goes in same direction as my further comment. My suggestion about training people on their interests pusrues same objective. Curiosity and development personal interests are crucial to make a project successful. About the rest, as I said, I can only agree and in my opinion this video is a piece of very valuable wisdom on software project management. Thanks for it.
By the way I don't want to just be critic on that point. In general I found the talk very interesting on some aspects, specially those related to encouraging and empowering the young people, and supporting their good ideas and approaches and don't tearing down people when they are failing because all of us have failed at a certain time.
Thanks a lot!
31:20 oh man....sorry, I had to turn it off... If you want to have a chance on making a software project to succeed, use people that are enough experienced on the technologies you will use and are able to teach/mentor the people of the team that do not have experience. If you are talking about making a commercial project succeed, never. I repeat, never, try something just because you are curious about it.
Do you think it's to risky to try new technologies? When to learn them though?
@architectureweekly Companies should pay training time (most of them already do) for employees (1/2 weeks a year?) and employees should be allowed to choose in which topics they want to be trained. Doing successful projects involve being efficient and effective. Both things can't be achieved when you pick something so important as a technology just because you are interested on it. As I said, you can do it partially if you have core people in the project that are experienced and will be able to mentor/train a small group that might not know it. But such a decision should never taken because people are 'curious and interested on it'.
Avraham here. I certainly see your point, and the way you state your good point makes me realise that I might have overstated my case. I agree that the successful delivery of quality software is the most important objective of the organization, and that we can't satisfy our curiosity at the expense of the business. However, I still hold the position that the interests of the team are valid considerations that should not be ignored. People perform better when they are given a chance to learn and explore. A good manager will know how to balance the team's need for learning and for expanding their horizons with the need to use solid knowledge they already have. Maybe allow for curiosity in a "controlled" or low-risky part of the project.
Do you think you can see some merit in my position? Or do you really feel that it is "never" appropriate to try something new on a commercial project?
Thanks for your good comment - sorry you had to stop in the middle.
@@apoupko1 I was kidding about stopping in the middle. I watched in detail the full video because it was in essence absolutely worth it. I totally agree on your further nuance and it also goes in same direction as my further comment. My suggestion about training people on their interests pusrues same objective. Curiosity and development personal interests are crucial to make a project successful. About the rest, as I said, I can only agree and in my opinion this video is a piece of very valuable wisdom on software project management. Thanks for it.
Thanks!