Almost each big or small company today hires software developers and other IT specialists as full-time employees to work on internal or custom development projects. Teamwork is a very responsible yet challenging activity because people should be in charge of both their own and their teammates' success. For teamwork to be effective, regular communication among team members and shared vision of the project goals are critical. And politeness and mutual respect are key to successful communication.
However, there's a list of phrases that product owners, clients and team leaders shouldn't use in their daily communication with software developers and QA engineers regardless of how correct and polite they may sound.
Having talked to Intersog software engineers and PMs, we've compiled a list of 10 things not to tell your IT staff. Here you go:
1. "Can you finish testing it as soon as possible?"
To be really effective, software testing should be perceived as a well thought-over and thought-out function within your software development. Proper testing is key to a quality software product and "haste makes waste" is the rule of thumb here! Whereas there're many online tutorials about how to speed up testing, in practice it's not that easy. Even test automation should be maintained, revisited and modified on a regular basis.
In the best case scenario, your testing should cover an entire software development lifecycle, from product design to final release, and your developers should collaborate with testers to attain the best result.
Create test plans, stick to / review and modify them, but never hurry your tester when the project is in full swing and they need to focus on details not to miss critical errors and bugs that will cost you overhead at the post-production stage.
2. "I've no time to read your bug report, can you describe an issue in a nutshell?"
Good QA engineers and testers spend a lot of their time and efforts creating comprehensive bug reports that provide issue details and describe steps that lead to an error. When you, as a product owner, PM or team lead, neglect or depreciate bug reports, you show to your employee that 1) you don't really care about their work quality, and 2) you don't appreciate such qualities as professionalism, attentiveness, dedication to project success, etc.
Believe it or not, but you won't keep your staff motivated and happy if you constantly ignore their deliverables.
Bottomline: always read your testers' bug reports!
3. "Can you promise there're no bugs here?"
Tester's role is NOT to control app quality, but to help developers bring a quality software product to market. As such, their ultimate goal is to make sure the product fully meets project requirements and client's expectations. As they say, "do more, promise less". Testers shouldn't verify you have a 100% clean code or bugs-free app; they should rather focus on the quality of tests being performed. So, leave them alone and don't make them promise anything.
Bottomline: You better employ a test-driven development (TDD) to eliminate false promises.
4. "Skip it for now, I'll do it later"
That's one of the most common mistakes made by team / tech leads who want to accelerate the process and, thus, take things into own hands without waiting for developers to complete their task. We recommend you stop doing this! Rather, you should act as a mentor and make sure your software developers become more professionals and mature within your organization. At first, this approach may seem uncozy, but it'll pay off well in the mid to long term, be assured!
Bottomline: the more interesting and challenging tasks you assign to your team members, the more they'll respect you as a leader!
5. "I'm going home" (pertaining to a PM)
In a nutshell, PM's key goal is to oversee the project and make sure everything goes according to the plan. When the process stumbles into errors and inconsistencies, employees feel discouraged and unmotivated and start shifting blame on each other. That's very detrimental for any software project, and that's when PM should step in to handle issues and improve team morale.
PMs should be very collaborative and should tend to spend as much time with their team as possible. When developers work overtime to get project things done on time, PM should stay, too!
Bottomline: unity is key to team success, so don't leave your team out in the blue!
6. "I haven't seen you writing code for a long time"
Programming doesn't declare how much time should be spent on writing code. A developer who's just written a new function can go for hours re-thinking and reframing it. Therefore, if you don't see you developer coding, it doesn't necessarily mean he's not busy at the moment. He may be doing research or asking other developers about issue resolution.
Bottomline: evaluate your team members by their individual contribution to project success and ability to use non-trivial approaches to problem solving rather than time they spend on coding.
7. "It's a super easy task, just use a template"
Having assigned a "super easy task" to your developer, you can put yourself at risk of paying overhead at a later stage. Based on our experience at Intersog, we can say with confidence that developers hate it when client or PM assesses their task complexity based on their gut feeling or subjective experience. What irritates them even more is that sometimes PMs aren't proficient enough in software development to impose their viewpoints or assessments.
In general, try to avoid such phrases when you assess a task and confide more in your staff. When a developer says something like: "It's an easy-peasy task, it shouldn't take more than an hour...", the chance is high the task will be completed fast. However, if PM or client says something like this, it may lead to misunderstanding and resentment.
Bottomline: by assessing a task as super easy, you initially question and depreciate your IT staff competence. Is it really what you want?
8. "Take a look here, it's urgent!"
The way programmers work resembles that of an artist. Just like an artist, they're focusing on their creation (code) and keeping in mind a very complex picture. When you interrupt their reflections and contemplation with something "urgent", they literally get off track. According to studies, it takes an average person 15 minutes or more to get their attention back after distraction, so interruption can be destructive for your team!
Read our article about how to work in interrupt-driven teams!
PMs or tech leaders should plan their work so that they assign tasks in the morning and get result in the evening without interrupting a team in the middle of the day and letting each team member work in own tempo.
Bottomline: Make sure to eliminate all other irritating factors from your team space (e.g. small talks, loud music, noise from PCs, etc) to increase productivity and keep a healthy atmosphere inside team.
9. "No need to re-factor, we need to deliver today!"
The more kludges in code, the less developers want to work with it. Especially when they're not allowed to re-factor it. If you don't keep your code base clean, it becomes so dirty that you won't be able to make any change without using hacks and workarounds. This is the first step to project failure!
Coding is like playing jenga when players take turns removing one block at a time from a tower comprised of 54 blocks. Each block removed is then balanced on top of the tower, creating a progressively taller but less stable structure. To keep your tower stable, you need time to make a change in its structure.
Bottomline: Allocate one day a week for code re-factoring by your team, otherwise you'll have to re-write code from scratch some day in the future.
10. "He'd do it faster than you!"
Each of us has own work speed as well as strengths and weaknesses. Someone can fulfill tasks quickly, while the others may need more time to complete their assignments. However, in software development speed can mean opposite to quality.
We recommend you pay attention not to task completion speed, but to how each team member can correctly assess time needed to complete this task.
Bottomline: what really matters is how objective your developers are when evaluating own capabilities.
