Mostly work woes
Jun. 21st, 2021 10:11 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
shivverI really should post more. I've got a few things to talk about, but for the most part, non-work life has been pretty vanilla. Work, however...
Office reopening...
Most recently, the office re-opened today. The list of rules for coming in, though.... whooo. Interestingly, there's no mask rule, but there's "no gathering in communal areas", "wipe down communal areas after use", "bring your own food, containers, utensils", "minimum 1-hour gap between meetings in conference rooms", and more.
Personally, I'm not going in any time soon, and only part of that is that I still consider our country to be in the grip of a pandemic. My industry doesn't require, for the most part, working in proximity with our colleagues. Is adding all this overhead to our day really worth it? For some people, it'll help (one of the members of the team I'm on really wants to get out of the apartment away from his roommate, so I can see it being helpful for him), but in general, it's not going to add to our productivity and work quality.
Not to mention, I really like being able to roll out of bed, grab a muffin and tea, and get to work. I have not missed losing an hour of my day simply to the commute.
Drama...
A month ago or so now, the company let the director of engineering go, which was a huge surprise. Not from a performance point of view. He (I'll call him Rick) has been ineffective at best, obstructionist at worst.
Rick's a friend from years ago, and he's a great developer, but not so great as a manager. He has old-fashioned views of how to run things that don't work well with the structure of the company. Development-wise, he believes fervently in the waterfall methodology, which, in a nutshell, means that a design for the software is created, then the developers create the software, then QA tests it, and then it's released - the process moves like water over a waterfall.
It sounds great, but it has a lot of problems. First, clients rarely have a coherent idea of what they want created, much less a full detailed design. Second, if they did have a design, it normally takes months to create software, and at the end, the client looks at it and says, "This doesn't solve the problem." Basically, waterfall doesn't really handle change very well, and so you end up either spending a lot of time either doing work that isn't ultimate used or backtracking and rewriting things as new things up. Third, everything's in a phase, so while design is creating the design in the first phase, what are your devs and QA doing?
A large portion of the software industry has adopted some form of Agile methodology to solve some of these problems. Agile, in a nutshell, works in short time periods called sprints, during which the devs create and QA tests a small slice of what the client wants. The client gets to see very quickly if it's what they want, and the next sprint, a new piece is created, or the previous pieces are adjusted, which isn't a huge deal because they're small. Thus, everyone always has work to do, changes can be incorporated without too much upheaval, and the client gets to see things as they are created and not all at once six months later.
Agile isn't perfect, but it's as close to industry-standard as it can be... and Rick is adamant that it can't possibly work (even though most of us have come from companies that run successfully using it). I remember him saying, "No, we're not doing Agile. I'll work on it this weekend and come up with a process that'll work" - that was two years ago and he never did produce it. (Not that I expected him to - he expected to come up with a new, efficient process in a weekend when the industry's specialists have been working on the problem for decades?) We've been using Agile all this time while Rick has been trying to find the Holy Grail of processes.
The other main thing that Rick insisted upon was a flat management structure, which, to him, meant that as director of engineering, all developers reported directly to him, rather than to a middle manager. That might have been good four years ago when the company was founded, but now we have 40+ developers, which means at the very least, that's 40+ hours spent in one-on-one meetings with each developer every two weeks. Not to mention 40+ review cycles every year - even estimating a week of work for preparing an employee's review (which is low), that's over 3/4 of a year of work.
Needless to say, Rick was neglecting his developers. They weren't getting their one-on-ones, they had no one they felt they could talk to, Rick wasn't helping them with their career development, etc. Two of the most important devs on my project quit in the last two months, primarily because of Rick.
It probably also didn't help that Rick's philosophy was "devs should dev and nothing else". While part of that was minimizing the meetings devs should attend (which is a good thing - though not to the extent that Rick enforced that, because he didn't want them in ANY meetings at all), he also nixed during-work-hours social and training events.
So, the CEO, Mike, let him go, which is remarkable because Rick is Mike's best friend. When I first met Rick and Mike, they were devs at the studio I'd just joined eleven years ago; Rick was dev lead, Mike was a junior dev. I'm not sure if they'd known each other before that, but they were quick best friends, built on their mutual love of tabletop miniature games. Mike had been a dev, but his interest was in business. It must have been difficult to have to let Rick go, and I know Rick didn't take it well.
It's only been a couple of months since he left, but things have been changing a lot. First, the developers have now been distributed among the technical managers so that no one manger is overloaded and the devs can get the attention and assistance they need. One of the devs got a hefty pay raise because Rick had never gotten around to doing his review or increasing his salary after nearly three years of employment. That dev is no longer the lowest-paid dev (and possibly the lowest-paid employee - I heard he was making less than I was, which is ridiculous). I'm sure he wasn't the only one. My husband and I also got pay raises out of the blue. My husband reported to Rick but I didn't (I reported to a technical manager who is now the new director of engineering, because I should have reported to the QA manager who is my husband and that's just not right), but apparently Rick had been holding back raises in general.
We're also getting more training opportunities and team-building events. The entire QA team (many of which reported to Rick) were allowed to attend a two-day virtual conference. So, it's getting better. It's just too late for those two (highly-important) devs that left. And I'm not looking forward to running into Rick randomly. That's going to be awkward.
Office reopening...
Most recently, the office re-opened today. The list of rules for coming in, though.... whooo. Interestingly, there's no mask rule, but there's "no gathering in communal areas", "wipe down communal areas after use", "bring your own food, containers, utensils", "minimum 1-hour gap between meetings in conference rooms", and more.
Personally, I'm not going in any time soon, and only part of that is that I still consider our country to be in the grip of a pandemic. My industry doesn't require, for the most part, working in proximity with our colleagues. Is adding all this overhead to our day really worth it? For some people, it'll help (one of the members of the team I'm on really wants to get out of the apartment away from his roommate, so I can see it being helpful for him), but in general, it's not going to add to our productivity and work quality.
Not to mention, I really like being able to roll out of bed, grab a muffin and tea, and get to work. I have not missed losing an hour of my day simply to the commute.
Drama...
A month ago or so now, the company let the director of engineering go, which was a huge surprise. Not from a performance point of view. He (I'll call him Rick) has been ineffective at best, obstructionist at worst.
Rick's a friend from years ago, and he's a great developer, but not so great as a manager. He has old-fashioned views of how to run things that don't work well with the structure of the company. Development-wise, he believes fervently in the waterfall methodology, which, in a nutshell, means that a design for the software is created, then the developers create the software, then QA tests it, and then it's released - the process moves like water over a waterfall.
It sounds great, but it has a lot of problems. First, clients rarely have a coherent idea of what they want created, much less a full detailed design. Second, if they did have a design, it normally takes months to create software, and at the end, the client looks at it and says, "This doesn't solve the problem." Basically, waterfall doesn't really handle change very well, and so you end up either spending a lot of time either doing work that isn't ultimate used or backtracking and rewriting things as new things up. Third, everything's in a phase, so while design is creating the design in the first phase, what are your devs and QA doing?
A large portion of the software industry has adopted some form of Agile methodology to solve some of these problems. Agile, in a nutshell, works in short time periods called sprints, during which the devs create and QA tests a small slice of what the client wants. The client gets to see very quickly if it's what they want, and the next sprint, a new piece is created, or the previous pieces are adjusted, which isn't a huge deal because they're small. Thus, everyone always has work to do, changes can be incorporated without too much upheaval, and the client gets to see things as they are created and not all at once six months later.
Agile isn't perfect, but it's as close to industry-standard as it can be... and Rick is adamant that it can't possibly work (even though most of us have come from companies that run successfully using it). I remember him saying, "No, we're not doing Agile. I'll work on it this weekend and come up with a process that'll work" - that was two years ago and he never did produce it. (Not that I expected him to - he expected to come up with a new, efficient process in a weekend when the industry's specialists have been working on the problem for decades?) We've been using Agile all this time while Rick has been trying to find the Holy Grail of processes.
The other main thing that Rick insisted upon was a flat management structure, which, to him, meant that as director of engineering, all developers reported directly to him, rather than to a middle manager. That might have been good four years ago when the company was founded, but now we have 40+ developers, which means at the very least, that's 40+ hours spent in one-on-one meetings with each developer every two weeks. Not to mention 40+ review cycles every year - even estimating a week of work for preparing an employee's review (which is low), that's over 3/4 of a year of work.
Needless to say, Rick was neglecting his developers. They weren't getting their one-on-ones, they had no one they felt they could talk to, Rick wasn't helping them with their career development, etc. Two of the most important devs on my project quit in the last two months, primarily because of Rick.
It probably also didn't help that Rick's philosophy was "devs should dev and nothing else". While part of that was minimizing the meetings devs should attend (which is a good thing - though not to the extent that Rick enforced that, because he didn't want them in ANY meetings at all), he also nixed during-work-hours social and training events.
So, the CEO, Mike, let him go, which is remarkable because Rick is Mike's best friend. When I first met Rick and Mike, they were devs at the studio I'd just joined eleven years ago; Rick was dev lead, Mike was a junior dev. I'm not sure if they'd known each other before that, but they were quick best friends, built on their mutual love of tabletop miniature games. Mike had been a dev, but his interest was in business. It must have been difficult to have to let Rick go, and I know Rick didn't take it well.
It's only been a couple of months since he left, but things have been changing a lot. First, the developers have now been distributed among the technical managers so that no one manger is overloaded and the devs can get the attention and assistance they need. One of the devs got a hefty pay raise because Rick had never gotten around to doing his review or increasing his salary after nearly three years of employment. That dev is no longer the lowest-paid dev (and possibly the lowest-paid employee - I heard he was making less than I was, which is ridiculous). I'm sure he wasn't the only one. My husband and I also got pay raises out of the blue. My husband reported to Rick but I didn't (I reported to a technical manager who is now the new director of engineering, because I should have reported to the QA manager who is my husband and that's just not right), but apparently Rick had been holding back raises in general.
We're also getting more training opportunities and team-building events. The entire QA team (many of which reported to Rick) were allowed to attend a two-day virtual conference. So, it's getting better. It's just too late for those two (highly-important) devs that left. And I'm not looking forward to running into Rick randomly. That's going to be awkward.
