Team Reputation

  • Comments posted to this topic are about the item Team Reputation

  • There is the reputation of the team and your personal reputation. Most of the teams I've been on were somewhere in the middle; not bad, not great. I think that probably describes most people; simply average.

    Even if you're on a team with a bad reputation, you can drive yourself to achieve a stellar reputation.

    Tom

  • I started on my current team as the "low man", over eight years ago. The team was struggling (I knew this) and was known as one of the "armpits" of the company. There was a lack of SQL Server expertise (one of the reasons I was hired), so I knew I could make a difference.

    Today I manage this team, and overall, the team has a pretty good reputation. We are often the "go to" people when either our services or our support people need assistance with data adjustments / corrections / custom work in a customer's database. This is in addition to our normal responsibilities (custom data conversions).

    I agree that an individual can stand out, even on a poor team. By being helpful, having a good work ethic, and providing excellent deliverables - on time, within budget, and with few defects - that individual is likely to be retained / promoted / given other opportunities, regardless what happens with the rest of the team.

    I also agree that the team reputation can reflect the reputation of the leader. If the leader is excellent, the leader likely demands excellence of the team. If the leader is belligerent, team individuals likely can't be as helpful as they may like to be because of the reaction they get from their lead. If the leader is poor, the poor members of the team likely get away with continuing to be poor.

  • Our department/team recommended various software applications to our users

    so we were considered the "experts".

    On one team assignment, a team member and I installed our recommended

    software on a users computer, all the while, my team-mate berated,

    slammed and practically "s___ on" the application to the user. I was furious

    but held my tongue in front of the users. On our way back to the office,

    I was really Pissed. I let loose on the team mate for throwing our (and my)

    reputation with that user out the door. That user certainly won't come to

    us for recommendations after we gave them a crappy application. I even

    told my boss that the team mate may come to him complaining about the

    berating I gave him. I didnt see the team-mate the rest of the day.

    The next day, he was more nice to me than he had been in a long time

    and nothing else was said about the incident.

    I was able to reassure the users and maintain our reputation as the

    solution provider. Reputation of an IT group whether it be developers or

    IT technicians, is of paramount importance.

  • I'd go so far as to say that you need to (and to be able to) take pride in your team. It's definitely one of those circumstances where if you've got nothing good to say then say nothing - you just cannot knock your team mates or their work to anyone outside the team except in the most circumspect of manners. It's an unwritten rule, a kind of omerta of IT in my book.

  • While doing customer service work, one (not one of my usual ones)

    when calling in for assistance,

    said Don't send Jack because he lies

    and Don't send Joe because he farts.

    Now, that is a perception problem...

    (names changed to protect the guilty)

  • call.copse (4/7/2014)


    I'd go so far as to say that you need to (and to be able to) take pride in your team. It's definitely one of those circumstances where if you've got nothing good to say then say nothing - you just cannot knock your team mates or their work to anyone outside the team except in the most circumspect of manners. It's an unwritten rule, a kind of omerta of IT in my book.

    Ditto! 😎

  • I have to disagree a bit with the aspect of not saying anything if someone doesn't meet expectations. There's no doubt that not everyone on a Team is going to be equal. I very much agree with the intelligent manager that will find the niche that a "misfit" can really excel at and become a productive and contributing member of the Team.

    But there are some real bucket-for-brains managers out there that simply don't pay attention or that simply can't handle conflicts of any kind. You all know the type I'm talking about. I've worked for a couple of managers that have allowed slackers, posers, fakers, arrogant sots, those that practice malicious compliance with rules and standards, whiners, and a few other ugly personality types to continue at the company and, yeah, you know those types, as well. These types of people can very quickly destroy a team and if the manager isn't doing anything about it, then you're doing the company a diservice by not taking it up the chain. And, before you do that, you need to make damned sure of two things... 1) you're right and 2) your not a problem yourself. And, yeah... there's a right way and a wrong way to do this but keeping your mouth shut might not be the right thing to do either.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden (4/7/2014)


    I have to disagree a bit with the aspect of not saying anything if someone doesn't meet expectations. There's no doubt that not everyone on a Team is going to be equal. I very much agree with the intelligent manager that will find the niche that a "misfit" can really excel at and become a productive and contributing member of the Team.

    I'm going to have to agree with the whole idea -- but the way to handle it is inside the team and the management chain. You do your best not to reveal the problems to anyone outside the team.

    So the comment that "Joe Bob didn't fix this yesterday," is met with "This is a new issue that we're just discovering and working on," or something similar. Then when you get back to the team you either comment to Joe Bob and/or document it or bring it up to management as needed.

    And then there is also the need to follow the chain of management if it is not a fiduciary, regulatory, or similar issue. If you give your lard brained manager athlete's scalp too often you may be the problem and probably need to look elsewhere for employment.

    To me that is the professional way to handle it. Essentially you do your best to cover to the outside the problems in the team and then work the problems out internally as best as possible.



    ----------------
    Jim P.

    A little bit of this and a little byte of that can cause bloatware.

  • In the teams I've worked on, customers (whether internal or external) have always been able to sniff out who is competent or incompetent and use them as a point of contact/avoidance as necessary.

    I don't take responsibility for other adults on the team. If they fail the "team" may be impacted by that but it doesn't somehow abstractly translate to my work not being up to scratch.

  • Cody K (4/7/2014)


    In the teams I've worked on, customers (whether internal or external) have always been able to sniff out who is competent or incompetent and use them as a point of contact/avoidance as necessary.

    While that may leak out, you don't try to make it obvious.



    ----------------
    Jim P.

    A little bit of this and a little byte of that can cause bloatware.

  • Jim P. (4/7/2014)


    While that may leak out, you don't try to make it obvious.

    Definitely.

  • Jim P. (4/7/2014)


    Jeff Moden (4/7/2014)


    I have to disagree a bit with the aspect of not saying anything if someone doesn't meet expectations. There's no doubt that not everyone on a Team is going to be equal. I very much agree with the intelligent manager that will find the niche that a "misfit" can really excel at and become a productive and contributing member of the Team.

    I'm going to have to agree with the whole idea -- but the way to handle it is inside the team and the management chain. You do your best not to reveal the problems to anyone outside the team.

    So the comment that "Joe Bob didn't fix this yesterday," is met with "This is a new issue that we're just discovering and working on," or something similar. Then when you get back to the team you either comment to Joe Bob and/or document it or bring it up to management as needed.

    And then there is also the need to follow the chain of management if it is not a fiduciary, regulatory, or similar issue. If you give your lard brained manager athlete's scalp too often you may be the problem and probably need to look elsewhere for employment.

    To me that is the professional way to handle it. Essentially you do your best to cover to the outside the problems in the team and then work the problems out internally as best as possible.

    Absolutely agreed. And I do tend to protect the team I'm on from outsiders. Having been in the Navy for almost a decade, I also have a strong respect for the chain of command. So if there's a real problem with someone on the team, I'll take it and copies of the pile of documentation I've collected on the person to the manager. Of course, it's very likely that, because the trouble maker is still employed, that the manager is going to be absolutely useless because 1) the manager should already know about that and 2) have already done something about it.

    If the manager doesn't take care of a "poison member", then I'll make a decision. If the company is worth working for (and I'm not just talking about money), I'll take it up to the next rung in the chain of command but (now) with 2 people to report. If it's not, then I'll give my two weeks notice because it's not worth working with "poison team members" that report to a manager that allows it to continue. As they say... "Been there, done that, not doing it again".

    Of course, that would also indicate a personal failure on my part. I can normally turn someone around long before such an action would even come close to being required.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

Viewing 13 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic. Login to reply