Is your manager just next level laid back? I feel like most places are going to notice and be bothered seeing the yellow circle on your Teams or Slack status consistently for long periods of time.
If managers are spending their days watching the color of the circles next to their team member's names, maybe the managers need more work to do in order to "stay engaged" at work.
Of all the bad heuristics for trying to determine whether someone is being productive, this has to be near the bottom of the list. It's the digital equivalent of measuring engineer productivity by looking around the room and seeing who is at their desk. Except that it can be trivially gamed by a simple mouse jiggler script.
A youtube video won't work for me -- my work computer goes idle if the mouse or keyboard doesn't send input for more than 10 minutes. A lot of my work involves work off of my computer, so I just bought a USB mouse jiggler to keep my computer awake so I still get instant messages from my coworkers when I'm working offline.
Totally agree but from a SWE perspective on any kind of Agile/Scrum team I think the expectation is usually that you pick up another task if you finish early and there's still time during a sprint for example.
This also obviously breeds other bad incentives i.e. the faster you work the more work you get.
It took me about 2 months to learn this after getting my first job. Nowadays I intentionally add minor bugs that turn up during demos so I have stuff to "go back and fix" later.
That sounds... unnecessary. There is always stuff to refactor, and tests to add, folks showing up at the last minute with new requirements. Or you can just wait a day to push commits, etc. More honest, I think.
The point is, that if you demo something and it's perfect, someone in the room is more than likely going to opine about a way it could be even better. Likely not another dev, but a product or biz person. Even if you deflect by saying "that wasn't in the story, but we'll add it to the backlog" that still takes time and unnecessary discussion.
If you leave or introduce some trivially fixable but noticable flaw in the demo, that will (hopefully) get noticed and everyone can feel that they are doing their jobs without needing to make up something.
Refactoring and adding tests can be (and very often are) pushed into the backlog, and then never done. "We'll circle back to that after this sprint (narrator: they would not circle back to it) but for now focus on these new features"
Disagree. This is a misconception junior devs often have... that you need to ask permission to do your job. (Not unless the boss is dysfunctional, in which case it's time to leave.)
Tests and refactoring should be done as part of every ticket and typically don't need to be explicitly called out. This naturally pushes "done" so you don't run out of tickets early.
Yes, but the point of this was to generate (easy) work that others want you to do so they won't ask you to do other (more time-consuming) stuff instead.
You'll have a very different experience telling the product owner you spent the whole week working on bugs that they noticed and they told you to fix (even if you left them in originally on purpose) than telling them you spent all week refactoring code. The former is an instant "great!". The latter is gonna get a concerned look and more questions.
The topic wasn't correctly doing development work, but finding ways to slack off while looking good.
You don't tell non-technical folks technical details, you deliver finished tickets on schedule, which makes them happy. Would you discuss what algo's you used with them? Database schema? No, then talking about unit tests is a non-sequitur as well. Complete snoozefest for non-geeks anyway.
In fact I'd be disappointed by a dev that constantly introduces careless bugs, it's a dev smell. Most bugs should be unique and result from ambiguous/incomplete specs.
Don't agree it is good advice to build a career being dishonest to others. I'm not even a goody-two-shoes... it's just not necessary in all but the most dysfunctional of places.
I agree it's not a great idea, for multiple reasons, but I get why the poster who brought it up would prefer letting bugs slip through to padding everything with more refactoring and adding tests. Deliver features fast(er than you really should be, probably), then coast on some easy bugs for a bit.
External perception of how well a developer is doing often has very little to do with how good a job they're actually doing. I don't think making refactoring and test-making your "easy work" would have the same effect on appearances as the fast-features-and-some-bugs approach, at least at a lot of places.
The only tests we have are some for a project I worked on that I wrote to prove it could be done. Automated testing might as well be dark magic to my coworkers.
> from a SWE perspective on any kind of Agile/Scrum team I think the expectation is usually that you pick up another task if you finish early and there's still time during a sprint for example.
This is true, assuming that:
1. the whole team has approximately equal skill
2. the system is uniform and well-documented
3. the people actually give a shit about the product
If any of these assumptions are not met, then the expectation is naive.
I can't think of any environment that I've been in where this is true. I think the closest I've been was as part of a team of three people where each of us could really handle any task in the codebase. It was also true that there were things that we each cared far more about as individuals, so, in spite of comparable skills, we tended to gravitate to specific stories, anyway.
As a manager, I have every expectation that we won't be doing scrum exactly by the book, but that's totally fine. I'm more concerned about (reasonably) consistently reproducible levels of productivity, not squeezing every point out of a sprint. If there's slack time, great. That seems to be when people are most likely to contribute new stories, learn something new, etc. Besides, rigidly following scrum feels anti-Agile, anyway. People and interactions over tools and processes.
Picking up another task doesn’t mean that it has to be finished. If one lacks skill, they can train. If documentation is missing, one can document whatever they learn. The last one is difficult to address, but not impossible. If team members don’t give a shit about the product, I bet they can still find something they give a shit about that also contributes to the product.
You make a good point. I guess as long as the people are passionate, the first two issues can be, over time, worked through. I guess the tarpit is that the "time" can be really long, especially for (skill-wise) heterogeneous team working on large undocumented projects.
I am definitely willing to concede I may be in a bad situation but are there really teams in Agile frameworks with fibonacci pointing where you can pick up a 3-5 point ticket, finish it before the end of a sprint and not work on anything else?
I don't think you're supposed to do nothing at that point. Leisurely improve your tools, read to improve knowledge/performance, etc. This compounds your efficiency over time, without the stress of more deadlines.
I've seen plenty where a point-a-day pace or somewhat under (maybe 0.8pt/day) would be a totally normal pace, and is absolutely achievable with under half a day of actual work per day, including meetings, if you know what you're doing.
But then again, points are incommensurable between teams.
One thing I've found to be consistently true: Good managers highlight concerns with your performance. Poor managers complain about your hours[1]. If they're complaining about your hours, then there's something else bothering them, but they're using this as a proxy[2]. I don't want to work with managers who are not willing to discuss the real issues. They're a pain to deal with. So I always start looking for another job when this happens.
[1] This is assuming you're not missing meetings, and it's not a role that is customer facing with defined hours (e.g. storefront that's open for an advertised set of hours).
[2] The way to tell, BTW, is there's always someone else who's working less than you're expected to but is getting a pass.
>If they're complaining about your hours, then there's something else bothering them, but they're using this as a proxy[2].
This can also be a sign that the manager doesn't really know what you're doing and/or has not set clear goals for you, so they have nothing else to measure except your hours.
As VP Eng with an org of 35, my CEO was always giving me grief about the number of hours people on my team were in the office. I always pushed back with our milestone tracking. We are on target, and that's all that matters to me. People know what they need to get done, and that's what I want to manage, not hours in the office, vacation balances, or anything else. I'm not their parent. I set expectations, support them in meeting those expectations, and let them make the adult decision about their time.
Ha. I refuse to play the game. I set my slack to away the day I start and never turn it back to green. I've done this at every job during the pandemic. The stupid green bubble vs gray or yellow or whatever is a form of always being at your desk micro management and it isnt productive.
I'll happily explain that to anyone who asks but I've only had a few people ask. Again, if you get your work done most people dont give a shit.
- Set a reminder to go fuck around with your LinkedIn profile for a few minutes every couple months, so at no point are you suddenly active on it (and so, probably thinking about looking for a new job).
- If you have a job in an office with a relaxed dress code (like most devs, probably) make a point of dressing interview-nice at least a couple times a month, from the start. That way it's not notable when you happen to dress nice one day and also happen to take a slightly long lunch....
Huh, for what hide that? Would they proactively fire you?
Here, it is always joked that intentionally giving those signals is the trick to support getting the desired pay raise.. some years ago even saw one guy pulling that off.
The trouble is if you're just idly searching a bit and aren't in a hurry, you might not want your current employer (or co-workers) to start planning to be rid of you soon. At the very least, it might make things awkward.
Its strange but I never worked or can imagine working in such an environment.
When coworkers would learn I'm searching for something else they either understand me and/or try to persuade me not to jump ship. Why should they, lol? And if I go they wish me all the best as I would do to them.
Yep. After a while I disabled notifications, so Slack just doesn't disturb me when working. Sometimes I just quit it completely for an hour or two so I don't look at it because it usually sits on screen 3(the laptop) and I see stuff moving in the corner of my eye.
If someone would question my work ethic or similar because of my Slack status I would explain to them that this is bogus. If they insist, I would complain about them with their boss. If that all is not futile I would just find another job.
I worked at a place where they watched the im dot color to decide whether people were working or not, including expecting you to answer voice calls on the first three rings every time. This place was brain dead. I had to teach people not to call me or not to expect me to pick up, and I built a USB hardware mouse emulator that would move th cursor a couple px left and right while perfectly enumerating as the company’s standard issue mouse.
This place was hands down the worst place I’ve worked at. Nothing was ever getting done, everyone was running with their hair on fire constantly, it was hell. But managers paid a lot of attention to the color of the IM dot instead of, you know, fixing actual problems.
Fuck this place. I don’t miss it. I hope it gets run into the ground by the multiple layers of incompetents at the helm. But it’s unlikely, their customers are in a regulated, captive market.
Use slack on a phone or tablet most of the time, even when actually working. Set a high notification level when "at work" so you are notified even for non-mentions. Bonus: probably the single most power-hungry and memory-eating piece of crap on your laptop, is reduced to using the tiny amount of power it takes to send a push message, on a different device.
Manager here. I do the same thing and I suspect a few of my reports are as well.
As long as they continue to complete their work to my satisfaction level I don’t question them on it. I’ve made clear to them that there’s a few core hours they need to make sure they can be available for meetings with other teams and our 5-10 minute standup is about the only checkin I need. I can already see their git commits and jira history so if I really really wanted to follow along as they go I check that instead of interrupting the devs.
My management might want us to work harder if they found out, but every time they’ve tried to get more productivity without increasing pay there’s been a mini exodus of employees and I think they’ve(consciously or not) picked up on the amount of output they are going to get for their salary.
The common opinion I and other managers I know well enough to speak openly with is that this a fantastic event for good managers and terrible for bad ones. The good ones work load has diminished because we as managers no longer have to do performative micromanagement for our bosses or other managers. Good managers also already were managing against plans or results that don’t change whether remote or in office. The bad managers have had their workload increase because micromanaging remotely doesn’t appear to be a solved problem
Not directly related to your comment, it just triggered a random reflection on micro management...
Being micro managed as a manager is even worse than as an IC - there's a certain level of badgering you have to pass on so you can satisfy higher management, and there's a limit to how much of that you can filter. So you get micromanagement of yourself plus the extra shitty feeling of having to do it to others.
I got out of management for this reason. It was far easier to do my work and otherwise be left alone as an IC. As a manager there were so many meeting that were just there to tell my manager how my reports were doing. It was incredible how much time I spent just relaying tiny updates up and down the chain. Time that could have been spent doing work.
Sure, but what would be their argument against it? "Dev X is pushing his features on time, he's a nice college, always learning from him, but... Ah yeah, but he leaves work 1h before everyone else. Please fire him".
So would it be better for the company for me to take on 1-2 more tickets per sprint and then leave 1+ year sooner from the company because I'm burned out?
Retention isnt talked about often but if companies spent half as much time retaining employees as they do hiring new employees then they would be far better off. A new hire needs 3-6 months before they are going to be as functional as someone who has been with a company for several years.
Sure but I guess depending on the place I'd think unless you had an explicit agreement about leaving early that there would be pushback. "If you have enough free time to leave early you have enough time to pick up another ticket"
Which leads right back to the "screw around until the clock strikes five" road, which leads to stress, boredom and resentment. Humans are not machines. 100% efficiency is a pointy-haired manager's pipe dream.
I've left these "time to lean, time to clean" jobs in the dustbin of my teens where they belong. It's a seller's market for us geeks right now; we should take advantage of it while it lasts and find good conditions for ourselves to work in.
I put together these questions for my job search and they have worked ok for me.
"What has turnover looked like in the past year?"
Sweat shops have high turnover, press for a number for this question.
"What are your on call expectations? How do you manage incidents out of hours? How frequently do incidents like that happen?"
If they don't mention comp time or anything like that during those three questions they probably don't offer it, and if incidents happen with any frequency you can assume you will work a good bit of unplanned overtime.
"How is my work evaluated?"
The harder the criteria here the less likely they use butts in seats management. If it's someone vauge about "how well you collaborate with the team" or similar it's probably a subjective measure probably related to if your butt is where they expect it to be when they look.
Sure, I have time enough to pick up another ticket at 3:30pm. I also have time to fuck it up because I've already racked my brain fixing two other tickets, attending a morning standup, and sitting through a company-wide DEI webinar when I should have been having lunch.
So, what would you prefer? That I clock out early because I've put in a solid day's work despite not getting to have lunch, or that I do a half-assed job just to look busy that I'll just have to revert and fix the next morning?
One gets so utterly weary of all this Taylorist bullshit that managers get in the process of earning their MBAs.
As a manager - my work habits look pretty similar. If you don't trust your peers or reports, such that you need to monitor the specific hours they're doing asynchronous/solo work, then that's a problem.
The challenge is actually getting people to take advantage of this. I work with folks who default to overworking, so I have to be pretty insistent that they take time for themselves.
I currently have a manager like you and honestly this is worth a lot. It's basically part of my compensation, almost like being paid in time.
The peace of mind that comes with knowing that when I say "Hey, sorry, I need to take Wednesday off" the reply will be "Hope you've got something fun planned!" instead of the likes of "Hmm, well, we were ahead last sprint so if we slip this one it's okay" is incalculable. (I probably don't have something fun planned, but the sentiment is appreciated.)
Yup. I've left most jobs in the past because of a bad to okay manager. I've stayed at jobs that honestly I should have left sooner because of great managers.
Good managers help you improve your skills, give you meaningful feedback, facilitate work getting done, and get out of your way.
I use it as a recruiting tool. I can’t compete with FAANG salaries so one thing I do is make it clear performance objectives are accomplishment based not time based.
Most of the time my team has a good work life balance. They will all buckle up if shit hits the fan then we go back into normal mode.
Totally. Right now we have a few tickets in the sprint that have hard deadlines. I'm actually excited to work on them because its a bit of a challenge. Most of our tickets, like most tickets regardless of if people want to admit it or not, don't have hard deadlines so we can actually get things done in a reasonable timeframe.
I don't think there is a single thing that helps retention better than WLB. Comp is a close second but someone will always pay better that you. You cant win that battle. WLB is hard to screen for while interviewing so when you find it you are less likely to take a chance on losing it by taking a new job.
In microsoft teams you can schedule "focus" time for a max of 4 hours. This acts like DnD and books your calendar. What I did was copy the same slots into 2 more 4 hour slots. So every day I'm busy for 12 hours with DnD. It does not go to the yellow status during that time. Win-win situation if you have shitty management :P
