One of the issues I've had that isn't mentioned here is the value of mutual trust. Communication and trust are the two cornerstones of a really solid manager <-> managee relationship in my experience. Whether that lack of trust manifests itself as micro-management, constant check-ins, or a constant threat of surveillance it can easily turn an above average performer into an apathetic and demoralized employee.
I used to work remotely for a company that spanned more than a few timezones, with a wonderful daily team manager and a not-so-great weekly department manager. Learning that my minutes and output were constantly monitored completely destroyed my trust with the latter, and had me searching within the week. My reaction to that was so strong I actually considered it a fortune when I was laid off for unrelated reasons rather than having to quit.
I would be reprimanded for signing on five minutes later than usual despite being on a team of individuals that spanned multiple countries, and would get a questioning ping if I was offline for more than 10 minutes (especially problematic if you're the type of programmer to write or plan code on the whiteboard / paper first). Extremely draining to deal with that sort of nonsense and mistrust.
Please, managers of the world, trust your employees! You have performance metrics for a reason!
IME this kind of experience comes when you have a manager who has no fundamental understanding of what it is that they are managing and has no particular reason to trust you.
A manager who can monitor your output by reading your pull requests simply won't engage in this type of behavior whereas a manager who can't will usually instinctively gravitate to terrible metrics like "does he show dedication by being in at 9am rather than 9:05am"?
Managers should form a very deep understanding of whom to trust and why or understand on a very deep level what it is that they are managing.
Managers who cannot do either of those things should be terminated with prejudice.
>You have performance metrics for a reason!
As far as developing software goes, every single performance metric is terrible.
The argument made is that being a "good employee" and following the rules is a signal to your employer that you're willing to make personal sacrifices to be dependable - the implication being that someone who follows the rules almost all the time is by necessity sacrificing some part of their personal interest.
It's just that, though - managers want dependability as much as they want competence, sometimes more so. This may or may not be good for the company depending on the company. If the leverage of each employee (in terms of their ability to affect the bottom line) is small, then dependability is far more important. If the leverage is high, then the employee's results dominate - the employee can come in whenever they want wearing whatever they want and say anything they want, as long as they make it rain.
Thank you for that. I think the takeaway for some of the other commentators here is that if you are getting flack for coming in late, it means you are not the type of employee who can really effect the bottom line.
That is not a judgement, not everyone can effect the bottom line and it is not guaranteed that everyone finds themselves in that position over the course of their career.
But, if you have a manager who keeps telling you what a big effect you're having (perhaps to justify a lower salary or discourage a move to a new role) but also gives you flack for coming in late, it should shine a light on the truth as to how they see your role.
> The argument made is that being a "good employee" [...] is a signal to your employer that you're willing to make personal sacrifices to be dependable
It would be nice if the employer was giving symmetric signal to be
a dependable party that will not throw you under the bus for a mildly
controversial statement nor lay off at first financial bump.
>Is turning up on time for your job a terrible metric?
The worst metric.
That is, unless the "turning up on time" is actually causing a serious and recognizable problem. Then it's the problem that's a problem.
>As the initial commenter said: trust goes both ways.
No it doesn't. If you put the onus on the developer and say "not only do you have to deliver high quality code you have to make me trust that you've delivered high quality code by adhering to these arbitrary metrics I've come up which bear no intrinsic relationship to how you do your job" you're admitting incompetence as a manager.
It's a manager's job to know whom to trust and a manager that trusts the useless developer who turns up at 9am sharp over the excellent developer who turns up at 9:05am requires termination.
>Actually, turning up on time may not make your manager trust you more, but turning up late will definitely make them trust you less.
It will definitely make a bad manager trust you less.
A good manager will either recognize that you're delivering or not.
> A good manager will either recognize that you're delivering or not.
And a great manager will evaluate the wider effects of your behavior on the whole team and over a long timescale. If you being late to your job causes others to start doing the same, and if your manager cuts you slack because you are a "high performer" then social dynamics come into play that must be...well...managed! Performance also slips over time. People get spoiled, sometimes depressed, sometimes lazy.
Managers look at whole teams and long-term trends. Stop focusing on yourself and the immediate moment. Success is a marathon, not a sprint, and requires careful, regular progress.
> If you being late to your job causes others to start doing the same
You're missing the point entirely: Who cares if they're also late?
Short of them being late to something important like a meeting, it seriously couldn't matter less than any of the thousand other things you should focus on as a manager.
Unless you work in something with external time pressures (e.g. I used to work in equities and US market hours dictated our need to be available) there's no reason it should matter whether someone shows up at 9 or 9:45. If you're really worried about people missing each other, set core hours (11-3 say) where everyone's expected to be available.
>If you being late to your job causes others to start doing the same
If they also are producing and not causing other people problems then I see no problem.
However, if they are not producing then that is a problem. However, if they are coming in on time and not producing that is exactly the same problem.
The point is that one problem is unrelated to the other.
>social dynamics come into play
Social dynamics always come into play but in this instance, they really don't matter. If a manager knows how well everybody is performing and is communicating that then these other intra-team dynamics you are talking about simply don't happen.
It seems to me that you're coming at this from the perspective of a manager who fundamentally does not understand what they are managing and isn't cognizant of who is performing and obviously isn't communicating that because they don't know.
Because that's exactly when you would see the intra-team dynamics which you're describing will happen. That is what happens on most software teams, sadly :(
>Success is a marathon, not a sprint
I never said or implied that it was anything else.
>Stop focusing on yourself and the immediate moment.
I am focusing on neither.
I am beginning to suspect that you are exactly the kind of manager I'm talking about here. Hi.
That's kind of what I meant when I wrote "unless the "turning up on time" is actually causing a serious and recognizable problem. Then it's that problem that's a problem".
Yes, for IT support type roles I think measuring online availability as one aspect of job performance is legitimate.
In software engineering, many companies prioritise "getting your work done" (which is admittedly a subjective, hard-to-quantify metric) and consider any metric that contradicts it to be suspect.
A person who believes this would say that if according to policy my best employee should work 9am-5pm, but he prefers to work from 7am-3pm and is my best employee, it is the policy not the employee that needs changing.
Personally, I always try to get to the bottom of this stuff during job interviews - nobody wins if the employee assumes there will be flex-time and the company doesn't allow it!
This. I've literally never held a job that wasn't okay flex time, and I've worked at 4 radically different types of companies as a software engineer over the last 7 years.
I'll be honest, I was surprised to read this sorry if environment still existed for programmers
I think the criteria should be turn up on time when it matters. If there is a staff meeting scheduled at 9.30, don't show up at 9.45. Otherwise I agree that day to day most places shouldn't care
At one workplace, the manager instituted a daily all-hands meeting starting at 8:45 AM. But of course you still have flexible working hours; you just have to show up for this one meeting whose start time can't be changed because there definitely are reasons.
Yes, I was already interviewing at other places when that happened.
If you are in Germany, yes there is. I had horrendous experiences in different companies. 5 Mins late was a real offender.
Until I got hang of a manager and I asked what is this nonsense. He told me, he used to work as a manager in real industry and really really cannot comprehend why programmers "whine" so much about this. All his workers started the work at exact 8am so that the parts quota of the day would be achieved. I got no comment and after two weeks I just resigned...
At every company, my own managers have exorcised far more blatant use of flex time than I've ever needed. If I'd ever received any guff (which I haven't) for my own needs, they would have gotten a deserved ear-full.
Flex time shouldn't mean that you show up sometime between 8 and 11. You should be at work within some sort of reasonably consistent window barring unforeseen circumstances.
When you let people run wild, you end up with angry people anyway as gold-brickers will always take advantage of the system. Communications and accountability break down as you can never have all parties involved in a matter in the same place or same phone call at the same time. I've worked in places where people get wacky because the guy who supposedly works 6-2 really is around from 8-1.
I disagree. I trust my people. We all understand the idea that you get your work done. This gives them the flexibility to do what they need to do for their life. I have one guy that signs off a couple of hours a week during the fall to tend to his home/farm. I have another that takes time to make sure his girlfriend can make it to her Dr. appointment. These are also the people that I see working at midnight or such finishing things, because they realize at 8 p.m. they know how to fix something.
The key for us is communication. We make sure that each of us knows what the other is doing. Sure we have meetings every once in a while that we know we need to all meet, but for the most part we center our communication around ways to make sure that we can leave a message and they can get back to us when they can.
Showing up sometime between 8 and 11 is unreasonable, because it prevents people to come sooner then at 8. It should have been "sometime between 6 and 11" to be proper.
Also since people know the guy in your story is not working enough, it should be easy to check on him couple of times and then fire him.
Our practice is that you can pick your own consistent start time between 7-9. You can also do things like compress your week to 4 10 hour days or add an hour to get a day every two weeks. We don't want you in the office after 6 on anything approaching a regular basis. You can vary the time by day, which is common for childcare or other outside demands on your time.
If your habit is a 5 hour start window for an 8 hour workday, you're not going to work out.
>"getting your work done" (which is admittedly a subjective, hard-to-quantify metric)
Getting "work done" is fairly easy to recognize - you can tell when bugs are getting fixed and features are being delivered and when they are not.
Getting work done to a high standard and delivered at an appropriate speed is, I think, only recognizable by another developer who is as good or better than you.
>Personally, I always try to get to the bottom of this stuff during job interviews - nobody wins if the employee assumes there will be flex-time and the company doesn't allow it!
Yeah, that's one of my red flags during interviews. Companies that are strict on this type of stuff are essentially advertising the fact that management is clueless about what development does and rely upon intrinsically meaningless social cues to build trust. Like suits.
This seems like it would be subjective but it actually tells a story. Most likely tickets aren't being broken down enough, one employee could be snagging easy bug tickets in the morning and another employee could be working on a epic feature.
On the other side of things I have a guy at work who rocks out 20 tickets and a guy at work who tries to go into super plan mode and take his time and make sure every semicolon is perfect 20 times. This is ok, it's what management is for I need to make sure the fast guy is a little more careful sometimes and I need to check on mr planner and make sure he speeds it up sometimes.
One time I got laid off for not closing enough stories. Meanwhile the guy that was kept on was the source of a lot of bugs. So what is that if you generate your own problems and "solve" them?
That's a different problem from the one Planning Poker addresses.
But to answer your question, the original story should have acceptance criteria such that the ticket can't be closed if there are bugs. Failing that, the bug ticket should be linked to the original ticket.
Continual feedback is also important. If the manager who laid you off valued velocity over bug-free code, that should have been communicated way earlier.
Alice works with both of them, and knows that the one ticket Dave is working on requires a lot of refactoring work to solve it nicely.
Or knows that Bob is just that good. Or Dave's having a bad week because of X.
Direct superiors tend to have at least a vague idea of what is happening, along with a certain level of trust. These two make it less likely for the answer to your question to be as ambiguous. At least for ballpark estimates of whether one should be worried.
Metrics should always be supplemented with communication. If Dave's performance is under question, talk to him and find out his progress on the one ticket he's been working on.
EDIT: realized after posting that multiple people made this point. Just goes to show that it should be common sense.
OK, I'll give an example. My team leader in a previous job used to regularly turn up at 11am (officially we were supposed to be in by 9.30, but it was academia and no one complained too much). I was usually in before 9.15 - like the majority of the staff.
So sometimes I would need to ask him something, and he wasn't around - that would hold me up.
Sometimes other people would need to ask him something. He wasn't around, so they asked me instead - usually when I was trying to get in the zone.
I am all for giving staff flexibility but it should not come at an expense to productivity.
Remote, timezone-distributed teams deal with this all the time. We always ensure everyone has a bunch of work they can do, and we use email/chat to handle the asynchronous communication issue. What you described isn't a scheduling issue, it's a communication issue. Not on your part, either, BTW.
I wrote the parent post. Here are my reflections on the responses (which were insightful as always).
Regarding turning up on time and professionalism - For me the main component of professionalism isn't trust but respect.
Demanding an employee arrive by a certain time may or may not be a good way to run a business (up for discussion), but, once you as the employee have agreed to do so then consistently being late is a sign of disrespect. Part of how I would define professionalism is doing what you have agreed to do (or making a good faith attempt, even if not possible). If you still think it's unreasonable, consider if your employer paid you a couple of days late - is this still ok?
A lot of the comments mentioned what they consider to be attributes of a good manager, but only from their perspective as someone being managed. To me a bad manager would be someone who allows a centralization of knowledge in one person, so much so that that person can start to behave in a disrespectful manner (YMMV).
Some programmers have the attitude that they are indispensable and can behave anyway they like. There is a certain irony in the fact that we optimize/destroy other peoples jobs for a living but don't consider the possibility that it will end up happening to us - other professions are not as forgiving of some of the behaviours we might consider normal or fair.
Please let me know what you think (lessons on grammar also welcome).
What I'm reading here is that you're perceiving it (perhaps accurately, perhaps not) as a threat to one's dominance as manager.
I think you may be using the word respect as, say, a capo would - as in, "respect the chain of command" or as cartman would say "respect mah authoritah"!
If true, then that signals a certain level of insecurity over one's position which I think may be an unfortunate signal to send. As an employee I would see that as weakness, especially if combined with technical incompetence.
>If you still think it's unreasonable, consider if your employer paid you a couple of days late - is this still ok?
It's funny, an employer actually asked me that in my first job and I shrugged my shoulders and I said I probably wouldn't notice, which was an answer that clearly infuriated him.
He later fired me (a real blessing in disguise), and the last chunk of pay actually did come in about 4 days late - something I was keeping a close eye on because I was concerned he may not pay me at all. I am absolutely convinced it was him being spiteful - he did payroll himself and there was no other reason I could see for it being late.
I had a good chuckle over that one.
>Some programmers have the attitude that they are indispensable and can behave anyway they like.
Often it's because they are and they can. I mean, nobody's indispensable of course, but the nature of what they do means that they can create (or destroy) a lot of value and don't have much of a reason to fear termination. This tension between that and managerial refusal to recognize it because it signals a threat to their dominance has, I think, been the result of a lot of self destructive behavior in this industry. A lot of people would rather feel powerful than keep a healthy bottom line. Their prerogative, I suppose. It's good to recognize this and point it out when it happens though, because, for instance, as a shareholder I wouldn't want to be bullshitted about what went down.
I can certainly see how you could interpret my remarks on disrespect as "perceiving it (...) as a threat to one's dominance", but this was certainly not my intention.
My context is of never having had a 'bad' manager, they have always been agreeable and pleasant with a good technical understanding and (I can only assume) high self-esteem.
I think I have used the word respect in two slightly different ways: one when describing employer/employee relationship and one where describing manager/managed.
When I talk about disrespect in the context of a manager I mean it on more of an interpersonal relationship level, not as a struggle for dominance in some sort of power structure.
> "...As an employee I would see that as weakness, especially if combined with technical incompetence."
Adding the bit about "technical incompetence" sound to me like you are projecting certain other attributes on the hypothetical manager that we are discussing. What has been your experience with managers?
> "It's funny, an employer actually asked me that in my first job and I shrugged my shoulders and I said I probably wouldn't notice, which was an answer that clearly infuriated him."
When you have few bills to pay and/or other obligations then this attitude is fine, but I think for a large group of people (e.g. with families to support) this would be a real problem.
The point I was trying to make in the paragraph about "programmers acting any way they like" was that this may be an accept/successful strategy in the short term, but it may not be optimal long term. However indispensable you are now there is someone somewhere out there looking to optimize your job or make your skill set irrelevant. It's certainly possible that you are the exception and that no one will be able to do this to you, but I don't think that it applies to the majority of people reading this thread (I know it doesn't apply to me).
It seems like you view the employer/employee relationship in a very adversarial way, rather than an optimal way for both parties to get something they want. I have had jobs in the past (mainly part time service worker type jobs) where I feel that this attitude is valid. However, most companies I have worked for as a programmer have been small/medium level and started/funded by the same people (no VC money, no faceless career CEO or public shareholders). In these situations I have found that there is no calculated malice or attempt to 'enslave' you, just a few motivated people putting their own money and future on the line to try and make something of value and better themselves.
> "By his definition, you think programmers are "too free", no?"
No, I think a lot of programmers think that they are "too free", but are in-fact only "short term too free"
>When I talk about disrespect in the context of a manager I mean it on more of an interpersonal relationship level, not as a struggle for dominance in some sort of power structure.
Except the manager/employee relationship is fundamentally about dominance in a power structure so I don't see how you can separate the two.
Think about it this way: absent any kind of inconvenience (like an interrupted meeting), would a manager ever apologize to an employee for coming in at 9:05am?
If the answer is yes, this may be about mutual respect. Since the answer is no, this is intrinsically about respecting the chain of command.
>Adding the bit about "technical incompetence" sound to me like you are projecting certain other attributes on the hypothetical manager that we are discussing. What has been your experience with managers?
Yes, I am. Because, in my experience, there has always been a strong correlation between one attribute and the other. As in, mild technical competence usually means that they care, but not hugely and deep technical incompetence means they end up caring a ton.
>When you have few bills to pay and/or other obligations then this attitude is fine
I'm aware others can not afford this attitude because they are up against the wall with credit card debt, mortgages and kids and whatnot but as far as I see it the point you and my previous boss were making was a rhetorical one. Point being that it doesn't work as a rhetorical question because I really didn't mind.
I think there may have been some sort of implied threat there - i.e. "you fulfill your end of the bargain by coming in before 9:05am and I'll fulfill mine by not paying you a day late". And I was like, ok, pay me a day late then.
>The point I was trying to make in the paragraph about "programmers acting any way they like" was that this may be an accept/successful strategy in the short term, but it may not be optimal long term. However indispensable you are now there is someone somewhere out there looking to optimize your job or make your skill set irrelevant.
Ok, so now you've branched on to a different topic. I agree that this is the case, but they will keep trying to do that however servile you act and behaving like a slave isn't going to stop it from happening. While they are trying to optimize your job and make your skill set irrelevant, you should instead be trying to optimize your performance and make your skill set more and more relevant while maintaining a healthy savings buffer that protects against unemployment.
As far as I can tell the biggest threats are actually directed at those with the least relative power.
>It seems like you view the employer/employee relationship in a very adversarial way
Yes. The largest military uprising in the United States since the civil war (battle of blair mountain) was fundamentally an employee/employer conflict. The relationship is a naturally adversarial and naturally parasitic. That doesn't mean it has to be all about that in every instance, but that is still its natural tendency.
>I have had jobs in the past (mainly part time service worker type jobs) where I feel that this attitude is valid. However, most companies I have worked for as a programmer have been small/medium level and started/funded by the same people (no VC money, no faceless career CEO or public shareholders). In these situations I have found that there is no calculated malice or attempt to 'enslave' you
I think that is in and of itself an artefact of the difference in power disparity. As a programmer you had more power so they didn't feel like they could fuck with you with impunity. As a part time service worker they could so they did.
I think some of those nice people you worked with might have changed their tune had they seen your relative power slipping. I have definitely seen this happen.
> Is turning up on time for your job a terrible metric?
Most devs are "round the clock" employees even though their job doesn't explicitly say so. If a serious production crisis happens at 3:00AM, all hands are on deck.
Only at dysfunctional companies. If you need round the clock coverage, you need to set up an on-call rotation. Expecting employees to be available 24/7 is completely unreasonable.
There are lots of 'Professionals' who turn up on time, but turn theire head off while on the time, so you get nothing from mere body presence but billable hours.
An old co-worker of mine used to work for a company that made flight simulators. He said his manager would stand in the front foyer on the 2nd floor and make notes of who arrived after 9:00am.
I would have fun trolling such a boss. When I was younger, I would stress about job security; work OT whenever asked, say yes to every request, etc.
Now that I'm in my late 30s... I'm finding I have more self-confidence than I've ever had in my life. Couple that with a general sense of professional ennui that's been steadily building over the last few years, and you get someone who just doesn't care if you fire him and acts accordingly.
This is very true in india. Almost most of the managers go in to management because they can't code and to evalulate an employee they take every metric other than looking in to the commits.
But also for teams to be successful, employees have to be able to trust their managers. I just quit a job after a month because, within that short time, my manager twice misrepresented the scope of a task so he could either leave early or have the day off.
I knew after those incidents that there was no point in continuing. It would be foolish to trust someone in any larger way who would casually treat a new employee in that fashion.
I used to work remotely for a company that spanned more than a few timezones, with a wonderful daily team manager and a not-so-great weekly department manager. Learning that my minutes and output were constantly monitored completely destroyed my trust with the latter, and had me searching within the week. My reaction to that was so strong I actually considered it a fortune when I was laid off for unrelated reasons rather than having to quit.
I would be reprimanded for signing on five minutes later than usual despite being on a team of individuals that spanned multiple countries, and would get a questioning ping if I was offline for more than 10 minutes (especially problematic if you're the type of programmer to write or plan code on the whiteboard / paper first). Extremely draining to deal with that sort of nonsense and mistrust.
Please, managers of the world, trust your employees! You have performance metrics for a reason!