• Project Meetings

    From poindexter FORTRAN@21:4/122 to All on Wed Dec 6 08:21:23 2023

    Project Meetings only happen in this day and age because Project Managers would rather take up everyone's time going over an Excel spreadsheet than to have people use modern collaborative tools.


    And, if there were no project management meetings, we wouldn't need as many project managers...
    --- SBBSecho 3.20-Win32
    * Origin: realitycheckBBS.org -- information is power. (21:4/122)
  • From esc@21:4/173 to poindexter FORTRAN on Wed Dec 6 09:36:51 2023
    Project Meetings only happen in this day and age because Project
    Managers would rather take up everyone's time going over an Excel spreadsheet than to have people use modern collaborative tools.

    Tuggin' on my heartstrings over here!

    Meetings...the bane of my existence. Sometimes it's nice to be unemployed.

    --- Mystic BBS v1.12 A49 2023/02/26 (Linux/64)
    * Origin: m O N T E R E Y b B S . c O M (21:4/173)
  • From Nightfox@21:1/137 to poindexter FORTRAN on Wed Dec 6 13:03:23 2023
    Re: Project Meetings
    By: poindexter FORTRAN to All on Wed Dec 06 2023 08:21 am

    Project Meetings only happen in this day and age because Project Managers would rather take up everyone's time going over an Excel spreadsheet than to have people use modern collaborative tools.

    And, if there were no project management meetings, we wouldn't need as many project managers...

    One of my pet peeves is being stuck in meetings too long when I have work I'd rather be making progress on - especially if the meetings are set up by the same people who asked us to do the work, and especially if the meetings go longer than they were supposed to.

    Nightfox
    --- SBBSecho 3.20-Linux
    * Origin: Digital Distortion: digdist.synchro.net (21:1/137)
  • From poindexter FORTRAN@21:4/122 to Nightfox on Wed Dec 6 18:21:04 2023
    Re: Project Meetings
    By: Nightfox to poindexter FORTRAN on Wed Dec 06 2023 01:03 pm

    One of my pet peeves is being stuck in meetings too long when I have work I'd rather be making progress on - especially if the meetings are set up by the same people who asked us to do the work, and especially if the meetings go longer than they were supposed to.

    There was a point in time when I was the only person managing corporate systems for an e-commerce company. I got pulled into all of the management meetings, even though very few applied to me. At one point it was over 20 hours of my work week.

    I was listening to a podcast where the guest (the founders of 37Signals, the makers of Basecamp) were talking about their philosophy regarding meetings. They commented that you only recall a couple of meetings that were significant.

    I thought about a project manager I worked with in the 90s who ran a meeting like a machine. He started every meeting on time, brought people in, got their input and excused them when they were no longer needed. In and out.

    I strive to run my meetings like his.
    --- SBBSecho 3.20-Win32
    * Origin: realitycheckBBS.org -- information is power. (21:4/122)
  • From Nightfox@21:1/137 to poindexter FORTRAN on Thu Dec 7 12:46:13 2023
    Re: Project Meetings
    By: poindexter FORTRAN to Nightfox on Wed Dec 06 2023 06:21 pm

    I thought about a project manager I worked with in the 90s who ran a meeting like a machine. He started every meeting on time, brought people in, got their input and excused them when they were no longer needed. In and out.

    I strive to run my meetings like his.

    That would be a good way to do it, if it's the type of meeting where different information is only relevant for each person.

    Nightfox
    --- SBBSecho 3.20-Linux
    * Origin: Digital Distortion: digdist.synchro.net (21:1/137)
  • From Commodore Clifford@21:3/171 to poindexter FORTRAN on Wed Dec 20 01:50:42 2023
    On 06 Dec 23 08:21:23 poindexter FORTRAN wrote...


    Project Meetings only happen in this day and age because Project
    Managers would rather take up everyone's time going over an Excel spreadsheet than to have people use modern collaborative tools.

    And, if there were no project management meetings, we wouldn't need
    as many project managers... --- SBBSecho 3.20-Win32 * Origin: realitycheckBBS.org -- information is power. (21:4/122)

    To which Commodore Clifford replies...

    I thought their only purpose was to cause havoc and panic over things
    that aren't actually problems, requiring you to spend two hours
    explaining to a clueless IT Director that "this is how the system has
    always worked, how we expected it to work just that "the business" people
    never noticed and now thinks it is broken".

    --- RATSoft/FIDO v09.14.95 [JetMail 1.01]
    * Origin: STar Fleet HQ - Real Atari! bbs.sfhqbbs.org:5983 (21:3/171.0)
  • From Commodore Clifford@21:3/171 to esc on Wed Dec 20 01:52:12 2023
    On 06 Dec 23 09:36:51 esc wrote...

    Project Meetings only happen in this day and age because Project Managers would rather take up everyone's time going over an
    Excel spreadsheet than to have people use modern collaborative
    tools.

    Tuggin' on my heartstrings over here!

    Meetings...the bane of my existence. Sometimes it's nice to be
    unemployed.

    --- Mystic BBS v1.12 A49 2023/02/26 (Linux/64) * Origin: m O N T E R
    E Y b B S . c O M (21:4/173)

    To which Commodore Clifford replies...

    Well, I can't say I'd rather be unemployed... but I do wish IT was in
    charge of the projects.

    "No, you are not allowed to 'escallate' this because it's 'working as
    designed' you moron!"

    --- RATSoft/FIDO v09.14.95 [JetMail 1.01]
    * Origin: STar Fleet HQ - Real Atari! bbs.sfhqbbs.org:5983 (21:3/171.0)
  • From Commodore Clifford@21:3/171 to Nightfox on Wed Dec 20 01:56:24 2023
    On 06 Dec 23 13:03:23 Nightfox wrote...

    One of my pet peeves is being stuck in meetings too long when I have
    work I'd rather be making progress on - especially if the meetings
    are set up by the same people who asked us to do the work, and
    especially if the meetings go longer than they were supposed to.

    Nightfox --- SBBSecho 3.20-Linux * Origin: Digital Distortion: digdist.synchro.net (21:1/137)

    To which Commodore Clifford replies...

    My favorites are the ones where we have a four hour meeting to discuss an incident, listening to someone prattle on about how they want to be "fair
    to the devs"... in the meantime, the problem isn't even with our code,
    but with another system entirely and once the correct people figured it
    out, I doubt it even took that long to fix it.

    Oh, and this was between 8am and noon on a Sunday where we had already
    been up at 4am during a deploy and the feature was a pilot that we could
    have turned off anyway.

    --- RATSoft/FIDO v09.14.95 [JetMail 1.01]
    * Origin: STar Fleet HQ - Real Atari! bbs.sfhqbbs.org:5983 (21:3/171.0)
  • From poindexter FORTRAN@21:4/122 to Commodore Clifford on Thu Dec 21 16:06:00 2023
    Commodore Clifford wrote to Nightfox <=-

    My favorites are the ones where we have a four hour meeting to discuss
    an incident, listening to someone prattle on about how they want to be "fair to the devs"... in the meantime, the problem isn't even with our code, but with another system entirely and once the correct people
    figured it out, I doubt it even took that long to fix it.

    I remember a prticularly spicy post-issue meeting after my company's
    web site was down for an extended period. teams were trying to find the
    root cause, our DB said it wasn't the DB, and when he was questioned
    further, he quit, because he wouldn't work somewhere where his
    expertise was questioned.

    If memory serves, it was the DB.



    ... Abandon desire
    --- MultiMail/Win v0.52
    * Origin: realitycheckBBS.org -- information is power. (21:4/122)
  • From Commodore Clifford@21:3/171 to poindexter FORTRAN on Fri Dec 22 12:40:16 2023
    On 21 Dec 23 16:06:00 poindexter FORTRAN wrote...

    Commodore Clifford wrote to Nightfox <=-

    My favorites are the ones where we have a four hour meeting to
    discuss an incident, listening to someone prattle on about how
    they want to be "fair to the devs"... in the meantime, the
    problem isn't even with our code, but with another system
    entirely and once the correct people figured it out, I doubt it
    even took that long to fix it.

    I remember a prticularly spicy post-issue meeting after my company's
    web site was down for an extended period. teams were trying to find
    the root cause, our DB said it wasn't the DB, and when he was
    questioned further, he quit, because he wouldn't work somewhere
    where his expertise was questioned.

    If memory serves, it was the DB.

    To which Commodore Clifford replies...

    In my case, we have the opposite problem. We have our huge meetings when something goes wrong and they always blame us and want us to "own" the
    problem because it's on the website where you see the error.

    The problem is, it's rarely really our problem when it's something big...
    it's usually one of the hundreds of service endpoints we have to interact
    with. One of those fails, we have an error message displayed. But it's
    not our code that is in error. Sometimes, we can do a fix faster (this
    is usually the case when someone makes a change to a service without
    actually testing it or notifying all consumers of the service) but they
    still try to "blame" us.

    It's getting old.

    --- RATSoft/FIDO v09.14.95 [JetMail 1.01]
    * Origin: STar Fleet HQ - Real Atari! bbs.sfhqbbs.org:5983 (21:3/171.0)
  • From Bf2K+@21:3/171 to Commodore Clifford on Tue Dec 26 10:12:24 2023
    On 22 Dec 23 12:40:16 Commodore Clifford wrote...

    On 21 Dec 23 16:06:00 poindexter FORTRAN wrote...

    Commodore Clifford wrote to Nightfox <=-

    My favorites are the ones where we have a four hour meeting
    to discuss an incident, listening to someone prattle on
    about how they want to be "fair to the devs"... in the
    meantime, the problem isn't even with our code, but with
    another system entirely and once the correct people figured
    it out, I doubt it even took that long to fix it.

    I remember a prticularly spicy post-issue meeting after my
    company's web site was down for an extended period. teams were
    trying to find the root cause, our DB said it wasn't the DB, and
    when he was questioned further, he quit, because he wouldn't
    work somewhere where his expertise was questioned.

    If memory serves, it was the DB.

    To which Commodore Clifford replies...

    In my case, we have the opposite problem. We have our huge meetings
    when something goes wrong and they always blame us and want us to
    "own" the problem because it's on the website where you see the error.

    The problem is, it's rarely really our problem when it's something
    big... it's usually one of the hundreds of service endpoints we have
    to interact with. One of those fails, we have an error message
    displayed. But it's not our code that is in error. Sometimes, we can
    do a fix faster (this is usually the case when someone makes a change
    to a service without actually testing it or notifying all consumers
    of the service) but they still try to "blame" us.

    It's getting old.

    --- RATSoft/FIDO v09.14.95 [JetMail 1.01] * Origin: STar Fleet HQ -
    Real Atari! bbs.sfhqbbs.org:5983 (21:3/171.0)

    To which Bf2K+ replies...

    Whenever my customers have an issue with a 3rd party device, we ahve to
    go in and solve the problem. They ahve no understanding of the Siemens
    PLC controlling the machine, so every little problem is blamed on Siemens
    and we have to fix it. This happens 80% of the time... it is downright stupidity.


    --- RATSoft/FIDO v09.14.95 [JetMail 1.01]
    * Origin: STar Fleet HQ - Real Atari! bbs.sfhqbbs.org:5983 (21:3/171.0)
  • From Commodore Clifford@21:3/171 to Bf2K+ on Tue Dec 26 11:41:08 2023
    On 26 Dec 23 10:12:24 Bf2K+ wrote...

    Whenever my customers have an issue with a 3rd party device, we ahve
    to go in and solve the problem. They ahve no understanding of the
    Siemens PLC controlling the machine, so every little problem is
    blamed on Siemens and we have to fix it. This happens 80% of the
    time... it is downright stupidity.

    --- RATSoft/FIDO v09.14.95 [JetMail 1.01] * Origin: STar Fleet HQ -
    Real Atari! bbs.sfhqbbs.org:5983 (21:3/171.0)

    To which Commodore Clifford replies...

    Right now, this week my biggest thing is "the business" reporting things
    as bugs because it's not how any given "individual" thinks it should
    work.

    It works as was indicated by the requirements.

    They don't like that... they think it should "do this" instead.

    Well, ok... but the other guy thinks it should work "that way" and the
    other woman over there thinks it should work "totally differently".

    My answer.

    THUNDERDOME!

    --- RATSoft/FIDO v09.14.95 [JetMail 1.01]
    * Origin: STar Fleet HQ - Real Atari! bbs.sfhqbbs.org:5983 (21:3/171.0)
  • From ogg@21:2/147 to Commodore Clifford on Tue Dec 26 12:39:29 2023
    To which Commodore Clifford replies...

    Right now, this week my biggest thing is "the business" reporting things as bugs because it's not how any given "individual" thinks it should
    work.

    It works as was indicated by the requirements.

    They don't like that... they think it should "do this" instead.

    Well, ok... but the other guy thinks it should work "that way" and the other woman over there thinks it should work "totally differently".

    My answer.

    THUNDERDOME!
    I worked on the principle that if 50% liked it and the other 50% didn't, it was a win for me!

    ogg
    Sysop, Altair IV BBS
    altairiv.ddns.net:2323

    ... Help! I can't find the "ANY" key.

    --- Mystic BBS v1.12 A49 2023/04/30 (Windows/64)
    * Origin: Altair IV BBS (21:2/147)