19 bad advice to the IT manager of the bank ... or a tablecloth expensive

Today my manager decided to leave the bank where I work, transforming him from a reputable employer to a place where everyone scatters in just a year. This article is both a farewell letter to him and an instruction to others "how not to do it."





  1. Make development processes bureaucratic so that they are understandable only to those who developed them. In general, the time that a programmer spends on approvals, correspondence, attempts to explain something to people who simply do not want to do their job does not in any way affect the results of his work, because the deadlines for tasks are in fat and all these activities are not justification of their violation.





  2. When applying for a job, lie about what the programmer will do. Talk about ultra-modern technologies and promise that 70% of the programmer's time will be spent on development. It is not at all necessary to fulfill promises, who cares that in fact you have a monolithic legacy there, part of which was written in the last century.





  3. Distribute tasks on modern technologies and development only to programmers from neighboring departments who have no idea what is happening in your system. Yes, you heard right: the tasks of developing the system should be performed by people minimally familiar with this system. The programmers in your department should only deal with bugs. Aerobatics - if your programmers will rake the Augean stables during working hours and write new code on weekends. Well, what, they are developing their skills, why should this be done at the expense of the bank?





  4. When you change working conditions ("to remotely" translate, introduce strict working hours or something like that) - do not bother to pretend that the programmer has the right to vote. Just pretend that your word is enough for any change. If some disloyal cadres dare to "be against" - hint that problems await them: "we will put all the dissatisfied on a pencil. Thank you for not planting it. If someone becomes insolent to such an extent as to directly point out the legal inconsistency of your actions, just ignore it: it will look as if you have not deigned to answer, and the case is unlikely to come to court.





  5. If you don't like some programmer, dismiss him. It is possible for a failure to appear at the office. You can even in the middle of a coronavirus quarantine.





  6. , - . , , , , . , , , - ,





  7. - : . .





  8. - " ". -? ? : , - : " - ".





  9. : - " ". " -". , ( ), .





  10. , : , , - - . .





  11. - , . , 15 , .





  12. - , . . - - . , .





  13. - . . , , .





  14. . . , .





  15. , 1 - . , , , . . - , . , . .





  16. : : , , . , , . .





  17. . ? ! , , . ? ? , : , .





  18. More about working time: it was created for bugs and disputable cases. It is better to schedule organizational meetings after the end of the working day, because otherwise we will not have time to release the release. Let all personal matters be decided outside of working hours. You know better when working hours are over.





  19. The law at work is your word. If there are any alternative pieces of paper that claim this proud name (non-working days, labor code, quarantine measures) - feel free to ignore it. If it is not clear who, and not you, set the rules - what kind of boss are you?












All Articles