Ken Norton. How to work with programmers
I have been working in IT for 20 years, the last 13 - as a project manager. It so happened that during this time I earned a reputation as a manager who effectively works with programmers. Thanks to this skill, I went down in history as one of the three greatest managers of projects and directions - along with Niccolo Macciavely and Steve Jobs.
For many years I kept my professional secrets with me. But the time has come: today I will share with you the “Ten Step-by-Step Instructions for Working with Programmers.” Or, if closer to the point, let's call it this way: "How to make programmers do what you want."
Actually, why should you listen to me at all? Just look at the numbers. During my career as one of the three greatest project managers of all times and peoples, I had the opportunity to work with approximately 3,875,000 programmers. Of these, all my assignments were exactly fulfilled by more than 95% - i.e. as many as 1,000,000 programmers (approximate - for project managers, frankly, not up to mathematics). This is a gigantic amount and a gigantic experience, which is certainly worth considering.
As a project manager, you must rely on your success. Consider that top managers will not just try to distribute honors to your whole team. Therefore, you need to be vigilant: praise you and no one else, only you have the right to reward. A successfully completed project is the main driving force of a career, and why should you shine on someone's LinkedIn profile, besides your own? So, finally, throw off the ninja costume, step onto the stage, bathe in beams of glory and attention.
No, no, something goes at random. And in the case of software development, the software is usually at random. If the program does not work, the programmer is to blame. This is pure logic. So, when they accuse you, translate the arrows, and if possible, prepare the ground for choosing a scapegoat in advance. Remember: "we" has nothing to do with "I" (except for the fact that these are pronouns).
')
Small technical details - this is the lot of programmers, you have better lessons. For example, generate ideas. A thorough understanding brings nothing but disappointment, and forms the so-called "rational" view of the limits of the possible. If you know what is easy and what is difficult, you will not accomplish anything great. Avoid small things and details at all costs. Anything you can imagine is easily accomplished with a dozen lines of code. What exactly ten is not important at all.
Programmers write code, this is their usual occupation. They are always whining that they are in vain distracting them from all the important hacker affairs. So why should you waste time programmers, attracting them to the project to the programming stage? Coming to the office of the architect, you will not find there builders kicking a noodle. Call them only when you have thought over the whole strategy, have discussed everything with everyone, and all that remains is to write the code.
The best way to show your professionalism is to truly streamline the work of your team. The rules serve as a lubricant for the wheels of progress. Whenever possible, schedule meetings, meetings, meetings with detailed debriefing. Maintain the productivity of programmers by requiring them to fill in tables in project control systems, write reports, and notify the supervisors of all updates. Except you, no one will do it. Start right off the bat: you will never achieve anything with messages on the answering machine!
Programmers tend to analyze everything. This means that they practice a not too sophisticated approach to decision making, often relying not on thought and free flight of thought, but on “supporting data” and “rationale”. When making decisions, keep the atmosphere of secrecy - it will keep them on their toes. They will complain anyway, so it’s just pointless to give them specific reasons for this.
One of your functions as a project manager is to take responsibility on behalf of the team. To be a leader means to lift the bar in space and set a goal for everyone to teleport through it. Approve the terms of the project, without consulting with your team - thus you will show a healthy ambition. The situation in which a person is forced to answer for other people's promises tempers the character and reveals his best features. Remember President Kennedy. He set a date for landing on the moon "from the lantern" and NASA did an excellent job, eventually securing lunar mineral resources for the company "Standard Oil".
You are a busy manager, and you simply do not have time to wait for the programmer to complete the current task. Whatever he works, your need is still more important at the moment. So quietly distract programmers anytime. ICQ, Skype and the phone give a good result, but all this is far less effective than the old old-fashioned way: come up and pat on the shoulder. You ask, what if the programmer is working on a task that you yourself set for him an hour ago? Nothing wrong! But in the end, he will learn to set priorities himself.
For a career, there is almost nothing more dangerous than a situation in which your wrongness is convincingly proved. Take all measures to ensure that this never happens - be extremely contradictory, express yourself as vaguely as possible. Do not be afraid to change your mind at any time. If you have taken all possible positions, then in the end, by definition, you will be right. Do not write anything, and even better let your documents be so wordy and boring that no one wants to read them.
It happens, programmers say that this or that "is impossible." This is a lie. In programming, nothing is impossible, if only to think hard about brains. The Wright brothers did not even think that it was impossible to fly across the Antlantic! Always proceed from the assumption that the programmer wants to circle you finger, and act accordingly. Say, henceforth, when you hear phrases like “technical debt” or “work at home,” be ready to immediately catch him in a lie.
Well that's all. Now you have my “Ten-Step Programming Instructions Manual”. Print it and hang it in the workplace (preferably away from prying eyes). By following it, you can also become one of the greatest project managers (well, or at least just a great one). Nothing complicated.
I think this is blatantly obvious to everyone, but if it doesn’t suddenly: do not act as described in the Instructions. It happens that even the most conscientious project managers admit small sins on a particular item. I certainly do. Aim for the opposite and maybe you will succeed as a project manager. Or, at least, get colleagues from among programmers who will be interested in your success.
And finally ...
For many years I kept my professional secrets with me. But the time has come: today I will share with you the “Ten Step-by-Step Instructions for Working with Programmers.” Or, if closer to the point, let's call it this way: "How to make programmers do what you want."
Actually, why should you listen to me at all? Just look at the numbers. During my career as one of the three greatest project managers of all times and peoples, I had the opportunity to work with approximately 3,875,000 programmers. Of these, all my assignments were exactly fulfilled by more than 95% - i.e. as many as 1,000,000 programmers (approximate - for project managers, frankly, not up to mathematics). This is a gigantic amount and a gigantic experience, which is certainly worth considering.
1. Attribute all merit to yourself.
As a project manager, you must rely on your success. Consider that top managers will not just try to distribute honors to your whole team. Therefore, you need to be vigilant: praise you and no one else, only you have the right to reward. A successfully completed project is the main driving force of a career, and why should you shine on someone's LinkedIn profile, besides your own? So, finally, throw off the ninja costume, step onto the stage, bathe in beams of glory and attention.
2. Do not take the blame.
No, no, something goes at random. And in the case of software development, the software is usually at random. If the program does not work, the programmer is to blame. This is pure logic. So, when they accuse you, translate the arrows, and if possible, prepare the ground for choosing a scapegoat in advance. Remember: "we" has nothing to do with "I" (except for the fact that these are pronouns).
')
3. Do not bother about the details.
Small technical details - this is the lot of programmers, you have better lessons. For example, generate ideas. A thorough understanding brings nothing but disappointment, and forms the so-called "rational" view of the limits of the possible. If you know what is easy and what is difficult, you will not accomplish anything great. Avoid small things and details at all costs. Anything you can imagine is easily accomplished with a dozen lines of code. What exactly ten is not important at all.
4. Attract them at the end.
Programmers write code, this is their usual occupation. They are always whining that they are in vain distracting them from all the important hacker affairs. So why should you waste time programmers, attracting them to the project to the programming stage? Coming to the office of the architect, you will not find there builders kicking a noodle. Call them only when you have thought over the whole strategy, have discussed everything with everyone, and all that remains is to write the code.
5. Properly organize their work.
The best way to show your professionalism is to truly streamline the work of your team. The rules serve as a lubricant for the wheels of progress. Whenever possible, schedule meetings, meetings, meetings with detailed debriefing. Maintain the productivity of programmers by requiring them to fill in tables in project control systems, write reports, and notify the supervisors of all updates. Except you, no one will do it. Start right off the bat: you will never achieve anything with messages on the answering machine!
6. Never talk about the reasons for the decisions.
Programmers tend to analyze everything. This means that they practice a not too sophisticated approach to decision making, often relying not on thought and free flight of thought, but on “supporting data” and “rationale”. When making decisions, keep the atmosphere of secrecy - it will keep them on their toes. They will complain anyway, so it’s just pointless to give them specific reasons for this.
7. Take obligations without consulting anyone.
One of your functions as a project manager is to take responsibility on behalf of the team. To be a leader means to lift the bar in space and set a goal for everyone to teleport through it. Approve the terms of the project, without consulting with your team - thus you will show a healthy ambition. The situation in which a person is forced to answer for other people's promises tempers the character and reveals his best features. Remember President Kennedy. He set a date for landing on the moon "from the lantern" and NASA did an excellent job, eventually securing lunar mineral resources for the company "Standard Oil".
8. Do not hesitate to distract them from work.
You are a busy manager, and you simply do not have time to wait for the programmer to complete the current task. Whatever he works, your need is still more important at the moment. So quietly distract programmers anytime. ICQ, Skype and the phone give a good result, but all this is far less effective than the old old-fashioned way: come up and pat on the shoulder. You ask, what if the programmer is working on a task that you yourself set for him an hour ago? Nothing wrong! But in the end, he will learn to set priorities himself.
9. Be ambiguous.
For a career, there is almost nothing more dangerous than a situation in which your wrongness is convincingly proved. Take all measures to ensure that this never happens - be extremely contradictory, express yourself as vaguely as possible. Do not be afraid to change your mind at any time. If you have taken all possible positions, then in the end, by definition, you will be right. Do not write anything, and even better let your documents be so wordy and boring that no one wants to read them.
10. They lie all the time.
It happens, programmers say that this or that "is impossible." This is a lie. In programming, nothing is impossible, if only to think hard about brains. The Wright brothers did not even think that it was impossible to fly across the Antlantic! Always proceed from the assumption that the programmer wants to circle you finger, and act accordingly. Say, henceforth, when you hear phrases like “technical debt” or “work at home,” be ready to immediately catch him in a lie.
Well that's all. Now you have my “Ten-Step Programming Instructions Manual”. Print it and hang it in the workplace (preferably away from prying eyes). By following it, you can also become one of the greatest project managers (well, or at least just a great one). Nothing complicated.
Afterword
I think this is blatantly obvious to everyone, but if it doesn’t suddenly: do not act as described in the Instructions. It happens that even the most conscientious project managers admit small sins on a particular item. I certainly do. Aim for the opposite and maybe you will succeed as a project manager. Or, at least, get colleagues from among programmers who will be interested in your success.
- 1. Do not ascribe to yourself all the merits.
- 2. Accept the blame.
- 3. Work through the details.
- 4. Attract programmers at an early stage.
- 5. Simplify their work.
- 6. Always talk about the reasons for the decisions.
- 7. Never undertake commitments without consulting programmers.
- 8. Respect their time.
- 9. Be accurate and unambiguous.
- 10. Trust the programmers.
And finally ...
- 11. Always bring cookies.
Source: https://habr.com/ru/post/296998/
All Articles