The Basics of Software Production
From my experience as Software Production Manager, I have created a list of things that a S/W Manager should have in mind. In this post I’d like to share them and maybe get some feedback from you. Please note that this is not a technical article. It is mostly about human interaction and team building. Here goes:
1) Establish team spirit: You are the leader of this whole thing. No doubt about that. But what happens below your level. Are team member competing with each other? Are their roles clear to them? Are there conflicts? Sort it out, the soonest!
2) Assign specific roles: Don’t think that everybody can do anything. OK, this is a hard one when the project is small and has limited resources, but still… you have to try. Let alone the fact that if members feel that you are using everybody for everything, they will quickly come to the conclusion that you don’t know what you’re doing.
3) Give members the “big picture”: You would normally expect that a programmer can operate on “need to know” basis. This is more or less correct; or is it? No, you should try and give them the “whole picture”: What is this project about? Who the new software will help? By what means and processes? What benefits will it bring to the end-user and his Management? You may argue: “Why is a programmer interested in that?” I will answer that the programmer, having the entire picture in his head, can design his code in a more “open-minded” manner. He will know that the “transaction” that he is designing will be used by the module that his colleague is developing right know. He will know that this transaction is time-sensitive and so its user interface should be clean and simple. He will know why “that report” is very important to the Management and so it needs more filtering criteria and ability to sort by column. These are pieces of information that you simply just can’t give them through the Project’s Technical Documentation! Extra bonus: You are giving your programmers some kind of “business training”.
4) Give members “room to breathe”: I know that you are a better programmer than they are (that’s why you have been promoted, anyway!) But they are also IT professionals and they are trying to evolve. Give them room to develop, decisions to make. Yes, they will most certainly make mistakes. That’s why you are there: check, test and correct mistakes. But you must see this as an opportunity to help members grow and – rest assured – in the next projects things are going to be easier. Oh, I should not forget this: This process will somewhat increase the total time needed for the implementation of the project; you might want to include that in your project planning and assumptions.
5) Members are also humans: Don’t push them too hard. Don’t push them more than you need to get the job done. Difficult days will actually come – that’s almost certain. You need them to be in “tip-top” shape when that time comes. You need them to understand that “now, we have a few days of pushing hard”. They will understand. But they won’t, if you are pressuring them all the time! Would you, if you were on their shoes?
6) Be a leader, not a boss: Be ready to execute yourself whatever instructions or commands you are issuing. Don’t ask them to “jump off a plane” if you are not willing to do so! You are there to set an example and not smoke you cigar in you big-time corner office. They are watching you, just like you are watching them. Oh, and something else: You may have your own office, but they don’t; they are working together in shared space. Therefore, you can expect comments flying around like kites! Don’t give them ground to do that. Inspire respect to your personality.
7) Be a friend not a “buddy”: You must have good human relationships with your team. They must not fear you. They must not feel threatened by you. Be a friend to them. Talk to them. Listen to their problems. But don’t be a “buddy”: Don’t go with them for beers every afternoon, on happy hour. Don’t tell them jokes all the time. Don’t disclose personal details of your life, like “I had a big fight yesterday with my wife”.
8) Reward them: I don’t have much to say on this. It’s obvious! But just one tip: First talk to your boss (if you have to) and get his/her OK for some kind of reward. After that, go ahead and make some promises (only the ones that you can keep!). Reward after the job has been done is nice but it’s even nicer for members to have something to wait during all that time of coding, coding, coding!
1) Establish team spirit: You are the leader of this whole thing. No doubt about that. But what happens below your level. Are team member competing with each other? Are their roles clear to them? Are there conflicts? Sort it out, the soonest!
2) Assign specific roles: Don’t think that everybody can do anything. OK, this is a hard one when the project is small and has limited resources, but still… you have to try. Let alone the fact that if members feel that you are using everybody for everything, they will quickly come to the conclusion that you don’t know what you’re doing.
3) Give members the “big picture”: You would normally expect that a programmer can operate on “need to know” basis. This is more or less correct; or is it? No, you should try and give them the “whole picture”: What is this project about? Who the new software will help? By what means and processes? What benefits will it bring to the end-user and his Management? You may argue: “Why is a programmer interested in that?” I will answer that the programmer, having the entire picture in his head, can design his code in a more “open-minded” manner. He will know that the “transaction” that he is designing will be used by the module that his colleague is developing right know. He will know that this transaction is time-sensitive and so its user interface should be clean and simple. He will know why “that report” is very important to the Management and so it needs more filtering criteria and ability to sort by column. These are pieces of information that you simply just can’t give them through the Project’s Technical Documentation! Extra bonus: You are giving your programmers some kind of “business training”.
4) Give members “room to breathe”: I know that you are a better programmer than they are (that’s why you have been promoted, anyway!) But they are also IT professionals and they are trying to evolve. Give them room to develop, decisions to make. Yes, they will most certainly make mistakes. That’s why you are there: check, test and correct mistakes. But you must see this as an opportunity to help members grow and – rest assured – in the next projects things are going to be easier. Oh, I should not forget this: This process will somewhat increase the total time needed for the implementation of the project; you might want to include that in your project planning and assumptions.
5) Members are also humans: Don’t push them too hard. Don’t push them more than you need to get the job done. Difficult days will actually come – that’s almost certain. You need them to be in “tip-top” shape when that time comes. You need them to understand that “now, we have a few days of pushing hard”. They will understand. But they won’t, if you are pressuring them all the time! Would you, if you were on their shoes?
6) Be a leader, not a boss: Be ready to execute yourself whatever instructions or commands you are issuing. Don’t ask them to “jump off a plane” if you are not willing to do so! You are there to set an example and not smoke you cigar in you big-time corner office. They are watching you, just like you are watching them. Oh, and something else: You may have your own office, but they don’t; they are working together in shared space. Therefore, you can expect comments flying around like kites! Don’t give them ground to do that. Inspire respect to your personality.
7) Be a friend not a “buddy”: You must have good human relationships with your team. They must not fear you. They must not feel threatened by you. Be a friend to them. Talk to them. Listen to their problems. But don’t be a “buddy”: Don’t go with them for beers every afternoon, on happy hour. Don’t tell them jokes all the time. Don’t disclose personal details of your life, like “I had a big fight yesterday with my wife”.
8) Reward them: I don’t have much to say on this. It’s obvious! But just one tip: First talk to your boss (if you have to) and get his/her OK for some kind of reward. After that, go ahead and make some promises (only the ones that you can keep!). Reward after the job has been done is nice but it’s even nicer for members to have something to wait during all that time of coding, coding, coding!
Great post. Thanks for sharing.
ReplyDeleteTHANK YOU FOR THE INFORMATION
ReplyDeletePLEASE VISIT US
erp software companies