Last week, I wrote an article, Top 10 Things You Should Never Say To Your Boss. This week, I am writing the other side of the coin and focusing on the team owners and what they should not say to their developers.

I've been working in the software industry for 17 years. Most of the points discussed here are based on my personal experience. The article is written for business owners, project owners, technical managers, team leaders and seniors who manage a team of developers.

One thing worth mentioning is that most bosses have bosses. If an employee is trying to do something that is in the best interests of the boss's employer it is actually the boss that should obey the employee. That is of course an over-simplification; it is a general concept, not a rule.


Here is a list of my things not to say to a developer.

    I don't have time for this.

    So you're busy and you really don't have time for your developer. I suggest you find some time. By not giving time enough to your developer, you're actually hurting the project and hence yourself.

    There are many possible solutions. A really good boss is creative, flexible and open to alternatives. One solution is to get it in writing and when you do, give it the attention it deserves. It could be that a developer has already tried to communicate in writing. If so and you tell them you do not have time then that leaves the employee without a reasonable solution. The problem might be personal or the problem might be a problem for the company, either way ignoring it has consequences.

      Just do it the way I like it

      Coding is not food. Your taste does not matter as long as the developer is doing his/her job. These days, the technology and features are being released rapidly. You should encourage your developers to adapt the latest features, trends and technologies that benefit the organization and project. It is your responsibility to know what is best and that is not easy to do. You need to analyze the costs and benefits of the latest features, trends and technologies. It is reasonable to restrain developers from using something just because it is new but it can also be a mistake to avoid converting to something new. The longer you delay implementing something new, the more it could cost to do the conversion.

      One of my long time clients asked me to review one of his projects. I met the architect and the tech lead of the project and started the code review. The project was developed using .NET 4.5 and Visual Studio 2013 but what I saw was the developers still using coding that complied with .NET 1.1 and 2.0. I questioned the architect and he replied, this is the way like it. We've been doing this for a long time. It is easy to understand. The problem is that the longer they delay developing code using the latest capabilities, the more it will cost to convert when it becomes necessary.

        Just leave it. I will do it.

        In my early days, I made this mistake myself. Sometimes to move things faster, you end up doing it yourself. I suggest you stop that. To scare your development and grow your organization and team, you must know how to train your developers. I know it can be very frustrating from time to time but for the long run, it will actually help you.

        One of the key attributes of a good leader is an ability to create his/her own replacement. In software development, as a project owner, you must consider “what if”. What if I am sick tomorrow?

        We use computers to do as much of the detailed work as possible. The philosophy is that it frees us to do the things that computers cannot do. You need to delegate to your employees everything they can do so it frees you to do the things that they cannot.

        Also avoid keeping the fun stuff for you to do yourself. Employees are likely to resent that.

          You're taking too much time

          You must determine why a developer is taking more time than your expectations. There must be a valid reason behind it. If the developer is not skilled, it is your job to find a replacement. If a developer is not motivated, it is your job to figure out why. Again, it all falls on you. All of that can of course be difficult to do. It is easy to avoid doing it. A common way to avoid doing it is to blame the developer for not getting the work done on time and when that is done to avoid finding problems, there are consequences.

          Your projects will proceed much more smoothly if you are realistic about the time required. Setting unrealistic deadlines might get the work done on time but end up being very costly later. Employers need to attempt to employ developers that are able to make reasonable estimates that can be relied on. If however a deadline is used because the employer thinks the employee is not productive then that is a problem. The ideal is to have a trustworthy employee that is trusted.

          One suggestion is to maintain a record of estimates compared to actual times, especially if that is done for many developers and many projects. There are software systems and other methodologies available to help get other opinions of time estimates.

            He can do faster than you

            Everybody has their own pace. Everybody has their own strengths and weaknesses. Some people are fast and some are perfectionists. Some are slow but workhorses. When you hire a new employee, it is your job to determine their pace and skills and maximize what they are capable of.

            Be careful about judging an employee as being faster if they only seem faster because they put in more hours. Longer hours might seem to be an advantage but it is not necessarily an advantage. If for example a developer actually puts in more hours to get something done faster then it might be a symptom of carelessness if they must do a lot of testing. An extended amount of time spent testing could result in costlier maintenance in the future if the testing begins with buggier code. It is your responsibility to determine what applies.

              Do it now

              Yes it is very difficult not to say this. Trust me, I've been a developer. I have worked under projects. I have managed teams and projects and now I am managing companies. There are many times, I want things now.

              But I know, I am wrong. Sometimes things can't be done now.

              Think of it in terms of the amount of time spent switching gears from one thing to another. You should assume that asking a developer to do something that takes 10 minutes will take an hour away from something else. That is not a problem if it is done once and/or when it is important enough but the cost could accumulate if done carelessly.

                Can you use a template or this is really simple

                Oh, this one pisses me off. This does not apply to a technical person. This usually comes from amateur business owners who do not understand software at all. I hear this a lot from non-technical business owners.

                Oh yea, if it's that simple, why can't you do it yourself?

                  A student can do it

                  You've just not only insultated your developer, but you've also demoralized him/her. Reality is, no a student can't do it. That's why you hired an experienced developer and pay lot more than you would pay a student.

                    Summary

                    In this article, I talked about some things you should not say to a developer. I am sure you have your own list. I would like to get your feedback and your items that you don't want your boss or other people to say.

                    Authors: Mahesh Chand and Sam Hobbs