Team member is vehemently against code formatting

Question

I am the manager of a small team of developers (5 engineers, including me).

A few months ago, on the suggestion of another colleague we introduced mandatory code formatting in the code base, for our main project. Our project is in Python and the formatting tool is black (not relevant, I guess).

I find value in having the same 'appearance' of the code in all the project files, for me it is part of the Quality Assurance for the whole project. Code merge requests have to be formatted with the tool otherwise they cannot be added to the software.

Since then, a colleague is always complaining and expressing disagreement about this decision whenever the occasion happens.

How would you deal with such situation ?

What would you answer to "code formatting is totally bullshit", "it's like colors, some people like it red some other blue that's it", "it reduces my freedom", "it makes code more complicated to read with no added value" etc. ?

Answer 1

Honestly, my reaction would be the following:

Bob, I appreciate the feedback, but as a team we've decided that we're using Black as our mandatory code formatting tool, and that decision is final. I understand it's not your personal preference, but I'm afraid that you're going to need to learn to work with it.

But if I wanted to engage in a discussion?

"code formatting is totally bullshit"

That's not very constructive feedback, could you be more specific?

"it's like colors, some people like it red some other blue that's it"

Of course, but standardising on those "colors" is very helpful, and we had to choose one!

"it reduces my freedom"

So does agreeing to write code in the same language and version of that language, but can you imagine the chaos if we didn't?

"it makes code more complicated to read with no added value"

That's not true. After a while reading code in this format then it won't be more complicated to read at all - in fact it'll be simpler to read (added value there) because you'll only have to learn one style across the whole project. It also then means that diffs are much more readable for PRs, we can onboard other devs and get them up to speed quicker, and devs won't get hung up about what kind of formatting might look a bit prettier in a given sitaution.

To be clear, if his feedback was constructive - say of the format "I don't think Black is helpful to us for x, y and z reasons, since much of our code follows a, b c coding style which Black deals with poorly, have you considered (another tool) instead", then that's a very different scenario. That's when you should make every effort to engage in a discussion to validate his concerns, and work with him in addressing them.

Answer 2

How would you deal with such situation ?

After nicely comforting him, which you have already done, it's time to firmly tell them to deal with it. It is not an individual's code, but the company's. As a manager, you need the code to be as maintainable as possible by your team and new additions you make to the team in the future.

"code formatting is totally b***$hit"

As a coder myself, in the companies I have contributed to, some standards of formatting are enforced. As a lead developer, I would actually expect them to be a fan.

"it's like colors, some people like it red some other blue that's it"

As your manager I like red, deal with it.

"it reduces my freedom"

Code formatting does not impact freedom of creating a elegant solution. I call B.S. on this, and you should too.

"it makes code more complicated to read with no added value"

Ummmm nope. This actually makes me wonder if your lead developer is actually a lead at all....

To reiterate -- you have set a standard, as a manager or a team it matters not. The lead needs to get on board with it or perhaps move on.

Answer 3

I would try to convince him of the positive effects of uniform code formatting. Git diffs become much easier to digest when commit n and commit n+1 have the same formatting. Maintainability becomes easier, assuming the formatter enforces good practices. In the end, corporate software development is a team sport.

If your code formatter allows defining rules, ask him if there are certain rules that he dislikes and consider discussing them with your team.

Answer 4

How would you deal with such situation ?

I would try to understand the recalcitrant developers point of view. They may have good points to make that I'm ignoring.

Background and supporting experience

We implemented auto formatting on our codebase a few years ago and it caused no end of problems, partially due to the way it was introduced, but mostly due to the way it impacted our workflow. It caused so much extra work fixing merge conflicts that in the end, we turned off many aspects of the auto formatting, so it only auto-corrected things which didn't cause more problems than they solved. We also went through every setting and included only those that everyone agreed on.

One problem with auto formatting is not only does it 'standardise away' bad formatting, it also 'standardises away' good formatting.

An auto formatter can't tell the difference between a double space accidentally added, and a double space added to make an element on one line, align with an element of another line. This visual association can make it much easier to read the code, as it can be far more obvious that two things on two lines are related.

If you are going to implement auto formatting, you need the whole team to buy into it.

You need to apply the formatting globally, in a branch, and only merge in that branch once everyone has had a chance to review the effect is it has on their workflow, raise their objections and agree a way forward.

Most people would buy into automatically stripping whitespace from the ends of line, few people would want their careful manual line splits for readability to be mindlessly re-split into the incoherent mess many auto-formatting tools produce.

My suspicion is that this developer is upset because they take pride in their work, have spent a lot of time making their code as readable and maintainable as possible, and this auto reformat has destroyed all of their carefully crafted formatting.

Even though the syntax of Python already places a number of requirements on formatting, it still leaves a great deal of latitude for the individual developer.

In short. Listen to your developers objections, you may be able to improve the code base for everyone. As PEP 8 — the Style Guide for Python Code says

A Foolish Consistency is the Hobgoblin of Little Minds

It is right there at the top of the guide for a very good reason.

---

Condidering jrhs comment, occasionally people who describe programming as "more an art than a science" get laughed at, but I disagree when it comes to the soft skill aspects of coding. Programs aren't just speaking to the compiler/interpreter, they are speaking to programmers who may have to fix, enhance or maintain that code in the future.

To address VGRs comment, I don't think this is a good place to critique black. I haven't used this tool, but reading through the description I can see mostly good things there, especially for long term maintenance and diffability (the bane of complex merges).

That doesn't help if the whole team doesn't buy into using such a strict and uncompromising auto-formatting however.

Answer 5

If I owned a bakery, I may want my bakers to use a standard size of loaf. It makes it easier to buy bags for the bread, for instance. I can have a consistent price on the loaves I make.

My bakers may feel that this restricts their creativity. Some may like to make very small, or very tall loaves of bread.

Other bakers may feel that they prefer a much bigger loaf.

This doesn't mean that there aren't valid reasons for setting a standard.

However some bakers may want to point out that the loaf size I have requested will not fit in the oven. I'd be a very sensible bakery owner if I listened to those bakers.

---

Your team member is already conforming to a wide range of standards which may restrict their creativity and contradict their preferences. This comes with working on a team. This doesn't mean that you shouldn't set standards, but it's probably wise to allow and encourage constructive, non-disruptive feedback.

Answer 6

"code formatting is totally bullshit"

Even if this had a point (and it does not), black/white statements like this often hint at a very immature understanding of:

• how to deal with developer tools and discuss about their pros and cons in a balanced and context-rich manner (a.k.a. professionally)
• how to deal with teamwork

We need professional and constructive opinions, not fanatic axioms.

"it's like colors, some people like it red some other blue that's it" / "it reduces my freedom"

No, it's not like colors. It's about readability, and about shared standards.

People doing this complaint are going towards the selfish path and do not realize the added value of common standards in dealing with code and, most of all, understanding other people's code and making them understand yours.

The fact that everyone has his/her own preferences, on the contrary, is exactly the reason why you should have coding standards, from comments, to naming, to formatting.

Sacrificing your "personal preferences" has to be done often for a greater good, good teamwork is all about compromise for the best result.

Imagine if:

• developer A has his standard
• developer B uses other formatting standards
• new "C" developer would have to read code in two different styles
• D in three... and so on.

It gets confusing and tiring because your brain has to adapt to different styles and constantly switch between them. With one shared standard, you just have to adapt once. In shared projects, even so if open sourced, you enforce standards for very good reasons.

And what if they edit the same file/class? Will it end up with different coding styles?

"it makes code more complicated to read with no added value"

I think what I stated above suffices as an answer to this utter nonsense.

---

Edit: please do look also at @nitarshs's answer, it gives another interesting angle from a group-psychology point of view that I found interesting.

Answer 7

Perhaps the root cause of the problem is not related to Code-formatting, but something else?

In my experience, this situation clearly shows that the dissenting individual has not expressed himself/herself in a mature and rational manner, immaterial of whether they are right or wrong.

I am not sure how long the individual in question has been with you and the team, but I really think you should know the person's disposition better to know how to handle situations like this

I have noticed that even rational people behave in irrational ways when they are not happy about something. Even they might be unaware of the true cause of their irritations.

Or its just possible that the person is immature by nature, in which case you can then choose to ignore them as long as they do their share of the work properly.

Maybe take them out for drinks/dinner and give them some care and attention. You should open up to them and let them open up to you. Try to know your teammates better and let them know you and the rest of the team better.

Answer 8

This isn’t about code formatting at all. It’s about the worst form of micromanagement possible. Whenever a commit is made, a stupid mindless micro-manager changes the code in a stupid micromanaging way. And this developer is pissed off. (It seems some people didn't get this - when I say "micro-manager" I'm talking about the code formatting tool).

Your gain, and your teams gain, from all of this is indistinguishable from zero. Your loss is that you had arguments, wasted your time, and you pissed off someone who so far has been a decent developer. Best case you will lose his support and engagement. Worst case you lose a valuable team member completely.

Just turn the tool off and be done with it. It has caused and will cause more damage than it’s worth. Just decide: Do you want to show that you have the biggest xxxx to wave around, or do you want a team that is happy and gets work done?

Answer 9

A few months ago, on the suggestion of another colleague we introduced mandatory code formatting in the code base

Since then, a colleague is always complaining and expressing disagreement about this decision

The core problem sounds not with the decision per se but with the fact that this colleague's opinion wasn't taken into account when making a decision that heavily affects them. Was this properly discussed, with all the pros and cons carefully evaluated (that goes for the automatic part of the enforcement, too), or you just made the decision unilaterally "because I personally like it"? Practice shows that a person is extremely more likely to defend a group decision if they feel that their opinion was heard and taken into account, even if it didn't make it to the decision in the end.

Answer 10

This isn't about code formatting. It's about being a good and effective manager and enforcing a decision you've taken on how the team does work - which as you've said is considered and is likely to the benefit of the team, overall.

I think the problem is best illustrated by removing the specifics from your question:

I am the manager of a small team of developers

-- I made a decision on a detail of how we do work --

Since then, a colleague is always complaining and expressing disagreement about this decision

It's a people problem - the hard part of being a manager. It's tempting to try to address the content of the complaints because they're familiar, comfortable territory and can be argued sort-of objectively.

But resist that temptation, because what you really have to do is tell this team member, directly and unambiguously, that they must accept the decision and stop discussing it.

It's personal, it's uncomfortable, but doing so is part of the job and is what the rest of the team wants and expects you to do, I can assure you.

Answer 11

Realistically, people leave teams. Using stylers like these make it easier for another person to pick up the project in the future, and understand the actual content instead of speaking time understanding the formatting of it.

Try responding with a positive of using them. For example, "code formatters are bs", "well, it can be easier to find simple mistakes in code when you know how it should look" etc. Even better if they can be relevant to your project/team directly.

If it was more than one team member, I would have suggested holding a meeting explaining why this formatting tool is being used, the benefit it brings, and why it is so important that your developers use it. People don't like change when they don't understand the reasons behind it.

Answer 12

Far from a complete answer, but there is one point in here that sticks out to me. The code formatting in your commits in no way needs to be the same code formatting as is used in a developer's IDE while they work on a local copy of the repo. I don't know that I've ever worked on a collaborative project where every developer didn't have their code formatted just how they wanted it. Applying the formatting upon commit is easy enough to set up through git hooks.

Answer 13

Ultimately, as other answers have said, as a manager you have the authority to simply enforce a code style, and if someone doesn't like it, they can quit. However, this probably isn't great for morale or engagement, and an employee who begrudgingly forces their round code into a square style probably isn't happy or productive.

To that end, your best course of action would likely be to convince them that having a consistent style in a codebase is beneficial. Some answers have presented some points already, but there are articles and in fact entire books arguing in favor. They're right that it's like colors - everyone does have a favorite, but if every UI developer working on a project simply chose their favorite color to design with, the final product wouldn't look good at all.

A couple good articles I've just found with a quick search:

• https://www.smashingmagazine.com/2012/10/why-coding-style-matters/

• https://arstechnica.com/information-technology/2013/06/is-it-a-good-idea-to-impose-uniform-code-format-for-all-developers/

Answer 14

I find a big difference between insisting on well formatted code and an auto-formatter being imposed on checkin.

At my job we have a code-formatting mandate of sorts, which is loaded into the IDE, but when it goes really bad there's really something we can do about it because nothing will try to re-apply it at commit time.

I'm willing to believe you have a real problem of a lead developer deliberately doing things so that they're harder to pick up, but it's entirely possible that what's really going on here is the autoformatter is messing up hand-formatted blocks where the language has been bent into something else and so needs a different format matching the structure it actually has rather than what the parser believes it has.

These cases are not distinguishable from your post. Depending on what is going on, you may or may not be able to talk to your other developers and find out which it is. Beware of the attitude of "I believe its better because the boss does" though; it won't be spoken to you but I've seen it fall like that before.

It's actually possible everybody has a problem with it, and they're all letting this guy be the spokesman. Maybe you can find out.

But on doing your due diligence, if you find he's on a power trip, it's time to get rid of him.

Answer 15

You have a frank conversation about what the word "professionalism" means.

Your "lead developer" is acting like a pouting child. He/she may have the technical skills of a lead but is obviously lacking the professional skills of a lead. It's about more than just writing code: technical skills are a necessary but not sufficient prerequisite of that position. Being a lead means, at least to me, understanding that it isn't about you. That doesn't mean that you don't negotiate and advocate for yourself, it does mean that you don't throw a fit about things that are industry best-practices even if you privately think they are bullshit (lookin' at you, JIRA).

I would start by saying that he/she needs to get over it diplomatically, then move on to saying it undiplomatically, then move on to a PIP. You've already wasted too much of your valuable time on someone else's temper tantrum.

EDIT based on conversation in the comments

One commenter correctly points out that the tech lead's authority may have been unfairly undermined thus causing disgruntlement. While I certainly agree that might be the case, grumbling about the tool in public is an unprofessional and unacceptable response to the situation. Being undermined should be addressed directly, and in private.

Answer 16

I'm going to assume your representations of your lead developer's comments are accurate.

These are not the comments of a competent lead developer. I say that as an experienced software and manager of software engineers myself.

The feedback is unconstructive and highly inaccurate. A lead developer who does not understand the value of formatting standards is a lead developer who doesn't understand the dynamics of collaborative engineering.

It's quite possible that they do have legitimate and actionable concerns and I would start from this perspective. You're their manager; help them do their job well.

First, privately call them out on their crappy feedback to you. They are doing their job poorly, if they're just kvetching.

Next, demonstrate that you are open to actionable feedback on how to improve the implementation of coding standards if your developer has any. If they need time to figure out how best to articulate this, give it to them.

If they have nothing specific, then tell them to get with the program and stop bitching. It's not just unproductive. It's detrimental to the team.

You should also start paying attention to their performance as a leader on the team in general. Are they actually providing leadership to the other team members or are they simply the person who has been around the longest? Folks like this can really undermine a team's productivity if they are just acting as a gatekeeper to growth (which is what this individual is doing right now).

Answer 17

From a pragmatic point of view, I love code formatting simply because it makes diffing code so much easier. It will also make pushes much easier since if everybody is using the same code formatter, then in principle, adding a dumb inconsequential change to a file won't result in git thinking that the code has changed.

Personally I am not crazy about how the code looks, but the benefits outlined above more than help me overlook this.

Answer 18

Many other answers discuss if code formatting is worth it or not. That is entirely irrelevant to this question.

This is about communication, not about convincing him that standardized code formatting is great. Take a step back. What you need to communicate is:

• What you're trying to achieve.*
• How you're planning to measure success.

That extra bit of information will allow them to see things from your point of view, which is oftentimes enough to pacify them. The second part (measuring success) is necessary to demonstrate that you actually put some thought into it and makes it easier for them to trust you. It also allows them to find alternatives or modifications to the policy which satisfy your requests as well as theirs.

If that fails, there are 2 major ways to deal with employees who disagree with a policy change:

• Listen to them. They are paid professionals and their concerns may be more valid than you think.
• Shut them up. "This is the decision. I know you don't like it, and I have heard your concerns, but now I need you to accept it and work with the team."

---

*This is not about a list of benefits, it's about your motivation to implement the change. Maybe you want to empower the team and that's why you had the team decide on code standards and formatting. Maybe you just implemented a suggestion from higher up. Maybe you're planning multiple automation and/or analysis changes down the line that will benefit from standardized formatting. Maybe you want to use standardized formatting to better sell your team to the higher ups. Maybe you pushed standardized formatting simply because you like it.

Answer 19

I think that in this case it would be maybe possible to add a git hook that changes the code format to the one desired by the team on commit, and another one (used only by them) that changes the code format to the one desired by the team member on update.

If the team member feels so strongly about this, it may also be a good occasion to learn more about the code formatter and the git tooling, all knowledge that may handy later on.

Answer 20

code formatting is totally bullshit

This can easily be disproven by taking some example code (unknown to the developer), removing all newlines, tabs, and reducing multiple spaces to single spaces, and asking the employee to tell you what the code accomplishes.

it's like colors, some people like it red some other blue that's it

Yep. This is the case for pretty much any programming dispute. Tabs vs spaces, C-style brackets or egyptian brackets, ... But the answer is always the same: Some people like to drive on the left, some people like to drive on the right. Either is fine, but allowing both at the same time leads to madness.

Or, if you really want to use his analogy against him: but using blue and red together makes purple, which means that no one gets what they want.

An executive decision has been made to pick this format. Your employee does not have the authority to override that discussion. End of story. I would not endulge this line of questioning any further.
I'm always open to constructive feedback but your employee's argument is one of hardheadedness, it's not constructive. Don't let them turn it into a competition of being the most stubborn. Even if you win, you're signaling to your staff that being stubborn is an acceptable way of expressing disagreement.

That doesn't mean you can't help him if it's simply a matter of inexperience. Maybe you can find an automated formatter so he can type in his own format and have it converted.

I've told the people I managed that I don't care about the readability of their code before they check it in. I'm not expecting them to fully uphold the style guide at every second. As long as the code gets cleaned up before it's merged into the branch, that's acceptable. I often start from quick and dirty code and only clean it up once I got it working. Some people work this way, and that's okay, as long as they don't skip the required cleanup in the end.

it reduces my freedom

No one has the freedom to do whatever they want. Having to pay the employees reduces the company's freedom too.

The effort required to format the code from the get go will pay back dividends when someone else has to read their code.

Given this employee's remarks, I suspect it's likely that he's complained about other people's code formatting or naming conventions. Point out that others will feel the same about his formatting and naming. Uniformity means that everyone can read everyone's code, regardless of whether it's everyone's personal preference.

it makes code more complicated to read with no added value

It's harder to read for him now because he's not used to it. The more he resists the change, the longer he's going to struggle with it. The decision has been made, it is happening, end of story.

I would focus on the point that the employee has been informed of the new format, and is expected to now uphold it. If they don't comply (or don't put in genuine effort), any delays caused by their pull requests being rejected falls squarely on their shoulders.

---

Code merge requests have to be formatted with the tool otherwise they cannot be added to the software.

When you say "cannot", do you mean that it's not allowed, or that it's not possible (e.g. a reviewer will always reject the request)?

If it's the latter, that's the stick you need. If the developer does not follow the formatting rules, their requests do not get accepted and any delays incurred from this are their responsibility, which will result in a bad performance review.

If it's the former, then you're really relying on everyone to willfuly partake in the system, which only works if everyone does so. You're currently dealing with someone who's holding out. It's possible that he's holding out specifically because he knows that you don't enforce it but only ask.

Answer 21

You're a manager, so let's try to manage him (and this), don't just tell him off or view him as a problem:

"John, my responsibility is to make this as easy as possible for everyone, and for future employees, not just some of the people here today."

"When most developers looks over code, its faster if they can take some things for granted, like the way the code will be done, and the way some things are standardised. If there is ever a need for anyone to scrutinise the code [External code audit? Liability? Due diligence?], its better if it is standardised. You're right that some like blue and some like red, and outside work, you and I can both code in any way we like. But while we're writing code that a team has to maintain, and future engineers have to quickly and accurately understand, my belief is that standardisation will help, and I'm leading the team - not you, not Bob, not Alice, so I have to make those kinds of calls if I feel the need - and I do."

"When you find yourself managing projects like this in future, you can make the call you like, and expect others to follow your directions. But I hope when you do - and you're good so you probably will [a compliment never hurts if it's true, if not leave out] - that you'll reconsider and see the benefits it gives, even if it imposes a discipline that you don't see any point in, right now."

"I believe it will save small amounts of time in every days work, when code is redone, I believe it will reduce errors, and I believe it is professional. I'd like you to respect that even if you don't agree with it."

Answer 22

Whitespace is actually part of the python syntax. Readability is already designed in the language. In fact, python has it's own recommendations on how to format your code. Best Practices, naming conventions, etc. it's called PEP (more specifically PEP8). Start there! Knowing PEP is something they can add to their resume!

How would you deal with such situation ?

I think the four other developers are on the right side of this argument and you may be in the wrong here. Honestly take in the feedback of your employees and take it to heart. Put yourself in their shoes. If there paycheck is based on performance, and this tool reduces that, you're essentially taking money from them in their mind.

I think a good next step is to decide whether or not to continue using the tool. If you deem it beneficial, explain why. For example, if the End-User/Client gives you better reviews or future projects because the code is beautiful - tell that to your employees! That means more money in their pocket!

Remember, your KPIs for Quality Assurance may not be what is in the job description for your team members. Make your team have buy-in on their projects. Make it something they are proud to own. When a strong sense of ownership is a workplace norm - quaility assurance comes naturally.

Answer 23

Two additional points may be worth considering.

1. You're asking for a black/white answer for a grayscale problem. Your code formatting rules could be reasonable, could be relaxed, could be nitpicking. I have seen all kinds of rules. So first, of all, check if the code format rules you demand are actually reasonable or not.
2. Was the code formatting and all the code standard rules just imposed from above, or agreed by the developers in the team - those who actually write the code and who read / use the code from others? It might be a good practice to decide on a set of coding standard rules by committee - once only, and then these rules are enforced. If most of the devs agree to them, then you have a high chance of these rules being reasonable, and if anyone complains, chances are, he is the problem. If the rules were simply imposed by decree of one person... well then you might have a problem there.
3. An alternative is to find a code inspection / formatting tool that's more or less the industry standard for the language you use. For example, for C# I use Resharper. Then the decision will be unbiased, and the formatting can more or less be done automatically in the editor, as the code is written. If Resharper is happy, I'm happy. Find something of that sort for Python.

My personal rule of thumb when I lead a team is to only insist of strict rules when someone's code looks really ugly... and if that happened, we could be looking at a deeper problem than just code formatting. A problem that starts from HR and hiring the wrong person. Otherwise, if the code looks more or less clear and organized, and its architecture / design is good, nitpicking about formatting often causes more trouble than it's worth.

Answer 24

Consistency is a weak argument. For a person who doesn't agree with a particular formatting rule, it might feel like there's a problem with micromanagement or with a power-hungry architect. Formatting almost never matters - "it's like colors, some people like it red some other blue".

The real benefit of automated formatting rules is that programmers don't waste time discussing stuff that doesn't matter. Too much time is spent in code reviews on comments about indentation. Much more brain power should be focused on real problems with the code.

Introduce the developer to the term Bikeshedding. Make it clear that you consider his comments a great contribution to bike shed design. He wastes time of others. He is a bad team player. It will be used against him during evaluation.

Answer 25

In addition to the other responses which covered The Talk pretty well already - a methodology to introduce formatting in your process whether Bob likes it or not:

Do code reviews using the four eyes principle on each and every merge request. Your master should only be modified with accepted merge request, no other way. All merge requests must be subjected to quality assurance, i.e. a different team member must look over the code. Enforce formatting and let Bob's MRs be rejected due to wrong code formatting.

If Bob refuses to comply, then his merge requests will be stuck in limbo. When asked, "why is feature XY not done, despite the deadline having long passed?", Bob may respond, "this has been done for a while, but got rejected by colleague Y". You can argue that it is then not done. This is what quality control is for. Coworkes must reject such requests and reassign Bob, it is then Bob's job to deal with it.

There are various degrees of agressive if acting this way, so if you want the tone to stay as friendly as possible, be careful about how you implement this. Nevertheless - you should do code reviews anyway.

On a personal note - Bob's supposed statements about usefulness of formatting incline me to think they are possibly not suited for a lead role or simply lack some specific education in certain areas. Maybe they know the codebase in and out, but due to lack of best practices helped turning it into a giant mess and only they know a path through the chaos. This kind of thing is dangerous, because you may become very dependent on one single person as your codebase grows less and less maintainable.

Answer 26

There are a lot of answers here which focus on good technical arguments. To summarize: the team made a sound decision on how to proceed, and one individual rejects the team decision and the manager directions.

The conversation which I would have is more along the lines of: did you just call my instructions and the team decision "bullshit"? Did you really complain that being paid for working "restricts your freedom"? I strongly suggest you check in your code nicely formatted right now, and I will arrange a meeting with HR to discuss respect toward your employer, manager and team.