28

Due to the COVID-19 pandemic, most IT firms have started a work-from-home practice. To track their employees' work, they are using various time tracking software.

Our company (which provides services on wide range of software technologies) has issued new outrageous guidelines for software developers. Among various points, one of the major points states that the amount of time they spend in code editors shows the level of productivity. It is expected that they spend not more than 1-2 hours of their 9 hour shift in Skype, emails and browsers. The rest of the time should be in code editors with another line specifically saying that more usage of Skype shows lack of planning and documentation.

So, I want to know if the above assumptions and understanding of the company are correct at any level.

Do productive software developers/coders spend around 70-80% of their work time in code editors?

Is it a correct basis to calculate the work-time or mark their attendance on the basis of above mentioned factors?

(My opinion: As a web developer myself, I find these guidelines completely incorrect and insane. Having a common expectation from everyone irrespective of the type of project and the client they are handling is unjustifiable. It shows the lack of understanding of the organization's upper management of their own services and work flow. But, I would like to know the opinion of expert developers from around the globe present on this platform.)

To be clear: the guidelines states: this application usage tracking won't be the basis to cut our hours/attendance "as of yet".

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat. – Lilienthal Apr 13 '20 at 7:07
  • 3
    Are they measuring output at all? Honestly, people can be in an IDE all day but it won't matter if they don't write a single line of code. – HTDutchy Apr 13 '20 at 8:59
  • 4
    They don't trust you. Is there a history that could explain why? – Thorbjørn Ravn Andersen Apr 13 '20 at 10:15
  • 1
    @ThorbjørnRavnAndersen Pretty borderline comment. The worst thing you can do is to take unreasonable actions of a boss personal. – non-user38741 Apr 13 '20 at 11:32
  • 2
    @ThorbjørnRavnAndersen as OP writes these are guidelines released for all software developers. So it seems they trust no one ... – Daniel Apr 13 '20 at 14:28

10 Answers 10

45

It's like the old joke about the mathematician and the engineer. What's the difference? A mathematician works with pencil and paper. The engineer works with pencil, paper, and a trash bin.

It's conceivably possible for developers to spend 80% of their time cutting code, if they have clear specifications that they understand completely, and if they are developing new "greenfield" software. In other words, if they believe they never make mistakes.

It seems unlikely those conditions would always hold. If they don't, there are plenty of reasons for developers to use other programs than Visual Studio, Eclipse, or even Notepad.

  • Email / chat: obtaining clarifications on specifications, asking questions of one another.
  • Web browsers: for web developers, testing their applications.
  • Web browsers: for all developers, working with ticketing systems and GitHub-style code repositories.
  • Web browsers: for all developers, consulting documentation.
  • The system being developed: non-web developers

Your managers are being forced to change their thinking about supervision because people have to work remotely. They come from a mindset where people aren't working unless they are at their desk with heads down. Hence, they want some kind of metric for that, and they've chosen time-in-editor.

Do you want them to adopt better metrics? If so, you and your co-workers will have to make the case for the change. You have a good opportunity to do that: They have said they won't yet punish you (by paying for less work) for not following the 80%-editor metric.

Your best case can be made by showing you're just as productive -- you finish just as much work -- at home as you do in the office. Then maybe they will just trust you. (Yeah, right.) Failing that, they can look at your actual activity and learn something about how you do your work.

Obviously, if some of your co-workers slack off it will undermine your effort to make the case.

Be patient: changing attitudes is hard work (harder than development).

Good luck. And thanks for keeping at work during this horrible epidemic.

Get your boss a copy of Fred Brooks' old but still relevant book The Mythical Man-Month. And, maybe, read it yourself.

  • 6
    There's so much more than that, time in a console, time building code, time in a database, time browsing for solutions to software/os errors, etc, and if you happen to support your software...time dealing with support issues. – rtaft Apr 13 '20 at 0:11
  • 20
    Even better: get them two copies of The Mythical Man Month, so they can read it twice as fast! – celion Apr 13 '20 at 2:13
  • 2
    A great answer. We all tend to take it relatively hard on management for all kinds of reasons but, more often than not, we are being passive-aggressive and overly defensive. There are times when it's simpler than that: They just don't know better. In these cases, teach them (at least, try to). – Vector Zita Apr 13 '20 at 4:28
  • 2
    It also may not be possible to be as productive at home as at work. It depends on whether the individual has: a good desk/chair/ergonomic setup; superfast Internet connection (not necessarily a given); as many monitors with the same amount of screen real estate; a quiet place to work free from interruptions (during this COVID-19 time, people's entire families including small attention-needy children are at home with them). – shoover Apr 13 '20 at 5:11
  • 3
    @celion why stop at two copies? Buy a million and have one person read a word or letter from each page. Together they will finish it in no time! – David Apr 13 '20 at 12:25
21

Is it a correct basis to calculate the work-time or mark their attendance on the basis of above mentioned factors?

No, it isn't. But you're not in charge.

  • 7
    As much as this answer isn't the preferable one for OP in their position, it is the correct answer. As an employee, you're the crew member on a ship, and the captain is steering it the wrong way. You're not in charge of the ship and it's not up to you to say where the ship should be steered. The only choice you have is to leave the ship or stay on it. Or possibly try to convince the captain - but they're likely not going to listen. – Flater Apr 12 '20 at 18:01
  • 38
    @Flater Wow that is possibly the worst attitude towards work I've ever read. Its wrong on every level. First off, you have a responsibility to yourself not to be treated like garbage, which rules like this definitely cause. Second, you have a responsibility to do your best job for your employer, which includes creating the best environment to produce, which means pushing back on idiocy like this. You're failing on every level by accepting this. – Gabe Sechan Apr 12 '20 at 18:27
  • 11
    @GabeSechan: Working together towards a better goal is the ideal. But when push comes to shove and the person in charge disagrees, then there's nothing you can do - after all, that's what "in charge" means. I wasn't discussing idealism, I was discussing realism. What makes you think that a company who doesn't trust their employees to such a degree would trust their employee when that employee tells them not to check up on the employees that they don't trust? – Flater Apr 12 '20 at 19:36
  • 5
    @GabeSechan: Being fired is a massive drawback for your resume compared to quitting. Secondly, playing the "I'm too valuable" card is ridiculously arrogant, especially when used as a jusitifcation to question the decisions your company has made. – Flater Apr 12 '20 at 20:21
  • 3
    @Flater There are so many more options than the two options you give. Mutiny, formal complaint processes, sabotage, strike, etc. without even leaving your questionable maritime metaphor. Your reductionism is toxic and not a path down which anything good is found. – jwpfox Apr 13 '20 at 2:37
21

They aren’t correct, but this is fairly easy to game

I don’t think you will find anyone on here who agrees with how they are measuring productivity. However, if management were consistently intelligent in evaluating people, we wouldn’t have many questions on here, would we?

I would be inclined to game the system. I would never leave my IDE during the workday and find various workarounds for doing the same thing, just in an untrackable way. My experience with time tracking software is that it mostly cares about the active window on a machine, and/or whether there is periodic input into that active window, as it can’t tell whether you are achieving anything in that window. Others also have video tracking, but “I was thinking” is a very valid excuse and if they actually insist you churn out code every minute of every day, here is a link that can help:

https://ca.indeed.com/m/jobs?sameQ=1&radius=25&q=Software+Developer&l=&from=searchOnSerp

  1. You will want a full featured IDE. An IDE can prevent lots of Googling for little things. Instead of searching documentation for something, you can read through the names of functions when autocomplete gives you some options. You will lose out on a lot of best practice, but management evidently doesn’t value that. This metric is also going to punish any dev who prefers a text editor or uses a command-line git client, as I suspect using other tools is going to be under "other" rather than under "editor." A full-featured IDE also allows viewing images, so instead of reading a requirement in your bug tracker, you could take a screenshot, open it in your IDE as an image, and comply with the rules that way. You have a PDF of documentation to read? Run it through a PDF to jpg converter and read it in your IDE.

  2. You will want a 2nd computer. Time tracking software rests on the assumption that you can’t go and do another thing after clicking your button every 10 or so minutes. Having another computer allows you to go on Stack Overflow without seemingly ever leaving your IDE. If my management did this, I would set up one of my monitors to run on my Mac full time and use the Mac for Google and use my main laptop for the actual work.

Doing this, you could probably achieve 90% IDE time without really changing how you do development.

I wouldn’t be happy with this setup, but it’s the kind of stupid management initiative where the solution isn’t overly onerous, just somewhat irritating.

the guidelines states: this application usage tracking won't be the basis to cut our hours/attendance "as of yet".

This line makes me think layoffs are coming, so that is why I would roll over so easily and focus on meeting the metric.

  • 5
    +1 for the boomerang. Any reasonable manage should know that productivity in software cannot be caught by simple metrics – Manziel Apr 12 '20 at 17:55
  • 8
    Before you decide to game the system, think about how your coworkers will behave. You don't want to stand out here, even as the only person who hit the targets, because you don't want the spotlight on said gaming. Meanwhile if your coworkers want to push back together, you don't want to undermine their case with fake success. Of course if everyone from your team lead down does the second monitor trick, that's probably going to be okay. – Josiah Apr 12 '20 at 22:58
  • 4
    Good point, some IDEs even let you open internal browser windows. That basically solves most of gaming the system. – Piro says Reinstate Monica Apr 13 '20 at 5:26
  • Re "I would be inclined to game the system": Yes, it is a form of communication that you only get what you measure (and nothing else), while still being 100% within the rules. You could even buy an Arduino Leonardo (or the equivalent) to simulate mouse and keyboard activity if you are away. (I use one for a macro keyboard for actual productivity (automating repeating sequences of keyboard actions and avoiding modifier keys altogether (e.g. a physical key for Shift + Control + Tab))) – Peter Mortensen Apr 13 '20 at 11:50
  • Using an Arduino Leonardo will make it unintrusive and independent of software, incl. the operating system. Note that GNOME shipped with Ubuntu 19.10 broke the clipboard and also affects systems with more than one keyboard - the workaround is to switch to Cinnamon, Lubuntu, or similar (can be done on top of Ubuntu - no need to reinstall). – Peter Mortensen Apr 13 '20 at 12:04
10

Think about the things that need to happen as part of software development. Analyzing and understanding user needs and expectations. Decomposing requirements into units of work. Coming up with or making modifications to an architecture or design to support user needs. Documenting the architecture and design of the software. Writing code, including test code. Manual testing. Collaborative working. Peer review. Learning - reading existing system documentation, tool or technology documentation, prototyping.

Of these, only a few are going to be done inside of a code editor. Writing code and automated tests and creating prototypes will definitely be in an editor of some kind. Reading existing code for the system you are developing may be done inside of your editor, but it could also be done through a web interface to your source code repository. Code reviews, depending on your process and tooling, may be performed in your editor but will likely be done through a different tool.

I don't write (much) code at work anymore, but when I did, the vast majority of my time was not in my code editor. And even if my code editor was open, I may have been multitasking with other things open - an issue tracker, a wiki, a web browser for accessing documentation. Since I worked on a web application, I would also use a web browser to access my local development or one of the dev or test servers running a version of the application. With remote sessions, the use of tools like Skype and Slack to pair program via screen sharing is also going to increase.

Another thing to consider is that there are some numbers floating around (I wish I could cite a single, reputable source) about productive time being around 60%. That means in a 9-hour workday, you would expect to have a productive work time of around 5-5.5 hours. Highly optimized organizations may do better than 60%. Even if the assumption that a developer is only productive when in an editor holds true, 7 or 8 hours of a 9-hour shift would be a productivity time of over 78%.

Given the nature of software development, I can't see how it can be reasonable to make assumptions around productivity. Few, if any, people or organizations reach productivity of 78% or better during a workday. Even if you were, the use of an editor is not a good measure of software developer productivity as there are a large number of tasks that aren't done within the editor.

8

Whenever management wants to do something like this, they should always ask themselves: what am I incentivizing the employees out of?

In this case... you might have a developer that has a problem which they could probably solve in 20 minutes by some googling... but why? They're going to get dinged on performance. Better to spend 4 hours bashing a head into a wall and trying random stuff until it works. Or maybe you might have a developer that's not quite sure what they need to be doing with some facet of their current project. They could schedule a skype meeting and figure do a quick sit-down... except that's going to count against their performance metric. Better just bang something out and hope it's what's wanted - sure, it might result in a lot of wasted work... but that's wasted work in an IDE that doesn't count against me. Etc, etc.

Management actually put me in a similar position years back:

"Kevin, for your performance review, I had to dock you for the excessive web usage you had over the last 6 months."

"Wait, what?"

"Yeah, you were browsing the web an hour more per day than the department average."

"Yeah - that's because I was deep in the weeds trying to figure out how to write the extension button for the Thunderbird email client. It's a mix of Java - a language I don't really know - and a proprietary set of commands that don't have a good reference page. There were weeks where I was literally putzing around code sample sites for most of the day trying to cobble together commands and getting that thing working."

"You're saying that all of your web browsing was work related?"

"The vast majority. I mean, I may have visited a non-work site occasionally - but bring up the list of sites I was on. I bet google, stackoverflow, and the Thunderbird Chrome Language board are the three biggest sites."

"... well, given that you're acknowledging that some of this excessive browsing is personal, I'm letting the 'Needs Improvement' stand."

Now... care to guess how eager I was to do that sort of programming in the future? I mean, before I jumped at the chance to develop a key program in a new and exciting environment/language. Wanna guess how many projects like that I volunteered myself for in the future? Wanna guess how many times I'd volunteer for the difficult/impossible problems that I didn't already have a very good idea how to solve?

When in any position of authority, always ask yourself: what behaviors is this going to incentivize/drive?

  • Exactly this post is what OP should show to Management to rethink their guidelines! – Daniel Apr 13 '20 at 13:01
  • Was there any genuine assessment of your performance in the review? – Matthew Gaiser Apr 14 '20 at 2:00
  • Performance itself was great. It was in the subsection "Honesty and Integrity" - which made it even more irritating. – Kevin Apr 14 '20 at 3:23
3

I don't want to repeat what has been said in all the other answers, so I will leave it at that: that metric is ridiculous.

You are a software developer, not a typist. As a software developer, you are what is called a knowledge worker, you are being paid to think, you are being paid for your creativity, you are being paid for your knowledge, you are being paid for your experience, you are being paid for your expertise. You are not being paid for typing.

The time you spend typing into your editor is precisely the time that you are not doing any of the things you are being paid for. Your job is to spend a lot of time thinking so that you can solve the problem with the simplest, shortest code possible.

If you spend 70%-80% of your time coding, that means you only spend at a maximum 20%-30% of your time problem solving. Actually, it is much less than that, because you also have things like meetings, scheduling, team communications, reports, and … yes … time tracking to do during your work hours, plus all the project-related stuff that is not coding or problem-solving (trying to get a hold of the customer to clarify a requirement, for example).

If you spend most of your time coding, and no time thinking, it means that you are solving trivial problems. Statistically, it is highly likely that this same trivial problem has already been encountered by someone else, and that there is a ready-made solution for it. So, you should not be solving this trivial problem but instead use the existing solution.

You should be solving the hard problems, but those require a lot more time thinking than coding.

  • "You should be solving the hard problems, but those require a lot more time thinking than coding." minor quibble - often times as a developer I'm not solving the hard problems. However, even relatively simple ones tend to require less actual code and more thinking. Here is a trivial one: what colour should I make this button? The actual coding bit takes about 30 seconds. The thinking part might require 5 minutes (10 times as much) to check few variations. And even then it might take up an hour overall - you show it to few people to see what works better. Now sum the time. – VLAZ Apr 13 '20 at 13:00
3

Is there an ideal code editor usage percentage?

No, there is not.

Do productive software developers/coders spend around 70-80% of their work time in code editors?

Not in general, but some likely will match that number at least sometimes.

Is it a correct basis to calculate the work-time or mark their attendance on the basis of above mentioned factors?

Nope.

Why is there no ideal code editor usage percentage?

Because

  1. everyone is different
  2. everyone's work pile is different
  3. everyone's work pile contains different items from day to day
  4. everyone's environment is different

For 1) I sometimes love to work with a black board to come up with algorithms. That works for me nicely. Some other colleagues rather try out coding prototypes until one works. One coder looks at the DB via the code editor the other uses a command line db client. -> Differences in average code editor usage.

For 2) A senior developer might do more high level design and a junior more small tasks that are straightforward. One developer might do some DevOps task and write scripts in a text editor or coordinate software rollouts with another department. → differences in editor usage.

For 3) Monday everyone might be coding at the next release version, when suddenly during the night, servers with the old version crash due to a memory bug. Next day everyone jumps onto the log files, looks through database entries, hooks up debuggers or drives to the data centre to take a look at the cabling (or calls them). → Huge variation in code editor usage.

For 4) One colleague might work in a home office, and the others in the real office. The real office people can talk without switching the context on their PC, and the home office colleague needs to spin up a messenger. Or one colleague might have two monitors while another has one in his home office. The two-monitor person can leave the requirements open on his second screen, and the one monitor person needs to constantly switch. -> different code editor usage.

Bottom line: Unless you have a very strict assembly line development process, where every coder is supposed to work the same way, has the same kind of tasks every day and has the same setup and tools (without choice) as everyone else, there is no such universal truth. And no development process I've encountered so far was that "industrialized" - if it were, I'd not call it software engineering but software assembly - and it probably should be automated by then.

Now, on the other hand. If you want to code, at some point you need to edit the code in some way. So if you make the measure broad enough and count any editor in that could be used and pick the number low enough, then you can determine a minimal number like 10% a week that securely covers all successful coders (that are paid to develop software rather than do some other tasks). At that point it obviously gets quite meaningless - i.e. someone who slacks off so much they would be detected by that measure, should in any functioning company be detected much earlier by other means (e.g. by not having anything meaningful to say in a daily standup meeting for days).

Now there is a gray area in-between where you can use such a metric as an indicator, with other metrics to see whether someone needs support. But that is another ball park entirely of aiming for a perfect usage percentage. And again, there would be other metrics that cover the same cases without giving employees the feeling to be monitored and not trusted.

Therefore, your real question should not be "is there such a number?". Your real question should be "How do I get management to back the fuck off trying to manage me like a line worker that only works when being strictly monitored?" *

Or more nicely, how to get management to see that this measure is not helping anyone, but destroying self-determined work and thus personal work investment along with any good will and trust.

* Note that these are two separated parts: 1) being treated as a line worker 2) that is lazy when not monitored → i.e. I'm not saying every line worker needs monitoring either.

1

So, I want to know if the above assumptions and understanding of the company are correct at any level.

Do productive software developers/coders spend around 70-80% of their work time in code editors?

Is it a correct basis to calculate the work-time or mark their attendance on the basis of above mentioned factors?

Every company gets to make their own assumptions and judge developers on any basis they choose... no matter how ridiculous they are.

As I'm sure you already know, there's no factual basis behind any of their assumptions.

  • Fair to point out that I am not aware of any alternative metric that would be based on some sort of facts, not just rumors, besides measuring software by deadlines. – Tymoteusz Paul Apr 12 '20 at 18:01
  • @TymoteuszPaul Measuring velocity in SCRUM over a longer period of time makes some sense to me ... – Daniel Apr 13 '20 at 13:25
  • @JoeStrazzere Yes I know, but good that you point it out. Still it would give the management an indication that the need to do something if velocity dropped severely during those home office weeks. – Daniel Apr 13 '20 at 14:20
  • 1
    An old manager of mine said “any developer can double his rating according to any metrics without any improvement in productivity”. – gnasher729 Apr 14 '20 at 14:58
1

Whoever came up with that metric does not know the work you do to the level of such micromanagement.

These measurements may be useful if you have a baseline to work from. If when working at the office, time at the editor was between 75-85%, it makes sense to expect that same ratio, and take notice if there was a drop for a single employee.

Assuming everything else to stay the same: the employees are not asked to take more responsibilities, the specifications are not less defined now since the client is now providing them differently, etc.

Heh, I would probably not know the right percentage either. I would estimate that on my coding work, I spend more time at a console or web browser than at an editor (albeit recently I'm not developing large features). Specially, when you are chasing one of those hard-to-find bugs you could spend hours on a single defect! (but you may do the other 80% in the 20% left). And this not even taking into account the time spent on building the system, something you should do very often. Programmers don't work in a vacuum, and write a program from begin to end, and with no errors. Just like a writer won't write your novel straight ahead from begin to end. (It may be done by bright people if the novel/code is short enough. The point stands, though.)

Another point would be the amount of that is being required by your bosses. How are they keeping updated with the team members? Just that may already burn that hour that the employee may use for "not using a code editor". And that's not even considering that you were using an agile method like scrum! (hint: if tying people to their code editors was the best way to have employees produce value for the company, these methodologies wouldn't be successful)

It's also interesting how they would expect you to test the code or document its use. Is it the role of your QA team? Great. This guideline means you can pass them completely untested code, that may not even run. Please ask them to return the backtrace in a .c file, so you can read it on your code editor. Hardly a gain for your company, though.

In addition to all of these, an interesting point is that

specifically saying that more usage of Skype shows lack of planning and documentation.

I would expect the planning to be done by the management, and that the documentation to be the client specification. So, if you need to use Skype a lot, are they going to punish your boss for bad planning? Even if the product delivery is on time? What if the client can't make up his mind and is changing his requisites constantly? How are they going to account for problematic clients when assessing their developers' productivity?

  • 1
    Mostly agree, but one point: Even if you use the normal office as a baseline, that might be hugely skewed as now you have a different setup. Maybe all communication earlier on was orally with the other people in the room -> no context switch on the machine. Now this requires a context switch and can lead to huge deviations. But the problem is not the baseline, the problem is that the metrics are used as some fixed enforcement rule. – Frank Hopkins Apr 13 '20 at 1:39
  • Indeed. I tried to tackle that in the "Assuming everything else to stay the same" part, but perhaps the examples obscure this possibility. Sure, if you used to attend meetings with the code editor open, that would highly skew the metrics. If the numbers were right, and given enough margin for deviations, I think this could work (still preferable not to do anything based on that unless there's evidence that there has been a drop in productivity, though) but with numbers out of thin air, there's no way. I'm quite sure their in-office numbers were already quite far from this 70-80%. – Ángel Apr 13 '20 at 1:51
  • In general, that discussion whether that could be a good indicator for work effort is also academic (it's not a direct measure of productivity so it cannot be a strict indicator, it could be a soft indicator, i.e. to look closer, under some very restricted circumstances, but it has so many drawbacks and better alternatives that - just no). But I've seen this attempt in different forms now. Somehow company management seems to think they need to enforce office behaviour in home office setups. This begs the question: Do they have CCTV in their offices to make sure their workers just work there? – Frank Hopkins Apr 13 '20 at 2:10
  • 1
    And it somehow entails that weird thought that home office needs to work the exact same as in-place work. For many jobs it does not. Sure there are other distractions, but just as in-place you don't work against them by monitoring everyone, you work against them by providing a good framework to overcome them / blend them out. – Frank Hopkins Apr 13 '20 at 2:12
  • That being said, my initial comment was merely a hint on what I felt could be improved wrt. to the angle your answer takes. Imho the core problem is that there is an implicit contradiction in switching to home office and an assumption of "everything staying the same". -> that's imho the core contradiction in implementing the approach based on "normal" numbers. – Frank Hopkins Apr 13 '20 at 2:18
1

As all the other Posts mention, the proposed metrics do not hold any water.

I won´t repeat what the other have said but elaborate on a few points not covered.

  1. I don´t think its entirely unreasonable for someone who pays you to do something if they want to have some metric for the quality and quantity with which you deliver.
  2. With any new metric introduced, the process should be:
    • First: measure where you are at over a representative amount of time
    • Second: try to understand the numbers you get. How do they fluctuate. What do they really tell and what do they hide. Is there a sensible and realistic goal to be set here?
    • Discuss the numbers and agree to goals with your employees.
    • Regularly give feedback and control if the goals still serve the purpose

Otherwise, if you rush it, you just risk to steer you employees in the wrong direction. Instead of aligning them more with the business goals, you get them to cheat metric or deliver less optimal performance to rest the metric.

Even if this is just a ploy to get some paper trail for cutting your hours later, chance are if this happens on the wrong/ill understood metrics it harms to the organisation because the wrong people will get hours cut.

  1. There is actually a lot of material out there on how to mange and keep track of developers productivity. One way I found particularly sensible is "velocity". Note that this is not intended to measure individual performance but get an estimate of the teams rate of progress. In times like these you could easily see, after a few weeks of home office, if the teams velocity has dropped significantly. Then would be the time to talk to them and see what you can do to enable them to become as productive as before, again.

So what could you actually do, other than buckle down and/or fake it?

You could write an e-mail to the manager in charge (and only him, you dont want him feeling exposed and get defensive). It should consist of 3 parts.

A. Express you understanding and support of their goal. Make it clear that you are on board with the general idea and you will support any initiatives that promise to make the business more successful.

B. Express the risks the current approaches will carry. Beware not to be dismissive of the idea, but be sure to highlight the cost this could carry for the organisation. The google something in 5 minutes vs figure it out yourself in the code-editor in 2 hours is a good example to highlight perceived metrics vs. productiveness.

C. Propose a different approach. Nobody likes nay-Sayers. If you have nothing better to offer you can just as well keep quiet.

  • I would highlight C. Be part of the solution, not part of the problem. Think about where this came from. All of a sudden your company will have lots of people working from home. They are worried people will be slacking off, petting the dog, watering plants, cooking, etc. and want a way to check that. It is a reasonable worry, if not a reasonable solution. You know your job, so propose a better way to measure. Once you have a proposal, talk it over with colleagues and your boss, then write it up and figure out how to propose it. – Ross Millikan Apr 14 '20 at 4:36

Not the answer you're looking for? Browse other questions tagged .