10 ms·

Give me clear goals which are measurable, and I will get things done either remotely or on-site. It doesn't matter which one. This is a win-win situation becaus

Give me clear goals which are measurable, and I will get things done either remotely or on-site. It doesn't matter which one. This is a win-win situation because my manager can track my progress based on the previously setup measurements. And to achieve this, location is irrelevant. Things usually start turning south when managers just simply demand speed. Or eagerness. Or dedication. Or other bullshit which has no relevance regarding any specific task. These are the cases which brilliantly show the lack of management skills. These are the kind of little men who demand you to be at the office all time. You can call them control freaks, or micro-management fetishists. It doesn't matter. These people just show one thing with their behaviour: that they don't trust their subordinates.

bluGill 9y ago
That is technically true, but you do NOT want clear goals though. Clear goals are for junior "code monkeys" who just do what they are told without any concern for if they are going the right thing. If you want input into your work and the feeling that you are actually doing the right thing you need to have the context around your goals. Your physical presence in the offices lets you take part in "water cooler" and "hallway" conversations with various people. Yes you can do some of that via email, forums, and the like. However the human factor of your presence changes the tone of the conversation. It isn't just you either, the other person(s) involved. When you have a short, critical, task that needs to be done fast, then staying home without a phone or email is the best way to get it done fast. However for anything else communication is an important part of your job and physical presence aids that. That isn't to say remote work cannot - it does. However there are real disadvantages to it that need to be considered.
- fogetti 9y ago
  And what would be those disadvantages? You listed things which you think are supporting the arguments to be present in the office. But one argument which is supporting on-site presence, doesn't make it automatically an argument against working remotely. And you are basically trying to put words in my mouth. I didn't say a word that I will do what I am told without concern. That's only your implication. Correct me if I am wrong, but you imply that because requirements are usually unclear: that means that clear goals are undesirable. Does that sound logical to you? Because to me that's a big no-no. I only saw people pushing this kind of mentality who like to fish in troubled waters and enjoy the mess to take advantage of it for their own sake (i.e. climbing corporate ladders). And let me highlight one thing: if I am supposed to clear things up and organize my work, than what is my manager supposed to do? In this world that you imagined there is no role for a manager IMO. And that would be pretty much fine with me. It's just far from reality. I won't subscribe to the idea that the office is a rainbow colored fairytale. I am coming from the exact opposite direction of thinking.
  - sidlls 9y ago
    Just about anyone writing code in this industry can learn to implement, given a blueprint. Not everyone can learn to generate the blueprint. The former takes some marginal ability to memorize facts and to recognize patterns. The latter takes the ability to truly understand a problem and orchestrate the pieces of a solution together, some of which will be tasks ("clear goals") for a coder to implement. It's the (or at least one) difference between perpetually solving homework from CS and being an engineer. Can't speak for GP, but my view is the latter can't be accomplished without some direct, in person interaction today. The future, with more robust collaboration tools, may be different.
  - dalbasal 9y ago
    Not that it is undesireable, just that it doesn't exist. The mess you are talking about is fact. Maybe this is because managment sucks, but it's still a fact. Goals & requirements are unclear. This is a fact almost everywhere. Very few people (definitely programmers) have very clear requirements and goals to work against. So, I agree with you that having clear goals and requirements is a path to virtual workplaces. But, I think this is a troublesome route. Clarity is elusive. If it wasn't elusive, all the outsourcing efforts of 10 years ago would have been more successful. Computers are against us on this. If something is very clearly defined, it is a candidate for automation, outsourcing and such. The stuff we're left with is the poorly defined mess. That's why we have so much of it.
  - lloeki 9y ago
    "Clear goals" can have different levels of abstraction. Junior code monkeys may need finely grained detailed steps while climbing the technical, architectural or management ladder will make your goals more abstract as they encompass greater breadth and depth, yet them not being any less clear. "Steer team to deliver product A in 3 months with top quality" or "provide analysis of strange crash events P, Q, R that appear to be vaguely related and originate in lib K, and propose possible short-term mitigation tactics as well as systemwide refactoring strategies to reduce or remove dependency on regularly problematic but heavily used lib K within a mid-term timeframe, and we'll talk about your conclusions in two weeks" can be just as clear to some people as "implement method foo doing X according to spec point Y.Z by the end of the day" is to others.
- intoverflow2 9y ago
  > Clear goals are for junior "code monkeys" who just do what they are told without any concern for if they are going the right thing. Agree 100%, the less you act like a cog in a machine the less people will treat you like one. Lots of developers seem to want to log in to a system every day and just have a list of tasks they have to complete without any real collaboration or divergent thought and have their salary calculated by % of task completion. In my experience the people who collaborate in the office and try to push things further are the ones easily granted autonomy and no longer have to answer to micromanagement. Managers can see the difference between a box ticker and the breakouts that are actually making a difference at the company, once you achieve that then you'll notice people stop questioning what time you turn up to the office if at all.
  - tiggybear 9y ago
    You can act like you're not a cog, but there's only so much autonomy you get working under someone else. If you're an employee you are a "code monkey" to one degree or another. If you do not need clear goals, Work for yourself. You don't need dozens of people above you telling you what to do and extracting part of your paycheck if you can figure it out and execute it on your own.
    - bluGill 9y ago
      The CEO of my company doesn't tell me what to do. He tells a vice president who tells [skip a dozen or so layers of management] who tells my boss who tells me. Part of my job is to go on down the line - I'm expected to feed work to a half a dozen junior engineers (there are other senior engineers on my team who also are expected to find work to feed on down the chain). Each level of the chain requires understanding of what the business needs. I need to make autonomous decisions every day that ultimately the CEO stands behind. The composite of all the good decisions (enough better be good) results in the success of my company and the CEO will take credit for it. However all the CEO says to me is "we will be the global leader in [the generic area my project is in]" in an all company meeting. Every step down the chain has just been filling in details.
    - intoverflow2 9y ago
- sidlls 9y ago
  > Clear goals are for junior "code monkeys" who just do what they are told without any concern for if they are going the right thing. Most of the interview processes in tech are geared towards hiring for this exact role. There's some ego stroking involved, but for the most part the sorts of "code trivia" questions candidates jump through are basically "can you implement this algorithm or data structure" correctly. They don't actually test problem solving ability. So it seems to me for he kinds of trivial work most of us in the industry are doing your objection is a bit immaterial. Some of us are engaged in more complex work, and I agree 100% with you about that. Remote doesn't quite cut it most of the time for that sort of thing.
- taeric 9y ago
  I think this is confusing goals with tasks. And even then, sometimes you still want a mix of both. A nice backlog of tasks that need done along with high level goals we'd like to achieve (but no solid tasking to make happen) is a beautiful thing. Unfortunately, it isn't free and takes effort. Which is a large part of what a manager should help with.
- perpetualcrayon 9y ago
  I find that even when given "goals" in a broad sense, when you break down the problem into its constituent parts there generally is very little to debate. And when there is something to debate, those conversations take time to accumulate information and research, and for people to "digest" them completely. I find that in-person discussions about said topics is more counter-productive than productive since in-person meetings sometimes inadvertently suggests you have a fixed time-frame within which to come to a conclusion. And the "debatable" topics generally aren't going to be acted on immediately. There needs to be coordination and planning when you all come to a conclusion that a particular strategy is going to be the way forward, and a lot of times assumes you're probably going to break backward compatibility so it won't be released until a major version bump.
- eikenberry 9y ago
  I would say there are trade-offs with remote based communications with distinct advantages you don't mention that help make up for the lack of the human factor. The most obvious is that it eliminates the human factor, which can make it a lot easier to work with people who have unpleasant personalities. It also makes all communications more asynchronous, which means you can discuss things at the pace needed instead of the forced sync of a person staring at you. Then there are all the technical benefits, like cut-n-paste, live URLs, screen sharing, logs of conversations, etc. It also sounds like you haven't experienced a fully remote team working. You don't miss out on the physical presence because it is not there to miss and people make up for that absence in other ways. All the water-cooler/hallway conversations are then there, online, in the chat rooms or what not.
- kureikain 9y ago
  > Clear goals are for junior "code monkeys" who just do what they are told without any concern for if they are going the right thing. Yeah, this is so true. I think the task with an clear process to do it have an clear goal. But other than that, tasks that's very vague such as design an API, design schema to efficient some kind of certain query usually requires a bit of art, and we learn from the mistake/success of last similar project to improve this one.
yawz 9y ago
> Give me clear goals... Arguably, I need talented individuals forming good teams to clarify the goals and to have direct input to the roadmap. Reducing people to implementors may not be great for morale, motivation and engagement. Some people want their input to be more than their code, and rightly so.
- fogetti 9y ago
  You are implying things which I didn't say. See my previous answer to bluGill.
dalbasal 9y ago
If you have very clear goals, tasks and visibility, a lot of stuff is possible. Flexible, hours, flexible locations, contracting. At the extreme end of that statement, you might even say that if goals and tasks are welll enough defined, post-work-AI-automation-Jeremy-Corbyn. :) For most jobs, tasks and goals are not clearly defined. That's why managing and being managed is hard.
whipoodle 9y ago
If conditions were amenable enough, I'd work in a factory too. (I'm being serious, I would.)

bluGill 9y ago

That is technically true, but you do NOT want clear goals though. Clear goals are for junior "code monkeys" who just do what they are told without any concern for if they are going the right thing. If you want input into your work and the feeling that you are actually doing the right thing you need to have the context around your goals. Your physical presence in the offices lets you take part in "water cooler" and "hallway" conversations with various people. Yes you can do some of that via email, forums, and the like. However the human factor of your presence changes the tone of the conversation. It isn't just you either, the other person(s) involved. When you have a short, critical, task that needs to be done fast, then staying home without a phone or email is the best way to get it done fast. However for anything else communication is an important part of your job and physical presence aids that. That isn't to say remote work cannot - it does. However there are real disadvantages to it that need to be considered.

fogetti 9y ago
And what would be those disadvantages? You listed things which you think are supporting the arguments to be present in the office. But one argument which is supporting on-site presence, doesn't make it automatically an argument against working remotely. And you are basically trying to put words in my mouth. I didn't say a word that I will do what I am told without concern. That's only your implication. Correct me if I am wrong, but you imply that because requirements are usually unclear: that means that clear goals are undesirable. Does that sound logical to you? Because to me that's a big no-no. I only saw people pushing this kind of mentality who like to fish in troubled waters and enjoy the mess to take advantage of it for their own sake (i.e. climbing corporate ladders). And let me highlight one thing: if I am supposed to clear things up and organize my work, than what is my manager supposed to do? In this world that you imagined there is no role for a manager IMO. And that would be pretty much fine with me. It's just far from reality. I won't subscribe to the idea that the office is a rainbow colored fairytale. I am coming from the exact opposite direction of thinking.
- sidlls 9y ago
  Just about anyone writing code in this industry can learn to implement, given a blueprint. Not everyone can learn to generate the blueprint. The former takes some marginal ability to memorize facts and to recognize patterns. The latter takes the ability to truly understand a problem and orchestrate the pieces of a solution together, some of which will be tasks ("clear goals") for a coder to implement. It's the (or at least one) difference between perpetually solving homework from CS and being an engineer. Can't speak for GP, but my view is the latter can't be accomplished without some direct, in person interaction today. The future, with more robust collaboration tools, may be different.
- dalbasal 9y ago
  Not that it is undesireable, just that it doesn't exist. The mess you are talking about is fact. Maybe this is because managment sucks, but it's still a fact. Goals & requirements are unclear. This is a fact almost everywhere. Very few people (definitely programmers) have very clear requirements and goals to work against. So, I agree with you that having clear goals and requirements is a path to virtual workplaces. But, I think this is a troublesome route. Clarity is elusive. If it wasn't elusive, all the outsourcing efforts of 10 years ago would have been more successful. Computers are against us on this. If something is very clearly defined, it is a candidate for automation, outsourcing and such. The stuff we're left with is the poorly defined mess. That's why we have so much of it.
- lloeki 9y ago
  "Clear goals" can have different levels of abstraction. Junior code monkeys may need finely grained detailed steps while climbing the technical, architectural or management ladder will make your goals more abstract as they encompass greater breadth and depth, yet them not being any less clear. "Steer team to deliver product A in 3 months with top quality" or "provide analysis of strange crash events P, Q, R that appear to be vaguely related and originate in lib K, and propose possible short-term mitigation tactics as well as systemwide refactoring strategies to reduce or remove dependency on regularly problematic but heavily used lib K within a mid-term timeframe, and we'll talk about your conclusions in two weeks" can be just as clear to some people as "implement method foo doing X according to spec point Y.Z by the end of the day" is to others.
intoverflow2 9y ago
> Clear goals are for junior "code monkeys" who just do what they are told without any concern for if they are going the right thing. Agree 100%, the less you act like a cog in a machine the less people will treat you like one. Lots of developers seem to want to log in to a system every day and just have a list of tasks they have to complete without any real collaboration or divergent thought and have their salary calculated by % of task completion. In my experience the people who collaborate in the office and try to push things further are the ones easily granted autonomy and no longer have to answer to micromanagement. Managers can see the difference between a box ticker and the breakouts that are actually making a difference at the company, once you achieve that then you'll notice people stop questioning what time you turn up to the office if at all.
- tiggybear 9y ago
  You can act like you're not a cog, but there's only so much autonomy you get working under someone else. If you're an employee you are a "code monkey" to one degree or another. If you do not need clear goals, Work for yourself. You don't need dozens of people above you telling you what to do and extracting part of your paycheck if you can figure it out and execute it on your own.
  - bluGill 9y ago
    The CEO of my company doesn't tell me what to do. He tells a vice president who tells [skip a dozen or so layers of management] who tells my boss who tells me. Part of my job is to go on down the line - I'm expected to feed work to a half a dozen junior engineers (there are other senior engineers on my team who also are expected to find work to feed on down the chain). Each level of the chain requires understanding of what the business needs. I need to make autonomous decisions every day that ultimately the CEO stands behind. The composite of all the good decisions (enough better be good) results in the success of my company and the CEO will take credit for it. However all the CEO says to me is "we will be the global leader in [the generic area my project is in]" in an all company meeting. Every step down the chain has just been filling in details.
  - intoverflow2 9y ago
sidlls 9y ago
> Clear goals are for junior "code monkeys" who just do what they are told without any concern for if they are going the right thing. Most of the interview processes in tech are geared towards hiring for this exact role. There's some ego stroking involved, but for the most part the sorts of "code trivia" questions candidates jump through are basically "can you implement this algorithm or data structure" correctly. They don't actually test problem solving ability. So it seems to me for he kinds of trivial work most of us in the industry are doing your objection is a bit immaterial. Some of us are engaged in more complex work, and I agree 100% with you about that. Remote doesn't quite cut it most of the time for that sort of thing.
taeric 9y ago
I think this is confusing goals with tasks. And even then, sometimes you still want a mix of both. A nice backlog of tasks that need done along with high level goals we'd like to achieve (but no solid tasking to make happen) is a beautiful thing. Unfortunately, it isn't free and takes effort. Which is a large part of what a manager should help with.
perpetualcrayon 9y ago
I find that even when given "goals" in a broad sense, when you break down the problem into its constituent parts there generally is very little to debate. And when there is something to debate, those conversations take time to accumulate information and research, and for people to "digest" them completely. I find that in-person discussions about said topics is more counter-productive than productive since in-person meetings sometimes inadvertently suggests you have a fixed time-frame within which to come to a conclusion. And the "debatable" topics generally aren't going to be acted on immediately. There needs to be coordination and planning when you all come to a conclusion that a particular strategy is going to be the way forward, and a lot of times assumes you're probably going to break backward compatibility so it won't be released until a major version bump.
eikenberry 9y ago
I would say there are trade-offs with remote based communications with distinct advantages you don't mention that help make up for the lack of the human factor. The most obvious is that it eliminates the human factor, which can make it a lot easier to work with people who have unpleasant personalities. It also makes all communications more asynchronous, which means you can discuss things at the pace needed instead of the forced sync of a person staring at you. Then there are all the technical benefits, like cut-n-paste, live URLs, screen sharing, logs of conversations, etc. It also sounds like you haven't experienced a fully remote team working. You don't miss out on the physical presence because it is not there to miss and people make up for that absence in other ways. All the water-cooler/hallway conversations are then there, online, in the chat rooms or what not.
kureikain 9y ago
> Clear goals are for junior "code monkeys" who just do what they are told without any concern for if they are going the right thing. Yeah, this is so true. I think the task with an clear process to do it have an clear goal. But other than that, tasks that's very vague such as design an API, design schema to efficient some kind of certain query usually requires a bit of art, and we learn from the mistake/success of last similar project to improve this one.

yawz 9y ago

> Give me clear goals... Arguably, I need talented individuals forming good teams to clarify the goals and to have direct input to the roadmap. Reducing people to implementors may not be great for morale, motivation and engagement. Some people want their input to be more than their code, and rightly so.

fogetti 9y ago
You are implying things which I didn't say. See my previous answer to bluGill.

dalbasal 9y ago

If you have very clear goals, tasks and visibility, a lot of stuff is possible. Flexible, hours, flexible locations, contracting. At the extreme end of that statement, you might even say that if goals and tasks are welll enough defined, post-work-AI-automation-Jeremy-Corbyn. :) For most jobs, tasks and goals are not clearly defined. That's why managing and being managed is hard.

whipoodle 9y ago

If conditions were amenable enough, I'd work in a factory too. (I'm being serious, I would.)