• Comments posted to this topic are about the item Reteaming

  • This is an entirely new idea for me and one that I believe should be approached with an abundance of caution.  The idea of doing this just because 'it's that time of  year' or something akin to that, is very scary.  I'm all in favor of the concept of allowing people to participate in deciding their assignments, as long as it is in the interest of the employee, the team, and the company, but I think doing this 'just because  we can' could be quite disruptive.

    Timing could be very critical, and I would definitely do this is stages as much as possible, even to the point of making the transitions as gradual as possible to maintain some overlap.  It could be much easier to 'undo' a single transition that to fix  several at the same time.

    Maybe it's just my lack of experiencing this.



    One of the best days of my IT career was they day I told my boss if the problem was so simple he should go fix it himself.

  • I don't see a lot of movement among the rank and file, where I work. There does seem to be a fair amount of changing among middle management. Redgate's practice of reteaming is an entirely new idea to me. I'm interested in it. Would love to experience it myself.

    At my old job, because it was a small organization with only a couple IT/of IT/developers, it was quite easy to switch roles. In my current job switching to do something else is, apparently, impossible. I've spoken twice to my boss about wanting new challenges and to work on other tasks. Those requests have fallen on deaf ears. Apparently, in larger organizations with a couple hundred IT/developers everyone gets pigeonholed.


  • Definitely pigeon holed at my company.  No movement is possible outside of reorgs, at which time movement is not voluntary.

    To move up, one must move out.

    And that's exactly what the best people do...

  • We're too small a team to do something like this but I think for larger teams this is a very interesting idea. I am fortunate that in our small team I do many different tasks. One day I might be writing scripts to update or add new lab tests. Another I might be doing performance tuning or helping the devs write better T-SQL. And then, like this last week, I might find myself learning all about Azure SQL Managed Instances and migrating some QA databases up to a non-production Azure SQL Managed Instance. It keeps me learning and interested.

  • We tend to have small teams at Redgate, but we have many of them.

    Note that not everyone moves every year. Plenty of people choose to stay with the same team for a few years.

  • From the Article:

    I've seen friends at Microsoft change departments, products, etc. every year or two.

    Actually, that explains a lot.  While it may keep people from getting "bored" or "stagnant", it does mean that knowledge of SME's for any given product is a whole lot less than it could/should be.

    --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)
    Intro to Tally Tables and Functions

Viewing 7 posts - 1 through 7 (of 7 total)

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