Silent software development crisis

About me

I have been working in software development for 28 years. My current position is Senior Software Development Director of a consulting company in Austin, Texas. I have been working in this position for a little over six years.

My height was initially of a technical nature - I started as a software analyst as soon as I graduated from college. One of my favorite hobbies in those days was ridiculing the stupidity of management. Only later did I discover my management abilities and realized that I really liked it.
')
A rather cruel kind of karma works in the universe.

In my current position as senior director of software development, I have 6 development managers who report to me. Only in my organization about 50 software developers. We have an enviable low turnover and a very high level of customer satisfaction.

Over the years I have shared with my subordinates and their immediate subordinates the same conclusions that I am going to share with you now. These conclusions are the gained wisdom, and not what I intuitively knew or read. That is, I learned this by going through a difficult path.

Publication support is Edison , which has developed a system for calculating road traffic at intersections and an application for the exchange of taxi orders .

I share this with you, because over the past ten to fifteen years I have noticed a quiet crisis unfolding in the field of software development, which leads to a decrease in the quality of applications, dissatisfied employees, and dissatisfied users.

Almost all is to blame for bad management, or it may be better called fancy management. In the past, I was just as guilty as everything, until I discovered and perfected a basic set of methods that, for the most part, lead to everything falling into place - at least in my experience. No promises. Go!

Be careful with high scores.

Of course, you decided that some of the developers on your team are great performers. These are usually those developers who work fast. Managers usually choose and prefer these developers for projects.

In fact, there are very few excellent performers and they are extremely rare. Most likely you do not have them. You may think that there is and you will be greatly mistaken.

I bet that your excellent performers achieve such results of productivity through technical debt in the application, intentionally or unintentionally. They save time on the design and architecture of things at different levels (from low to high — objects and hierarchies of carriers, changes to the database schema, etc.), the lack of adequate testing and the development of code that is difficult to read, maintain and extend.

Such high-performing artists actually have very poor productivity, given the calculation of the total cost of ownership. But if this is a startup, where time to market has the highest priority, then pay attention to the aforementioned artists, just keep a close eye on the design and code.

If the work on the design and code is not very interactive, with a lot of questions and recommendations, it means that your employees do not take them seriously or are too shy to tell you about it. Very often, one or two developers are interested in this project, but without obvious interest and looking at the rest of the team, even interested developers would prefer to significantly limit their questions and recommendations.

With proper control and guidance, in the long run, the so-called high-performing artists will become better and happier. The overall performance of your team will accelerate and improve.

Encourage continued product improvement.

No matter how hard you try, technical debt will accumulate: features are added to the application with disgusting consequences, high-priority bugs are quickly patched by a govnokod, management operates with unrealistic deadlines, requirements change - we all went through it.

Stimulate developers to improve the application while they are working on their projects. Examples of improvements are creating objects for reuse from copied and pasted code and breaking large objects that are difficult to maintain into smaller objects that are easier to work with separately. Improve the database schema, even if it is rather difficult to do in the shortest possible time. Delete old and unnecessary code. Update the user interface to improve the user experience - sometimes even just changing a few words will notice a big difference.

Developers who are used to continually improving and perfecting things usually become happier developers, as continuous improvement gives them autonomy and a strong sense of self-worth. Do not underestimate the importance of morale.

When the tendency to continuous improvement becomes part of your team's DNA, the results will amaze you. But allow time for them to manifest, it will not happen overnight. This also means that management needs to recognize that this will take more time, as the developers will work on their major projects and in parallel make gradual improvements.

Continuous improvement is not an independent project. If you make it so, then you will eventually find a reason to completely abandon it, because it affects the timing. This should be something that developers will be asked to do while they do their normal activities. This is not like compound interest. Continuous improvement will eventually grow into amazing results.

Encourage code ownership

Not surprisingly, management likes to reduce risk, treating developers as interchangeable widgets. It is usually expected that developers are familiar with all points of the code. This reduces pain when a developer leaves a team or company.

This is a false economy. Your employees like working for you - right? - it means that the turnover should be low. Not taking into account the fact that developers can leave means to consider a non-standard scenario of probable events. To achieve better results, you need to consider a standard script.

Optimizing for a common scenario means that developers need to be given basic ownership of parts of the code base and not allow other developers to change this code without the approval of the owner. This leads to higher productivity, since any developer is likely to be familiar with the code with which he usually works.

It will also help you identify developers that deserve special attention. Some developers produce more bugs just as some carpenters produce substandard kitchen cabinets. For example, if the developer has the basic ownership of the user interface, and you find an unusually large number of bugs, it will immediately be clear what you, as a manager, should pay special attention to and perhaps take action.

Recognize Leaders

You will easily notice that some of your developers are more active than others in discussions, have more team members to whom they can turn for help or advice than others and are more often invited to design meetings, even if they do not work in this project. .

These developers are your true leaders. His or her colleagues have already done the hard work of identifying real leaders for you. These leaders must be recognized as such and require special consideration.

First of all, remember that it is difficult and time consuming to be both a software developer and a leader. Software development requires concentration — a concentration that is easily lost after one question or ten minutes at the blackboard. Returning to the right mood after that is problematic. Expect your leaders to take more time to complete their projects - in the end, they do two jobs at once.

These leaders should also be publicly recognized as such. They need to be encouraged for the work they are already doing. This makes it easier for them to help other developers without offense - this is now part of their official description of the profession! - and it provides recognition for them, and this raises morale. Without this official recognition, assistance may often seem to them to be simply an undesirable burden. Do not let this happen.

Most companies have large overlays in compensation in such positions as a senior programmer and lead software developer, so there is too little financial motivation to deny these promotions. Do not force your (often shy) true leaders to ask for a promotion - just do it. The icing on the cake is for you - as their manager you will receive in return loyalty and devotion.

Watch out for false scorecards

Do you count the number of jobs that each individual employee performed? View these calculations to be freely available to all software developers? Even worse: do top management have access to this data? Stop doing it immediately.

Software developers are not so stupid, and some of them will quickly learn how to beat the system if counterproductive incentives are visible. Anyway, all work will come down to achieving the highest amount of work done.

If work unit counting is part of your daily or weekly meetings, some developers will learn to solve simple questions in order to inflate your account. Software developers who dig in to more difficult tasks that take longer will morale consciously or unconsciously. This has a bad effect on the team and productivity.

It is even worse when error corrections are included in these calculations, when these errors are corrected by software developers, who themselves made them initially.

For example, consider the project of developer # 1, which will probably be completed in 10 days without errors (or with a small number of errors) and the project of developer # 2, which will probably be completed in 5 days, but in the end, 4 errors will be detected in it and fixing each will take 2 days. And all this without regard to additional support costs and negative customer experience as a result of these errors.

In this case, developer # 1 did only one job in 10 days, and developer # 2 five (the project itself + fixing 4 errors) in 13 days. Which one is more productive? Your scorecard obviously lies to you. Do not trust her and in no case do not advertise it.

Interrupt limit

Some employees are not aware of the impact that they have on other team members and often distract them from work with one quick question or worse. Encourage your team to communicate in such a way that breaks are minimized: email, chat (if your team does not use chat, then they should start), instant messages, phone calls.

In addition, one of the principled positions that managers must take, regardless of whether they understand it or not, is defense (to take a hit). External people must first talk to you, the manager, and then you decide which team you can include in the work and when.

Recommendations regarding restricting interruptions are softer than previous ones, since there is a fine line between intractability and a reduction in the number of employees who distract others.

Prefer individual jobs

We all have seen photos of open offices where software developers cannot get over and most of them are sitting in headphones in a miserable attempt to somehow concentrate.

Despite the fact that there is not a single scientific proof that open offices are a good idea and there is irrefutable evidence that they impair the productivity of most software developers, for some reason they are now widespread and popular. Software developers need personal space. Sound and visual distractions should be minimized, which means at least every developer should have a cabin with high walls and a small entrance - but large enough to meet the safety requirements, of course.

Sometimes there is a project in which close cooperation is required. Most offices have conference rooms that can be temporarily converted to open office spaces.

Encourage experiments

We all heard about the famous 20% of the time Google, thanks to which Gmail became possible, and it all grew into a successful online application development business.
While most companies do not have huge financial resources to actually implement a 20% policy, experiments, however, should be encouraged and supported periodically. Software developers are not devoid of good ideas and have special experience, and, accordingly, they have a good sense of application that can be improved and expanded.

By giving them the freedom to act, so that they periodically carry out research and development, you can get unexpectedly high dividends, as well as significantly improve the team's mood. It is also a good way to help managers identify true leaders who have taken the time to evaluate and consider more effective solutions for different requirements. This does not mean that software developers who prefer to work at work and relax at home are not worthy of contributors - but pay special attention to those developers who think they can know the best way to implement something or may have thought about what customers might like.

Allow staff to leave

If an employee approaches you and asks you to move from one group to another, graciously let them do it. This does not mean that you should allow them to leave in the middle of a crisis time, but as a rule, if they want to leave the group, then something did not work out, and you should allow them to transfer, even if they have not been in the group for a very long time - let's say less than one year.

Forcing employees to stay in the group, you will never achieve anything good. This will affect their morale, which affects the morale of the whole group. It is also likely that they will work less efficiently and, in the end, simply leave the company. Any manager who does not allow his employees to leave, did not understand at all how to produce the best balance of happiness and productivity of his employees, and this is a beginner’s mistake, which too often even experienced managers make.

Never reject small requests.

Your employee wants a bigger monitor? Buy it. Do they want a specific keyboard? Buy it. Do they want to work from home every Wednesday and is this their personal requirement? Allow Do they want a Mac instead of a PC? Give it to them.

Even if they have a constant flow of requests that never seems to end, never say no to them, except for one thing: if you are sure that the entire company will have this small request and this will really affect the budget too much. Compared to salaries and bonuses, the implementation of their small requests will maintain their morale and increase their productivity, and a penny is worth it. If you do not have a budget for such requests, it is time to start looking for work in another company, because the middle and top management has become useless. If you have refused a small request recently, return to the employee and tell him that you changed your mind.

Cancel annual and semi-annual reports

Your employees do not have to wait six to twelve months to find out that you think they have succeeded in something and that they have to work on it. Communication between managers and employees should be like a river that never stops flowing. Too many companies are still stuck in the past with their harmful and unproductive periodic reports. Some reports even sometimes require expert assessments. As a result, employees secretly team up to provide each other with good feedback — or employees who don’t like each other will blame each other. In any case, the results will be completely useless and cause only harm. Communication between the manager and the employee should not occur during these artificial, mandatory, face-to-face meetings — which usually occur weekly or twice a week — and become an uncomfortable requirement in cases where there is nothing to discuss. Both managers and employees should feel relatively comfortable when communication is necessary. If an employee is extremely inconvenient to start a conversation with a manager, or vice versa, this is an indicator of a very serious problem.

You are no better than your employees.

Software development is a job. Managing software development is work. The fact that your employees report to you does not mean that you are smarter or better than them. Many software developers, I dare say, most software developers like to be developers. Do not confuse and do not allow your employees to confuse management with career growth - this is just another job, even if they pay a little more for it. One of the worst things you could ever hear was that, as an employee, his career stalled because he was not promoted to a manager. There is nothing wrong with a single profession throughout life, it keeps your brain in good shape, and software development remains an outstanding career. Developers should want to get into management for one reason only - because they want it, and not because they consider it a step forward.

Do not discount younger or older developers.

Young employees do have more energy, which increases productivity. Older employees do have more experience and wisdom that increases productivity. Build a team with a variety of age and see how they bloom into something more.

All ages play an important role and the best development teams I have worked with have always had people of all ages — from twenty years old to those approaching retirement age. They perfectly complement each other. It is difficult to explain, but easy to see from a management point of view. In other words, do not allow age to play an important role in the hiring process, and you and your employees will succeed pretty soon.

Do not get stupid dress codes

As a manager, you can hardly say a lot about this, but still let your employees dress casually. Understandably, you don’t want them to go to work in pajamas or torn jeans, but a good pair of jeans and any decent shirt with a collar are fine.

Now, humanity knows that clothing does not improve the productivity or success of a company. And, of course, the only men who wear ties should be bankers or lawyers. Okay, I'm joking about that last part - a bit. Let your employees dress comfortably. For some, it will be jeans and a shirt, and for some business style. They are adults and you should let them decide.

Generalization

This can be a very long and confusing way to help you learn how to take care of your software development staff in the best possible way. If you take good care of your employees, they will take care of you, which leads to better results and higher career satisfaction for you and for them. This is basically a compilation of common sense, but I felt that it should be compiled in one place for all low-level software managers. I wish this article existed on my first day as a manager. I learned all this at work through trial and error and I cannot guarantee that it works for any team, but I tried my best and I look forward to feedback. I am sure that this article describes everything that a software manager must do on the way to success.

Translation: Diana Sheremyeva