|
Agreed. On Office vs Remote: This is a really, really difficult one. The company I just left moved to a remote-priority hybrid model, where the office was "heavily suggested" two days a week and "absolutely optional" every other day. As you could imagine, those two statements mean the same thing; its optional every day. I left because I love the office. I love the separation between work and home. I love the drive in; getting time to listen to podcasts or new music. Most of all, I love the company; I love collaborating in person, spontaneous low-stakes communication about little issues in their dev environments or problem solving, stuff that would never make it into Slack, but we're better off talking about it. Not enough of the team feels the same way, so most days it was just me and maybe 3 or 4 other people (out of a dozen+). So, I left to find a company that was more aligned with what I want. But, here's the ironic part: in the frank conversations I had with other team members, many are on the opposite side of the fence. The two-day-a-week "heavily recommended" was too much office time. They want full remote. Some of them were bold enough to just do it; management (and COVID) isn't at the place right now to enforce too harshly. Many still feel guilty about it; how there are people like me going in most days, which is aligned with the corporate mandate, and they're not doing it. One person left, citing this as a deciding reason. Point being, I think any model can work; full office, full remote, or hybrid. No matter what companies do, there will be churn, because every choice is different in some way to what employees have either gotten used to (remote during pandemic -> full office) or what employees miss (full office pre-pandemic -> remote). And if you choose hybrid, you seriously need to enforce it; if you enforce it, some people will be unhappy with the model you pick, but that's better than not enforcing it and causing everyone to be unhappy. On Positive Feedback: For me, it feels the best if its specific feedback not on the basic completion of tasks, but on the quality of completion. Not "Thank you so much for staying late to help with that customer issue", but "The way you solved that customer issue was pretty creative man, thanks for jumping in on that." That feels so much better (for me). One of the big things I took too long to learn, and am still trying to improve in, is understanding how valuable positive peer feedback is. Not just approving great PRs with zero feedback or a "LGTM" "+1" ":thumbsup:"; I love putting line comments in that say genuine positive things I feel about lines, like "That's an awesome solution" or "I didn't know you could do that in typescript" or "I really like this, I'm definitely going to start doing that". The first hurdle I had to cross was, actually, having these thoughts more often; to reframe PR reviews from "its how we control risk on production merges" toward "its an opportunity to help the submitter improve their code" and even further into "its an opportunity for me to stay up-to-date on how the entire codebase is evolving, and how other devs solve problems." Be specific, and be genuine. If I can't give genuine positive feedback, then either: the person I'm giving feedback to isn't really living up to any positive feedback, or in my experience more commonly: I'm not seeing the good in their work and effort, and its my responsibility to improve my ability to recognize it, so I can actually be genuine. |
I've been suspecting for many months that people will end up shifting to workplace styles that match their preferences if they can and this is a good example.