Ken Norton. How to work with programmers

Posted by Kenneth Norton, Team Leader, Google
  • Transfer
I have been working in the field of IT for 20 years, the last 13 - as a project manager. It so happened that during this time I have earned a reputation as a manager who works effectively with programmers. Thanks to this skill, I went down in history as one of the three greatest leaders in projects and areas - along with Nicolo Machiaveli and Steve Jobs.

For many years I kept my professional secrets to myself. But the time has come: today I will share with you the "Ten-step instruction for working with programmers." Or, closer to the point, let's call it this: "How to get programmers to do what you want."

Actually, why on earth would you even listen to me? Just look at the numbers. During my career as one of the three greatest project managers of all time, I have worked with approximately 3,875,000 programmers. Of these, more than 95% of them carried out all my instructions exactly - i.e. a whole 1,000,000 programmers (a rough estimate - to project managers, frankly, not to mathematics). This is a gigantic amount and gigantic experience, which is certainly worth considering.

1. Attribute all the merits to yourself.

As a project manager, you should count on recognizing your success. Keep in mind that top managers will repeatedly try to distribute honors to your entire team. Therefore, you need to be vigilant: praise you and no one else, only you have the right to a reward. A successfully completed project is the main driving force behind your career, and why do you want to shine on someone else's LinkedIn profile other than your own? So, finally, throw off the ninja costume, go up to the stage, bathe in the rays of glory and public attention.

2. Do not take the blame.

No, no, something will go awry. And in the case of software development, at random, as a rule, there is software. If the program does not work, the programmer is to blame. This is pure logic. So when you are being blamed, translate the arrows, and if possible prepare the way for choosing the scapegoat in advance. Remember: “we” has nothing to do with “I” (except that it is a pronoun).

3. Do not bother about the details.

Small technical details are the lot of programmers, you have better classes. 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 won’t do anything great. Avoid the little things and details at all costs. Everything you can imagine is easily doable in a dozen lines of code. Which exactly dozen is not important at all.

4. Attract them at the end.

Programmers write code, this is their usual activity. They always whine that how much they are in vain distracting from all sorts of important hacker cases. So why should you waste the time of programmers, drawing them to the project before the programming stage? Arriving at the office of the architect, you will not find builders kicking the bulldozer there. Call them only when you have thought out the whole strategy, you have discussed everything with everyone, and you just have to write the code.

5. Properly organize their work.

The best way to show your professionalism is to really streamline the work of the team. Rules serve as a lubricant for the wheels of progress. Whenever possible, schedule meetings, planning meetings, meetings with a detailed debriefing. Maintain the productivity of programmers by requiring them to fill out tables in the project control systems, write reports, and notify the authorities electronically of all updates. No one will do this except you. Start right off the bat: with messages on the answering machine you won’t achieve anything!

6. Never talk about the reasons for decisions.

Programmers tend to analyze everything. This means that they profess a not too sophisticated approach to decision making, often relying not on vision and free flight of thought, but on “supporting data” and “logical justifications”. When making decisions, keep an atmosphere of secrecy - this will keep them in suspense. They will complain in any case, so it is simply pointless to give them specific reasons for this.

7. Make commitments without consulting anyone.

One of your functions as a project manager is to make commitments on behalf of the team. Being a leader means lifting the bar into space and setting a goal for everyone to teleport through it. Confirm the terms of the project without consulting your team - thereby you will show a healthy ambition. The situation in which a person is forced to answer for other people's promises tempers his character and reveals his best features. Remember President Kennedy. He set the date of landing on the moon "from the lantern" and NASA did an excellent job, eventually securing the lunar mineral resources for Standard Oil.

8. Feel free to distract them from work.

You are a busy manager, and you just do not have time to wait for the programmer to complete the current task. Whatever he is working on, your need at the moment is still more important. So calmly distract programmers whenever you want. “ICQ”, “Skype” and the phone give a good result, but all this is much less effective than the old grandfather's way: to approach and pat on the shoulder. You ask, what if the programmer is working on a task that you yourself set for it an hour ago? Nothing wrong! But in the end, he will learn how to set his own priorities.

9. Be controversial.

There is almost nothing more dangerous for a career than a situation in which your wrongness is convincingly proven. Take all measures so 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 by definition you will be right. Do not write anything, and even better, let your documents be so verbose and boring that no one wants to read them.

10. They lie all the time.

It happens that programmers say that this or that is "impossible." This is a lie. In programming, nothing is impossible, if only a good brain. It didn’t even occur to the Wright brothers that it was impossible to fly over the Atlantic! Always proceed from the assumption that the programmer wants to circle you around the finger, and act accordingly. Say, henceforth, when you hear phrases like “technical duty” or “work at home”, be prepared to immediately catch him in a lie.

That's it. Now you have my “Ten-step instruction for working with programmers”. Print it and hang it in the workplace (better away from prying eyes). Following it, you can also become one of the greatest project managers (well, or at least just great). Nothing complicated.


I think this is blatantly obvious to everyone, but if suddenly not: do not do as described in the "Instructions". It happens that even the most conscious project managers make small sins regarding a particular item. I certainly. Strive for the opposite and perhaps you will succeed as a project manager. Or at least get fellow programmers who will be interested in your success.

  • 1. Do not ascribe to yourself all the merits.
  • 2. Take the blame on yourself.
  • 3. Work out the details.
  • 4. Engage programmers at an early stage.
  • 5. Simplify their work.
  • 6. Always talk about the reasons for the decisions.
  • 7. Never make a commitment without consulting with programmers.
  • 8. Respect their time.
  • 9. Be precise and unambiguous.
  • 10. Trust the programmers.

And finally ...
  • 11. Always bring cookies.

Also popular now: