"Friday format": How to extinguish the flame or 8 sure ways to ruin the development
Being a technical team leader is certainly a huge responsibility. Directing professionals in the right direction, you can create truly brilliant things. With the same success they can be destroyed in the bud. About this our material further.
/ photo by Bureau of Land Management CC
Even the most prominent idealists in top positions face a lack of resources, deadlines and bosses requiring predictable schedules and results. In such conditions, the focus shifts from the needs and moods of subordinates to short-term tasks. Meanwhile, success in IT depends primarily on people and ideas, and afterwards - on technology. According to IBM Systems Magazine, 54% of IT project failures are management-related and only 3% are related to technical issues.
')
Even people who try on the role of project manager agree with this. For example, Amr Noaman Abdel-Hamid (Amr Noaman Abdel-Hamid) in 2003 occupied a leadership position at IBM due to his experience in the company and technical training. However, he himself does not consider this decision to be a good one, since in his personal hierarchy the ability to motivate the team is in the first place among the qualities necessary for a project manager.
Someone will say that high pay is enough to incite enthusiasm. But in October 2012, renowned economist Dan Ariely (Dan Ariely) within the framework of TEDTalk stated that money as an exhaustive motivator for achieving an ideal working capacity is too simplified. Ariely oversaw a group of engineers at a Seattle company who was asked to implement a large project. He was for them not just a job, but an interesting challenge.
After two years of development, the manager suddenly told the staff that the project was canceled. Despite the fact that when the team members remained the same level of pay and position, they became disheartened. Ariely discovered that they stopped working as hard as they had before. In addition, the team started late, and no one wanted to stay at work.
This example says one thing: although generous material compensation is a necessary part of a professional’s workflow, it alone is not enough.
So, the project is waiting for implementation. Although the minimum requirements have not yet been developed, the time has come to hire developers. Let them still sit and guess what you need from them, and you call it a flexible development methodology.
The Geneca study found that only 55% of managers clearly understand the business goals of their projects. Others make decisions at random and make their subordinates suffer, because the development time is no longer realistic.
At the final stage of the project, when all the problems were on the surface, from the lips of decision makers, you can often hear: "We needed more time to spend on planning." The lack of a plan will surely result in chaos, which will not be ignored by subordinates. When the leader begins to rush from one task to another, change decisions and focuses on various aspects, the motivation will start to die out sharply.
Therefore, before starting the project you need to make sure that the goals are clearly set and agreed with the main stakeholders. Financial planning, overall expectations and objectives depend on it. The larger the project, the more valuable becomes the formal and clear presentation of information.
The quality of work affects only the competence and speed of execution, right? In an ideal world, perhaps, this is true, but in reality personal qualities affect the result of work.
Yes, you can open a fresh report Stack Overflow and make an impression about what the developer should be. Here you can find averaged data on age, education, experience and other impersonal information. However, when it comes to work, it all loses its meaning.
Andrea Goulet, head of the IT company Corgibytes, believes that software development is replete with stereotypes. One of them is that all developers love to rewrite code from scratch, and not to make changes to the existing one. In fact, there are two types of professionals: “makers”, who prefer to work with “empty canvas”, and “manders”, picking up the project at the MVP stage and working on security, scalability, performance, error correction and improved functions. This is a well-coordinated tandem, on which effective teamwork is built.
The success of the project and the company depends entirely on the personal qualities of the developers. According to Andrea, the key to managing a team is the motivation of employees, depending on their approach to work. Makers are similar to rabbits - they accelerate at short distances. Manders have more in common with slow and power turtles. All this should be taken into account by the supervisor and in time to catch the work model of the subordinate. We need a prototype - it's time to turn to the creators. There was a problem - manders will understand. Do not neglect the study of characters. Developers are not universal soldiers, and misunderstanding of this fact may be wasted resources.
Why on earth would you care about making a developer’s life easier? Is someone trying to simplify the work of the project manager? However, it is the project manager that should establish communication and simplify the interaction between the development department and other employees.
Bridges between departments are convenient tools that allow people of different professions to speak the same language. There are many solutions in all important industries. For example, Moqups and InVision help designers to collaborate on layouts, GitHub and Bitbucket allow developers to coordinate collaboration on code. If you do not take care of removing the barriers between team members and developing a standardized set of tools, problems will only pile up.
There is a good idea: hire really talented people, and then “stifle” their interest, motivation, and with them efficiency in a thousand trifles - make them generate reports after each new line of code, read in each sentence. Yes, and do not forget to force employees to request permission for each new line of code. And let every morning on your desk will be a list of the developer's tasks scheduled for the day with details of up to a minute.
This approach is called micromanagement. The goal of this strategy is to minimize the ability of talented employees to work independently of the manager. It works great if you intend to turn developers into weak-willed zombies, and is destructive for a creative environment.
Are you annoyed too, that developers sometimes spend time learning new languages, tools and frameworks? They want to participate in conferences and get access to paid courses, while your work is in full swing.
Everything would be fine, but according to go2HR, in 40% of cases of lack of training, employees leave within the first year.
Subordinates who can do absolutely everything and automatically receive up-to-date information during sleep are the utopian dream of a project manager. In reality, developers want to improve. And this is good for two reasons: firstly, the desire for knowledge characterizes the employee as a person well, and secondly, the needs of the team may change at different stages of product development, and the multi-functional developer will have to be here at the time. It is important to take into account the decrease in efficiency during training, which is compensated by new team skills. The professional development of employees not only benefits the student, but also the entire company.
There is nothing reprehensible in engaging a third party expert in the development process. But some project managers have a bad habit of giving external consultants a central role, downplaying their own subordinates.
As a rule, on the side of a specialist from the outside are training and experience, against which the merits of their own developers pale. Often, the consultant pursues his own interests and puts them above client. These people are extremely convincing, which is why in English they are even called dazzlers - blinding.
It happens that the magic glow is not really supported by solid knowledge, but the charm of the “expert” does not allow the manager to think soberly. In such a situation, developers quickly understand what is happening and lose their motivation, because their value and knowledge has been questioned. Having blindly trusted an external consultant, the project manager risks being left alone with the collapsed product.
Therefore, it is important to objectively assess the competence of the involved party, strictly delineate the areas of responsibility and set specific KPIs.
As is the case with an external consultant, this is a question of priorities. Developers will retain motivation if they feel that their leader is on one side with them.
Project managers must ensure project implementation. Sometimes this implies a refusal to make unnecessary functions and edits. If a manager agrees to everything without thinking about how his subordinates will cope with new and unreasonable tasks, faith in the team leader will be dispelled, and frustration will take its place.
If you catch yourself thinking that the clock is already twelve, and you and your team have been discussing the results of the previous meeting for an hour, something is clearly going wrong.
As renowned economist John Kenneth Galbraith once said, “meetings are necessary when you don’t want to do anything.” With regard to the development of this is not entirely fair, because here the whole focus lies in competent coordination. There is nothing wrong with the discussions themselves. They strengthen the team, allow all team members to understand at what stage of the project you are. But, as with micromanagement, it is important not to bend the stick.
Too many meetings on minor occasions is a bad sign for the staff. Frank Kelly (Frank Kelly), a tmlid in Nokia, believes that, ideally, developers should be able to independently establish communication with each other, and meetings should not be compulsory.
In a 2012 Industry Week survey, executives admitted that at least 30% of the time spent at meetings was wasted. Therefore, it is important to develop a uniform meeting schedule for your team. For example, you should agree on the maximum duration of a meeting or that discussions begin, even if someone is late. Invite less people to one meeting - efficiency decreases with an increase in the number of participants. Control discussions, agree not to use gadgets, announce the mitap agenda in advance so that all participants are prepared. Most importantly, do not “torment” subordinates with discussions for minor reasons. This not only reduces the effectiveness, but also affects the team spirit.
PS IaaS-digest: 30 materials on working with PD and high performance.
PPS A couple of links on our profile topics from the corporate IaaS blog:
/ photo by Bureau of Land Management CCEven the most prominent idealists in top positions face a lack of resources, deadlines and bosses requiring predictable schedules and results. In such conditions, the focus shifts from the needs and moods of subordinates to short-term tasks. Meanwhile, success in IT depends primarily on people and ideas, and afterwards - on technology. According to IBM Systems Magazine, 54% of IT project failures are management-related and only 3% are related to technical issues.
')
Even people who try on the role of project manager agree with this. For example, Amr Noaman Abdel-Hamid (Amr Noaman Abdel-Hamid) in 2003 occupied a leadership position at IBM due to his experience in the company and technical training. However, he himself does not consider this decision to be a good one, since in his personal hierarchy the ability to motivate the team is in the first place among the qualities necessary for a project manager.
Someone will say that high pay is enough to incite enthusiasm. But in October 2012, renowned economist Dan Ariely (Dan Ariely) within the framework of TEDTalk stated that money as an exhaustive motivator for achieving an ideal working capacity is too simplified. Ariely oversaw a group of engineers at a Seattle company who was asked to implement a large project. He was for them not just a job, but an interesting challenge.
After two years of development, the manager suddenly told the staff that the project was canceled. Despite the fact that when the team members remained the same level of pay and position, they became disheartened. Ariely discovered that they stopped working as hard as they had before. In addition, the team started late, and no one wanted to stay at work.
This example says one thing: although generous material compensation is a necessary part of a professional’s workflow, it alone is not enough.
The internal fire of the developers can go out at the behest of the wrong management decision and never flare up. In today's article, we decided to talk about project management and analyze the main approaches that may affect motivation.
Forget about planning
So, the project is waiting for implementation. Although the minimum requirements have not yet been developed, the time has come to hire developers. Let them still sit and guess what you need from them, and you call it a flexible development methodology.
The Geneca study found that only 55% of managers clearly understand the business goals of their projects. Others make decisions at random and make their subordinates suffer, because the development time is no longer realistic.
At the final stage of the project, when all the problems were on the surface, from the lips of decision makers, you can often hear: "We needed more time to spend on planning." The lack of a plan will surely result in chaos, which will not be ignored by subordinates. When the leader begins to rush from one task to another, change decisions and focuses on various aspects, the motivation will start to die out sharply.
Therefore, before starting the project you need to make sure that the goals are clearly set and agreed with the main stakeholders. Financial planning, overall expectations and objectives depend on it. The larger the project, the more valuable becomes the formal and clear presentation of information.
One size fits all
The quality of work affects only the competence and speed of execution, right? In an ideal world, perhaps, this is true, but in reality personal qualities affect the result of work.
Yes, you can open a fresh report Stack Overflow and make an impression about what the developer should be. Here you can find averaged data on age, education, experience and other impersonal information. However, when it comes to work, it all loses its meaning.
Andrea Goulet, head of the IT company Corgibytes, believes that software development is replete with stereotypes. One of them is that all developers love to rewrite code from scratch, and not to make changes to the existing one. In fact, there are two types of professionals: “makers”, who prefer to work with “empty canvas”, and “manders”, picking up the project at the MVP stage and working on security, scalability, performance, error correction and improved functions. This is a well-coordinated tandem, on which effective teamwork is built.
The success of the project and the company depends entirely on the personal qualities of the developers. According to Andrea, the key to managing a team is the motivation of employees, depending on their approach to work. Makers are similar to rabbits - they accelerate at short distances. Manders have more in common with slow and power turtles. All this should be taken into account by the supervisor and in time to catch the work model of the subordinate. We need a prototype - it's time to turn to the creators. There was a problem - manders will understand. Do not neglect the study of characters. Developers are not universal soldiers, and misunderstanding of this fact may be wasted resources.
Convenient tools are not needed
Why on earth would you care about making a developer’s life easier? Is someone trying to simplify the work of the project manager? However, it is the project manager that should establish communication and simplify the interaction between the development department and other employees.
Bridges between departments are convenient tools that allow people of different professions to speak the same language. There are many solutions in all important industries. For example, Moqups and InVision help designers to collaborate on layouts, GitHub and Bitbucket allow developers to coordinate collaboration on code. If you do not take care of removing the barriers between team members and developing a standardized set of tools, problems will only pile up.
Focus on the little things
There is a good idea: hire really talented people, and then “stifle” their interest, motivation, and with them efficiency in a thousand trifles - make them generate reports after each new line of code, read in each sentence. Yes, and do not forget to force employees to request permission for each new line of code. And let every morning on your desk will be a list of the developer's tasks scheduled for the day with details of up to a minute.
This approach is called micromanagement. The goal of this strategy is to minimize the ability of talented employees to work independently of the manager. It works great if you intend to turn developers into weak-willed zombies, and is destructive for a creative environment.
Need to work, not learn
Are you annoyed too, that developers sometimes spend time learning new languages, tools and frameworks? They want to participate in conferences and get access to paid courses, while your work is in full swing.
Everything would be fine, but according to go2HR, in 40% of cases of lack of training, employees leave within the first year.
Subordinates who can do absolutely everything and automatically receive up-to-date information during sleep are the utopian dream of a project manager. In reality, developers want to improve. And this is good for two reasons: firstly, the desire for knowledge characterizes the employee as a person well, and secondly, the needs of the team may change at different stages of product development, and the multi-functional developer will have to be here at the time. It is important to take into account the decrease in efficiency during training, which is compensated by new team skills. The professional development of employees not only benefits the student, but also the entire company.
The consultant will figure everything out
There is nothing reprehensible in engaging a third party expert in the development process. But some project managers have a bad habit of giving external consultants a central role, downplaying their own subordinates.
As a rule, on the side of a specialist from the outside are training and experience, against which the merits of their own developers pale. Often, the consultant pursues his own interests and puts them above client. These people are extremely convincing, which is why in English they are even called dazzlers - blinding.
It happens that the magic glow is not really supported by solid knowledge, but the charm of the “expert” does not allow the manager to think soberly. In such a situation, developers quickly understand what is happening and lose their motivation, because their value and knowledge has been questioned. Having blindly trusted an external consultant, the project manager risks being left alone with the collapsed product.
Therefore, it is important to objectively assess the competence of the involved party, strictly delineate the areas of responsibility and set specific KPIs.
The customer is always right
As is the case with an external consultant, this is a question of priorities. Developers will retain motivation if they feel that their leader is on one side with them.
Project managers must ensure project implementation. Sometimes this implies a refusal to make unnecessary functions and edits. If a manager agrees to everything without thinking about how his subordinates will cope with new and unreasonable tasks, faith in the team leader will be dispelled, and frustration will take its place.
Need more meetings
If you catch yourself thinking that the clock is already twelve, and you and your team have been discussing the results of the previous meeting for an hour, something is clearly going wrong.
As renowned economist John Kenneth Galbraith once said, “meetings are necessary when you don’t want to do anything.” With regard to the development of this is not entirely fair, because here the whole focus lies in competent coordination. There is nothing wrong with the discussions themselves. They strengthen the team, allow all team members to understand at what stage of the project you are. But, as with micromanagement, it is important not to bend the stick.
Too many meetings on minor occasions is a bad sign for the staff. Frank Kelly (Frank Kelly), a tmlid in Nokia, believes that, ideally, developers should be able to independently establish communication with each other, and meetings should not be compulsory.
In a 2012 Industry Week survey, executives admitted that at least 30% of the time spent at meetings was wasted. Therefore, it is important to develop a uniform meeting schedule for your team. For example, you should agree on the maximum duration of a meeting or that discussions begin, even if someone is late. Invite less people to one meeting - efficiency decreases with an increase in the number of participants. Control discussions, agree not to use gadgets, announce the mitap agenda in advance so that all participants are prepared. Most importantly, do not “torment” subordinates with discussions for minor reasons. This not only reduces the effectiveness, but also affects the team spirit.
PS IaaS-digest: 30 materials on working with PD and high performance.
PPS A couple of links on our profile topics from the corporate IaaS blog:
Source: https://habr.com/ru/post/333690/
All Articles