Mixing
How do I manage the expectation of detail orientation at work?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
48
down vote
favorite
I face a fairly common issue of having too many tasks to do at work and too little time in which to do them. As a result, I often deliver on tasks exactly as they were requested and do not go any further. However, what sometimes happens is that people notice other issues associated with the task and highlight those as well, and complain that these should have been fixed. Let me give an example:
I was asked to update the corporate website with an events listing. In the past, whoever updated these had never changed the event logos to be a consistent size. This means that the logos don't align nicely, but since I was short on time I did these as they had been done in the past without re-sizing. (To be honest, they don't look that bad, just a 4/5 pixel difference in width.) But after completing the task and letting the original requester know, she came back to me telling me to fix the sizing issue, with the implication that I should have fixed this earlier.
Now my problem here is that if I had turned around and fixed all of these when I noticed them (while updating) it would have taken me a couple of hours.
The issue is that I see MANY problems like this one, that need to be fixed, but aren't because nobody senior had noticed. If I highlight all of these I won't have time to work on projects that I actually get paid for.
So the issue here is how do I get people to stop expecting me to not only do the what they ask, but also to notice and fix a whole host of older issues?
work-environment workload
edited Aug 9 '16 at 20:12
Dan Getz
1133
asked Aug 8 '16 at 10:50
Lukas_T
55559
 |Â
show 3 more comments
up vote
48
down vote
favorite
I face a fairly common issue of having too many tasks to do at work and too little time in which to do them. As a result, I often deliver on tasks exactly as they were requested and do not go any further. However, what sometimes happens is that people notice other issues associated with the task and highlight those as well, and complain that these should have been fixed. Let me give an example:
I was asked to update the corporate website with an events listing. In the past, whoever updated these had never changed the event logos to be a consistent size. This means that the logos don't align nicely, but since I was short on time I did these as they had been done in the past without re-sizing. (To be honest, they don't look that bad, just a 4/5 pixel difference in width.) But after completing the task and letting the original requester know, she came back to me telling me to fix the sizing issue, with the implication that I should have fixed this earlier.
Now my problem here is that if I had turned around and fixed all of these when I noticed them (while updating) it would have taken me a couple of hours.
The issue is that I see MANY problems like this one, that need to be fixed, but aren't because nobody senior had noticed. If I highlight all of these I won't have time to work on projects that I actually get paid for.
So the issue here is how do I get people to stop expecting me to not only do the what they ask, but also to notice and fix a whole host of older issues?
work-environment workload
edited Aug 9 '16 at 20:12
Dan Getz
1133
asked Aug 8 '16 at 10:50
Lukas_T
55559
"I did these as they had been done in the past" is not a way to get ahead. If the client wanted it how it had been done in the past, why are they hiring you? Anticipating your clients' needs goes a long way.
– Chris
Aug 8 '16 at 14:49
6
@Chris didn't hire me to make these updates, I do something totally different. Just got stuck with the task as the person is on maternity leave
– Lukas_T
Aug 8 '16 at 14:50
2
@Lukas_T what does your boss tell you to do in these cases?
– WorkerDrone
Aug 8 '16 at 16:26
2
What is your work environment? If you have a single manager assigning you all of your tasks, it is their job to prioritize your work, and your job to manage their expectations.
– Blackhawk
Aug 8 '16 at 22:18
1
Why should it be your fault your "customers" are not doing their side of the job, and that you are overworked? Document all requests.
– Rui F Ribeiro
Aug 9 '16 at 19:57
 |Â
show 3 more comments
up vote
48
down vote
favorite
up vote
48
down vote
favorite
I face a fairly common issue of having too many tasks to do at work and too little time in which to do them. As a result, I often deliver on tasks exactly as they were requested and do not go any further. However, what sometimes happens is that people notice other issues associated with the task and highlight those as well, and complain that these should have been fixed. Let me give an example:
I was asked to update the corporate website with an events listing. In the past, whoever updated these had never changed the event logos to be a consistent size. This means that the logos don't align nicely, but since I was short on time I did these as they had been done in the past without re-sizing. (To be honest, they don't look that bad, just a 4/5 pixel difference in width.) But after completing the task and letting the original requester know, she came back to me telling me to fix the sizing issue, with the implication that I should have fixed this earlier.
Now my problem here is that if I had turned around and fixed all of these when I noticed them (while updating) it would have taken me a couple of hours.
The issue is that I see MANY problems like this one, that need to be fixed, but aren't because nobody senior had noticed. If I highlight all of these I won't have time to work on projects that I actually get paid for.
So the issue here is how do I get people to stop expecting me to not only do the what they ask, but also to notice and fix a whole host of older issues?
work-environment workload
edited Aug 9 '16 at 20:12
Dan Getz
1133
asked Aug 8 '16 at 10:50
Lukas_T
55559
I face a fairly common issue of having too many tasks to do at work and too little time in which to do them. As a result, I often deliver on tasks exactly as they were requested and do not go any further. However, what sometimes happens is that people notice other issues associated with the task and highlight those as well, and complain that these should have been fixed. Let me give an example:
I was asked to update the corporate website with an events listing. In the past, whoever updated these had never changed the event logos to be a consistent size. This means that the logos don't align nicely, but since I was short on time I did these as they had been done in the past without re-sizing. (To be honest, they don't look that bad, just a 4/5 pixel difference in width.) But after completing the task and letting the original requester know, she came back to me telling me to fix the sizing issue, with the implication that I should have fixed this earlier.
Now my problem here is that if I had turned around and fixed all of these when I noticed them (while updating) it would have taken me a couple of hours.
The issue is that I see MANY problems like this one, that need to be fixed, but aren't because nobody senior had noticed. If I highlight all of these I won't have time to work on projects that I actually get paid for.
So the issue here is how do I get people to stop expecting me to not only do the what they ask, but also to notice and fix a whole host of older issues?
work-environment workload
edited Aug 9 '16 at 20:12
Dan Getz
1133
asked Aug 8 '16 at 10:50
Lukas_T
55559
edited Aug 9 '16 at 20:12
Dan Getz
1133
edited Aug 9 '16 at 20:12
Dan Getz
1133
edited Aug 9 '16 at 20:12
Dan Getz
1133
1133
asked Aug 8 '16 at 10:50
Lukas_T
55559
asked Aug 8 '16 at 10:50
Lukas_T
55559
asked Aug 8 '16 at 10:50
Lukas_T
55559
55559
"I did these as they had been done in the past" is not a way to get ahead. If the client wanted it how it had been done in the past, why are they hiring you? Anticipating your clients' needs goes a long way.
– Chris
Aug 8 '16 at 14:49
6
@Chris didn't hire me to make these updates, I do something totally different. Just got stuck with the task as the person is on maternity leave
– Lukas_T
Aug 8 '16 at 14:50
2
@Lukas_T what does your boss tell you to do in these cases?
– WorkerDrone
Aug 8 '16 at 16:26
2
What is your work environment? If you have a single manager assigning you all of your tasks, it is their job to prioritize your work, and your job to manage their expectations.
– Blackhawk
Aug 8 '16 at 22:18
1
Why should it be your fault your "customers" are not doing their side of the job, and that you are overworked? Document all requests.
– Rui F Ribeiro
Aug 9 '16 at 19:57
 |Â
show 3 more comments
"I did these as they had been done in the past" is not a way to get ahead. If the client wanted it how it had been done in the past, why are they hiring you? Anticipating your clients' needs goes a long way.
– Chris
Aug 8 '16 at 14:49
6
@Chris didn't hire me to make these updates, I do something totally different. Just got stuck with the task as the person is on maternity leave
– Lukas_T
Aug 8 '16 at 14:50
2
@Lukas_T what does your boss tell you to do in these cases?
– WorkerDrone
Aug 8 '16 at 16:26
2
What is your work environment? If you have a single manager assigning you all of your tasks, it is their job to prioritize your work, and your job to manage their expectations.
– Blackhawk
Aug 8 '16 at 22:18
1
Why should it be your fault your "customers" are not doing their side of the job, and that you are overworked? Document all requests.
– Rui F Ribeiro
Aug 9 '16 at 19:57
"I did these as they had been done in the past" is not a way to get ahead. If the client wanted it how it had been done in the past, why are they hiring you? Anticipating your clients' needs goes a long way.
– Chris
Aug 8 '16 at 14:49
"I did these as they had been done in the past" is not a way to get ahead. If the client wanted it how it had been done in the past, why are they hiring you? Anticipating your clients' needs goes a long way.
– Chris
Aug 8 '16 at 14:49
6
6
@Chris didn't hire me to make these updates, I do something totally different. Just got stuck with the task as the person is on maternity leave
– Lukas_T
Aug 8 '16 at 14:50
@Chris didn't hire me to make these updates, I do something totally different. Just got stuck with the task as the person is on maternity leave
– Lukas_T
Aug 8 '16 at 14:50
2
2
@Lukas_T what does your boss tell you to do in these cases?
– WorkerDrone
Aug 8 '16 at 16:26
@Lukas_T what does your boss tell you to do in these cases?
– WorkerDrone
Aug 8 '16 at 16:26
2
2
What is your work environment? If you have a single manager assigning you all of your tasks, it is their job to prioritize your work, and your job to manage their expectations.
– Blackhawk
Aug 8 '16 at 22:18
What is your work environment? If you have a single manager assigning you all of your tasks, it is their job to prioritize your work, and your job to manage their expectations.
– Blackhawk
Aug 8 '16 at 22:18
1
1
Why should it be your fault your "customers" are not doing their side of the job, and that you are overworked? Document all requests.
– Rui F Ribeiro
Aug 9 '16 at 19:57
Why should it be your fault your "customers" are not doing their side of the job, and that you are overworked? Document all requests.
– Rui F Ribeiro
Aug 9 '16 at 19:57
 |Â
show 3 more comments
4 Answers
4
active
oldest
votes
up vote
72
down vote
accepted
My suggestion:
Create a log of issues/potential work items.
I would add anything someone requests on to this log, but also anything you happen to notice that needs fixing.
Entering something on the log doesn't mean you have promised to fix it; it just means there is something that, ideally, needs to be addressed eventually.
What this enables you to do:
- It demonstrates that you have noticed the issues, but chose not to prioritise them.
- It highlights the number of issues there are and the potential work it would be to fix them.
- It facilitates managing and prioritizing work. So now if someone asks you to fix the header sizes, it is clear that they are prioritizing this task over other, possibly more important tasks.
- Just in general, you are now pro-actively managing the situation rather than being on the back foot with too much work.
My thinking on this is based on the product backlog in Scrum software development. Some of that methodology may be useful to you. But even if you don't want to adopt a whole project management method, a simple log could be quite beneficial in your situation.
This is part of my general philosophy: in an environment where work isn't well-managed, manage your own work. Not only will this be a defense against the pressures put on you by the workplace, it will also set you apart as doing an excellent job--and it might inspire change around you.
6
The problem is, in some work environments with "more than average toxicity", the other party might not have the ethical standards in high regard. This backlog can be used against the creator of said backlog with something in the line of "This is easy to do, if you had time to enter it into a backlog, you should've just fixed it when you noticed" - Usually a place to flee from, but sometimes you are stuck on that job. <insert Dilbert strip link here>
– Mindwin
Aug 8 '16 at 15:04
3
That is true, but I did not see anything in the question which suggested a toxic work environment. Just one where a product stakeholder thinks about scope and units of work differently than a developer, which is like, everywhere. A backlog is a great way to handle this! +1
– Brandon
Aug 8 '16 at 16:26
To mitigate backlash, maybe you could include a rough time estimate in the log? Make it clear that it's not a very well considered estimate, but an approximate idea. The bonus is that management can then weigh up how much it's worth prioritising small fixes if they'll take you 6 hours.
– SuperBiasedMan
Aug 8 '16 at 16:36
@Mindwin If someone uses that line, they either don't understand (or are choosing to ignore) the true cost of any unscheduled change, especially when you include testing, documentation, change management, etc.
– corsiKa
Aug 8 '16 at 18:43
2
If it's "easy to do", add time estimates to the items in the back log, and times actually spent. This is standard, Outlook Tasks can do it. Then tell people to stop bugging you because you're losing all this time keeping track of this nonsense while you could be doing the work. It's them not you that cause you to do it. The point is you need to make it transparent to them what it takes to do the things they expect of you so you have data on the basis of which your job performance can be discussed.. The need to do this should be clear to them.
– reinierpost
Aug 8 '16 at 20:37
 |Â
show 3 more comments
up vote
38
down vote
So the issue here is how do I get people to stop expecting me to not
only do the what they ask and also to notice and fix a whole host of
older issues ?
Unfortunately, you don't.
Stakeholders have specific needs that they can articulate, and generalized needs that they can't.
When estimating a task, many include a certain percentage of time set aside to fix these sorts of unspecified issues. Once the primary change is made, general cleanup takes place and the result is an overall-better product that makes the stakeholders happy.
You may need to enlist the help of your boss to prioritize the overall projects. But always include some cleanup time (or "technical debt" time).
In addition, make sure you help keep a bug list up-to-date. That way, you can draw down the list as time allows. Pretty much every shop has a bit of "down time" here and there. A few quick bug fixes are great ways of filling in those time gaps.
Having happy stakeholders should be your goal, rather than just fixing what they specifically point out.
answered Aug 8 '16 at 10:58
Joe Strazzere
222k101648912
One thing I sympathize with that might be different in the OP's case is that he seems to be inheriting code from a prior development team. In that case, it isn't scope creep or vague requirements that trip you up, it's the minefield of someone else's poor design. In many projects, you won't even be able to review the code until you've agreed to do the work, and while something might sound and probably is simple on paper, a foundation of ugly design and poor coding can wreck the most reasonably padded of estimates.
– Blackhawk
Aug 9 '16 at 16:39
suggest improvements |Â
up vote
22
down vote
I won't have time to work on projects that I actually get paid for.
There are two simply answers depending on whether you're a contractor or not:
Contractor: you reply that this wasn't part of the contract or wasn't included in estimate or specification of the project you were hired for. You're happy to do these tasks at your usual rate with the understanding that it will delay other deliverables. If the tasks are too menial (e.g. you're a database specialist and they're asking you to clear up the documentation or refactor stuff) you can either say that that's not a service you provide or that you're happy to do it but your rate is still X$/h (i.e. too much for that kind of work). If you say the latter you can make it even clearer by recommending someone else for the work or pointing out that others can do it for less.
Regular employee: you are being paid for your time. Whether doing this is a good use of your time and justifies the delay on the delivery of other tasks is entirely up to your manager. Ask your manager. Note that this should be a broader conversation about your role to determine how much initiative you should take and what to say to people who take issue with your work.
answered Aug 8 '16 at 12:02
Lilienthal♦
53.9k36183218
1
I like this, because this is what I would do sort of, tell my manager there is a bunch of other things I noticed and if they want me to allocate time to resolve them.
– Kilisi
Aug 9 '16 at 0:39
suggest improvements |Â
up vote
5
down vote
Based on your statement implying multiple projects, I'm wondering if you have multiple managers or clients, which definitely makes things complicated. However, in the case of a single manager, I would suggest that:
It is your manager's job to prioritize your workload, and it is your job to manage their expectations.
In my positions both as an employee and as a manager, it has been my experience that if the work you have been assigned is beyond your capacity, it is specifically your manager's job to prioritize it or assign it to another employee. It is your job to manage your manager's expectations.
Suppose your manager assigns you several tasks which seems doable in the allotted time, but later something changes: the deadline is moved up, some preliminary research reveals that a task will take longer than you originally thought, or an unforeseen complication arises. It is up to you to promptly notify your manager of the issue along with proposed solutions and estimates if the issue is within your area of expertise. The manager needs this information ASAP to make good decisions for the project overall.
Right now, you are preempting your manager by deciding that it is always better to check the boxes of your task list, but your manager might decide, for example:
- It is more important that you hold off on the other tasks until the issue is resolved.
- The issue can be resolved by another employee so that you can focus on the rest of your tasks.
- The issue doesn't really matter, you can safely ignore it.
- It actually is more important that you check off everything in your list of tasks, so you should ignore the issue and move on for now.
While it isn't always feasible or practical with small issues, like the one you describe, to continually run to your boss with a presentation explaining the error and a list of proposed solutions, you can at least send a note to your manager explaining the issue and then move on to the next task until you have a response from them on how they want you to prioritize your time.
answered Aug 8 '16 at 22:26
Blackhawk
36915
By way of example, I once worked on the side to help a client with tax depreciation tool that was made with recorded Excel macros :'( Because of the poor structure of the code and the utter lack of any reasonable naming convention, simple requests might take orders of magnitude longer. I would notify the client and explain the situation ASAP and give them a few options: the quick and dirty hack, the compromise or the future-proof Right Way™. That way, whatever happens was on them. They consistently chose dirty hack until they realized how much pain it caused, and finally let me rewrite.
– Blackhawk
Aug 8 '16 at 22:38
suggest improvements |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
72
down vote
accepted
My suggestion:
Create a log of issues/potential work items.
I would add anything someone requests on to this log, but also anything you happen to notice that needs fixing.
Entering something on the log doesn't mean you have promised to fix it; it just means there is something that, ideally, needs to be addressed eventually.
What this enables you to do:
- It demonstrates that you have noticed the issues, but chose not to prioritise them.
- It highlights the number of issues there are and the potential work it would be to fix them.
- It facilitates managing and prioritizing work. So now if someone asks you to fix the header sizes, it is clear that they are prioritizing this task over other, possibly more important tasks.
- Just in general, you are now pro-actively managing the situation rather than being on the back foot with too much work.
My thinking on this is based on the product backlog in Scrum software development. Some of that methodology may be useful to you. But even if you don't want to adopt a whole project management method, a simple log could be quite beneficial in your situation.
This is part of my general philosophy: in an environment where work isn't well-managed, manage your own work. Not only will this be a defense against the pressures put on you by the workplace, it will also set you apart as doing an excellent job--and it might inspire change around you.
6
The problem is, in some work environments with "more than average toxicity", the other party might not have the ethical standards in high regard. This backlog can be used against the creator of said backlog with something in the line of "This is easy to do, if you had time to enter it into a backlog, you should've just fixed it when you noticed" - Usually a place to flee from, but sometimes you are stuck on that job. <insert Dilbert strip link here>
– Mindwin
Aug 8 '16 at 15:04
3
That is true, but I did not see anything in the question which suggested a toxic work environment. Just one where a product stakeholder thinks about scope and units of work differently than a developer, which is like, everywhere. A backlog is a great way to handle this! +1
– Brandon
Aug 8 '16 at 16:26
To mitigate backlash, maybe you could include a rough time estimate in the log? Make it clear that it's not a very well considered estimate, but an approximate idea. The bonus is that management can then weigh up how much it's worth prioritising small fixes if they'll take you 6 hours.
– SuperBiasedMan
Aug 8 '16 at 16:36
@Mindwin If someone uses that line, they either don't understand (or are choosing to ignore) the true cost of any unscheduled change, especially when you include testing, documentation, change management, etc.
– corsiKa
Aug 8 '16 at 18:43
2
If it's "easy to do", add time estimates to the items in the back log, and times actually spent. This is standard, Outlook Tasks can do it. Then tell people to stop bugging you because you're losing all this time keeping track of this nonsense while you could be doing the work. It's them not you that cause you to do it. The point is you need to make it transparent to them what it takes to do the things they expect of you so you have data on the basis of which your job performance can be discussed.. The need to do this should be clear to them.
– reinierpost
Aug 8 '16 at 20:37
 |Â
show 3 more comments
up vote
72
down vote
accepted
My suggestion:
Create a log of issues/potential work items.
I would add anything someone requests on to this log, but also anything you happen to notice that needs fixing.
Entering something on the log doesn't mean you have promised to fix it; it just means there is something that, ideally, needs to be addressed eventually.
What this enables you to do:
- It demonstrates that you have noticed the issues, but chose not to prioritise them.
- It highlights the number of issues there are and the potential work it would be to fix them.
- It facilitates managing and prioritizing work. So now if someone asks you to fix the header sizes, it is clear that they are prioritizing this task over other, possibly more important tasks.
- Just in general, you are now pro-actively managing the situation rather than being on the back foot with too much work.
My thinking on this is based on the product backlog in Scrum software development. Some of that methodology may be useful to you. But even if you don't want to adopt a whole project management method, a simple log could be quite beneficial in your situation.
This is part of my general philosophy: in an environment where work isn't well-managed, manage your own work. Not only will this be a defense against the pressures put on you by the workplace, it will also set you apart as doing an excellent job--and it might inspire change around you.
6
The problem is, in some work environments with "more than average toxicity", the other party might not have the ethical standards in high regard. This backlog can be used against the creator of said backlog with something in the line of "This is easy to do, if you had time to enter it into a backlog, you should've just fixed it when you noticed" - Usually a place to flee from, but sometimes you are stuck on that job. <insert Dilbert strip link here>
– Mindwin
Aug 8 '16 at 15:04
3
That is true, but I did not see anything in the question which suggested a toxic work environment. Just one where a product stakeholder thinks about scope and units of work differently than a developer, which is like, everywhere. A backlog is a great way to handle this! +1
– Brandon
Aug 8 '16 at 16:26
To mitigate backlash, maybe you could include a rough time estimate in the log? Make it clear that it's not a very well considered estimate, but an approximate idea. The bonus is that management can then weigh up how much it's worth prioritising small fixes if they'll take you 6 hours.
– SuperBiasedMan
Aug 8 '16 at 16:36
@Mindwin If someone uses that line, they either don't understand (or are choosing to ignore) the true cost of any unscheduled change, especially when you include testing, documentation, change management, etc.
– corsiKa
Aug 8 '16 at 18:43
2
If it's "easy to do", add time estimates to the items in the back log, and times actually spent. This is standard, Outlook Tasks can do it. Then tell people to stop bugging you because you're losing all this time keeping track of this nonsense while you could be doing the work. It's them not you that cause you to do it. The point is you need to make it transparent to them what it takes to do the things they expect of you so you have data on the basis of which your job performance can be discussed.. The need to do this should be clear to them.
– reinierpost
Aug 8 '16 at 20:37
 |Â
show 3 more comments
up vote
72
down vote
accepted
up vote
72
down vote
accepted
My suggestion:
Create a log of issues/potential work items.
I would add anything someone requests on to this log, but also anything you happen to notice that needs fixing.
Entering something on the log doesn't mean you have promised to fix it; it just means there is something that, ideally, needs to be addressed eventually.
What this enables you to do:
- It demonstrates that you have noticed the issues, but chose not to prioritise them.
- It highlights the number of issues there are and the potential work it would be to fix them.
- It facilitates managing and prioritizing work. So now if someone asks you to fix the header sizes, it is clear that they are prioritizing this task over other, possibly more important tasks.
- Just in general, you are now pro-actively managing the situation rather than being on the back foot with too much work.
My thinking on this is based on the product backlog in Scrum software development. Some of that methodology may be useful to you. But even if you don't want to adopt a whole project management method, a simple log could be quite beneficial in your situation.
This is part of my general philosophy: in an environment where work isn't well-managed, manage your own work. Not only will this be a defense against the pressures put on you by the workplace, it will also set you apart as doing an excellent job--and it might inspire change around you.
My suggestion:
Create a log of issues/potential work items.
I would add anything someone requests on to this log, but also anything you happen to notice that needs fixing.
Entering something on the log doesn't mean you have promised to fix it; it just means there is something that, ideally, needs to be addressed eventually.
What this enables you to do:
- It demonstrates that you have noticed the issues, but chose not to prioritise them.
- It highlights the number of issues there are and the potential work it would be to fix them.
- It facilitates managing and prioritizing work. So now if someone asks you to fix the header sizes, it is clear that they are prioritizing this task over other, possibly more important tasks.
- Just in general, you are now pro-actively managing the situation rather than being on the back foot with too much work.
My thinking on this is based on the product backlog in Scrum software development. Some of that methodology may be useful to you. But even if you don't want to adopt a whole project management method, a simple log could be quite beneficial in your situation.
This is part of my general philosophy: in an environment where work isn't well-managed, manage your own work. Not only will this be a defense against the pressures put on you by the workplace, it will also set you apart as doing an excellent job--and it might inspire change around you.
edited Aug 8 '16 at 14:55
answered Aug 8 '16 at 13:20
user45590
6
The problem is, in some work environments with "more than average toxicity", the other party might not have the ethical standards in high regard. This backlog can be used against the creator of said backlog with something in the line of "This is easy to do, if you had time to enter it into a backlog, you should've just fixed it when you noticed" - Usually a place to flee from, but sometimes you are stuck on that job. <insert Dilbert strip link here>
– Mindwin
Aug 8 '16 at 15:04
3
That is true, but I did not see anything in the question which suggested a toxic work environment. Just one where a product stakeholder thinks about scope and units of work differently than a developer, which is like, everywhere. A backlog is a great way to handle this! +1
– Brandon
Aug 8 '16 at 16:26
To mitigate backlash, maybe you could include a rough time estimate in the log? Make it clear that it's not a very well considered estimate, but an approximate idea. The bonus is that management can then weigh up how much it's worth prioritising small fixes if they'll take you 6 hours.
– SuperBiasedMan
Aug 8 '16 at 16:36
@Mindwin If someone uses that line, they either don't understand (or are choosing to ignore) the true cost of any unscheduled change, especially when you include testing, documentation, change management, etc.
– corsiKa
Aug 8 '16 at 18:43
2
If it's "easy to do", add time estimates to the items in the back log, and times actually spent. This is standard, Outlook Tasks can do it. Then tell people to stop bugging you because you're losing all this time keeping track of this nonsense while you could be doing the work. It's them not you that cause you to do it. The point is you need to make it transparent to them what it takes to do the things they expect of you so you have data on the basis of which your job performance can be discussed.. The need to do this should be clear to them.
– reinierpost
Aug 8 '16 at 20:37
 |Â
show 3 more comments
6
The problem is, in some work environments with "more than average toxicity", the other party might not have the ethical standards in high regard. This backlog can be used against the creator of said backlog with something in the line of "This is easy to do, if you had time to enter it into a backlog, you should've just fixed it when you noticed" - Usually a place to flee from, but sometimes you are stuck on that job. <insert Dilbert strip link here>
– Mindwin
Aug 8 '16 at 15:04
3
That is true, but I did not see anything in the question which suggested a toxic work environment. Just one where a product stakeholder thinks about scope and units of work differently than a developer, which is like, everywhere. A backlog is a great way to handle this! +1
– Brandon
Aug 8 '16 at 16:26
To mitigate backlash, maybe you could include a rough time estimate in the log? Make it clear that it's not a very well considered estimate, but an approximate idea. The bonus is that management can then weigh up how much it's worth prioritising small fixes if they'll take you 6 hours.
– SuperBiasedMan
Aug 8 '16 at 16:36
@Mindwin If someone uses that line, they either don't understand (or are choosing to ignore) the true cost of any unscheduled change, especially when you include testing, documentation, change management, etc.
– corsiKa
Aug 8 '16 at 18:43
2
If it's "easy to do", add time estimates to the items in the back log, and times actually spent. This is standard, Outlook Tasks can do it. Then tell people to stop bugging you because you're losing all this time keeping track of this nonsense while you could be doing the work. It's them not you that cause you to do it. The point is you need to make it transparent to them what it takes to do the things they expect of you so you have data on the basis of which your job performance can be discussed.. The need to do this should be clear to them.
– reinierpost
Aug 8 '16 at 20:37
6
6
The problem is, in some work environments with "more than average toxicity", the other party might not have the ethical standards in high regard. This backlog can be used against the creator of said backlog with something in the line of "This is easy to do, if you had time to enter it into a backlog, you should've just fixed it when you noticed" - Usually a place to flee from, but sometimes you are stuck on that job. <insert Dilbert strip link here>
– Mindwin
Aug 8 '16 at 15:04
The problem is, in some work environments with "more than average toxicity", the other party might not have the ethical standards in high regard. This backlog can be used against the creator of said backlog with something in the line of "This is easy to do, if you had time to enter it into a backlog, you should've just fixed it when you noticed" - Usually a place to flee from, but sometimes you are stuck on that job. <insert Dilbert strip link here>
– Mindwin
Aug 8 '16 at 15:04
3
3
That is true, but I did not see anything in the question which suggested a toxic work environment. Just one where a product stakeholder thinks about scope and units of work differently than a developer, which is like, everywhere. A backlog is a great way to handle this! +1
– Brandon
Aug 8 '16 at 16:26
That is true, but I did not see anything in the question which suggested a toxic work environment. Just one where a product stakeholder thinks about scope and units of work differently than a developer, which is like, everywhere. A backlog is a great way to handle this! +1
– Brandon
Aug 8 '16 at 16:26
To mitigate backlash, maybe you could include a rough time estimate in the log? Make it clear that it's not a very well considered estimate, but an approximate idea. The bonus is that management can then weigh up how much it's worth prioritising small fixes if they'll take you 6 hours.
– SuperBiasedMan
Aug 8 '16 at 16:36
To mitigate backlash, maybe you could include a rough time estimate in the log? Make it clear that it's not a very well considered estimate, but an approximate idea. The bonus is that management can then weigh up how much it's worth prioritising small fixes if they'll take you 6 hours.
– SuperBiasedMan
Aug 8 '16 at 16:36
@Mindwin If someone uses that line, they either don't understand (or are choosing to ignore) the true cost of any unscheduled change, especially when you include testing, documentation, change management, etc.
– corsiKa
Aug 8 '16 at 18:43
@Mindwin If someone uses that line, they either don't understand (or are choosing to ignore) the true cost of any unscheduled change, especially when you include testing, documentation, change management, etc.
– corsiKa
Aug 8 '16 at 18:43
2
2
If it's "easy to do", add time estimates to the items in the back log, and times actually spent. This is standard, Outlook Tasks can do it. Then tell people to stop bugging you because you're losing all this time keeping track of this nonsense while you could be doing the work. It's them not you that cause you to do it. The point is you need to make it transparent to them what it takes to do the things they expect of you so you have data on the basis of which your job performance can be discussed.. The need to do this should be clear to them.
– reinierpost
Aug 8 '16 at 20:37
If it's "easy to do", add time estimates to the items in the back log, and times actually spent. This is standard, Outlook Tasks can do it. Then tell people to stop bugging you because you're losing all this time keeping track of this nonsense while you could be doing the work. It's them not you that cause you to do it. The point is you need to make it transparent to them what it takes to do the things they expect of you so you have data on the basis of which your job performance can be discussed.. The need to do this should be clear to them.
– reinierpost
Aug 8 '16 at 20:37
 |Â
show 3 more comments
up vote
38
down vote
So the issue here is how do I get people to stop expecting me to not
only do the what they ask and also to notice and fix a whole host of
older issues ?
Unfortunately, you don't.
Stakeholders have specific needs that they can articulate, and generalized needs that they can't.
When estimating a task, many include a certain percentage of time set aside to fix these sorts of unspecified issues. Once the primary change is made, general cleanup takes place and the result is an overall-better product that makes the stakeholders happy.
You may need to enlist the help of your boss to prioritize the overall projects. But always include some cleanup time (or "technical debt" time).
In addition, make sure you help keep a bug list up-to-date. That way, you can draw down the list as time allows. Pretty much every shop has a bit of "down time" here and there. A few quick bug fixes are great ways of filling in those time gaps.
Having happy stakeholders should be your goal, rather than just fixing what they specifically point out.
answered Aug 8 '16 at 10:58
Joe Strazzere
222k101648912
One thing I sympathize with that might be different in the OP's case is that he seems to be inheriting code from a prior development team. In that case, it isn't scope creep or vague requirements that trip you up, it's the minefield of someone else's poor design. In many projects, you won't even be able to review the code until you've agreed to do the work, and while something might sound and probably is simple on paper, a foundation of ugly design and poor coding can wreck the most reasonably padded of estimates.
– Blackhawk
Aug 9 '16 at 16:39
suggest improvements |Â
up vote
38
down vote
So the issue here is how do I get people to stop expecting me to not
only do the what they ask and also to notice and fix a whole host of
older issues ?
Unfortunately, you don't.
Stakeholders have specific needs that they can articulate, and generalized needs that they can't.
When estimating a task, many include a certain percentage of time set aside to fix these sorts of unspecified issues. Once the primary change is made, general cleanup takes place and the result is an overall-better product that makes the stakeholders happy.
You may need to enlist the help of your boss to prioritize the overall projects. But always include some cleanup time (or "technical debt" time).
In addition, make sure you help keep a bug list up-to-date. That way, you can draw down the list as time allows. Pretty much every shop has a bit of "down time" here and there. A few quick bug fixes are great ways of filling in those time gaps.
Having happy stakeholders should be your goal, rather than just fixing what they specifically point out.
answered Aug 8 '16 at 10:58
Joe Strazzere
222k101648912
One thing I sympathize with that might be different in the OP's case is that he seems to be inheriting code from a prior development team. In that case, it isn't scope creep or vague requirements that trip you up, it's the minefield of someone else's poor design. In many projects, you won't even be able to review the code until you've agreed to do the work, and while something might sound and probably is simple on paper, a foundation of ugly design and poor coding can wreck the most reasonably padded of estimates.
– Blackhawk
Aug 9 '16 at 16:39
suggest improvements |Â
up vote
38
down vote
up vote
38
down vote
So the issue here is how do I get people to stop expecting me to not
only do the what they ask and also to notice and fix a whole host of
older issues ?
Unfortunately, you don't.
Stakeholders have specific needs that they can articulate, and generalized needs that they can't.
When estimating a task, many include a certain percentage of time set aside to fix these sorts of unspecified issues. Once the primary change is made, general cleanup takes place and the result is an overall-better product that makes the stakeholders happy.
You may need to enlist the help of your boss to prioritize the overall projects. But always include some cleanup time (or "technical debt" time).
In addition, make sure you help keep a bug list up-to-date. That way, you can draw down the list as time allows. Pretty much every shop has a bit of "down time" here and there. A few quick bug fixes are great ways of filling in those time gaps.
Having happy stakeholders should be your goal, rather than just fixing what they specifically point out.
answered Aug 8 '16 at 10:58
Joe Strazzere
222k101648912
So the issue here is how do I get people to stop expecting me to not
only do the what they ask and also to notice and fix a whole host of
older issues ?
Unfortunately, you don't.
Stakeholders have specific needs that they can articulate, and generalized needs that they can't.
When estimating a task, many include a certain percentage of time set aside to fix these sorts of unspecified issues. Once the primary change is made, general cleanup takes place and the result is an overall-better product that makes the stakeholders happy.
You may need to enlist the help of your boss to prioritize the overall projects. But always include some cleanup time (or "technical debt" time).
In addition, make sure you help keep a bug list up-to-date. That way, you can draw down the list as time allows. Pretty much every shop has a bit of "down time" here and there. A few quick bug fixes are great ways of filling in those time gaps.
Having happy stakeholders should be your goal, rather than just fixing what they specifically point out.
answered Aug 8 '16 at 10:58
Joe Strazzere
222k101648912
answered Aug 8 '16 at 10:58
Joe Strazzere
222k101648912
answered Aug 8 '16 at 10:58
Joe Strazzere
222k101648912
answered Aug 8 '16 at 10:58
Joe Strazzere
222k101648912
222k101648912
One thing I sympathize with that might be different in the OP's case is that he seems to be inheriting code from a prior development team. In that case, it isn't scope creep or vague requirements that trip you up, it's the minefield of someone else's poor design. In many projects, you won't even be able to review the code until you've agreed to do the work, and while something might sound and probably is simple on paper, a foundation of ugly design and poor coding can wreck the most reasonably padded of estimates.
– Blackhawk
Aug 9 '16 at 16:39
suggest improvements |Â
One thing I sympathize with that might be different in the OP's case is that he seems to be inheriting code from a prior development team. In that case, it isn't scope creep or vague requirements that trip you up, it's the minefield of someone else's poor design. In many projects, you won't even be able to review the code until you've agreed to do the work, and while something might sound and probably is simple on paper, a foundation of ugly design and poor coding can wreck the most reasonably padded of estimates.
– Blackhawk
Aug 9 '16 at 16:39
One thing I sympathize with that might be different in the OP's case is that he seems to be inheriting code from a prior development team. In that case, it isn't scope creep or vague requirements that trip you up, it's the minefield of someone else's poor design. In many projects, you won't even be able to review the code until you've agreed to do the work, and while something might sound and probably is simple on paper, a foundation of ugly design and poor coding can wreck the most reasonably padded of estimates.
– Blackhawk
Aug 9 '16 at 16:39
One thing I sympathize with that might be different in the OP's case is that he seems to be inheriting code from a prior development team. In that case, it isn't scope creep or vague requirements that trip you up, it's the minefield of someone else's poor design. In many projects, you won't even be able to review the code until you've agreed to do the work, and while something might sound and probably is simple on paper, a foundation of ugly design and poor coding can wreck the most reasonably padded of estimates.
– Blackhawk
Aug 9 '16 at 16:39
suggest improvements |Â
up vote
22
down vote
I won't have time to work on projects that I actually get paid for.
There are two simply answers depending on whether you're a contractor or not:
Contractor: you reply that this wasn't part of the contract or wasn't included in estimate or specification of the project you were hired for. You're happy to do these tasks at your usual rate with the understanding that it will delay other deliverables. If the tasks are too menial (e.g. you're a database specialist and they're asking you to clear up the documentation or refactor stuff) you can either say that that's not a service you provide or that you're happy to do it but your rate is still X$/h (i.e. too much for that kind of work). If you say the latter you can make it even clearer by recommending someone else for the work or pointing out that others can do it for less.
Regular employee: you are being paid for your time. Whether doing this is a good use of your time and justifies the delay on the delivery of other tasks is entirely up to your manager. Ask your manager. Note that this should be a broader conversation about your role to determine how much initiative you should take and what to say to people who take issue with your work.
answered Aug 8 '16 at 12:02
Lilienthal♦
53.9k36183218
1
I like this, because this is what I would do sort of, tell my manager there is a bunch of other things I noticed and if they want me to allocate time to resolve them.
– Kilisi
Aug 9 '16 at 0:39
suggest improvements |Â
up vote
22
down vote
I won't have time to work on projects that I actually get paid for.
There are two simply answers depending on whether you're a contractor or not:
Contractor: you reply that this wasn't part of the contract or wasn't included in estimate or specification of the project you were hired for. You're happy to do these tasks at your usual rate with the understanding that it will delay other deliverables. If the tasks are too menial (e.g. you're a database specialist and they're asking you to clear up the documentation or refactor stuff) you can either say that that's not a service you provide or that you're happy to do it but your rate is still X$/h (i.e. too much for that kind of work). If you say the latter you can make it even clearer by recommending someone else for the work or pointing out that others can do it for less.
Regular employee: you are being paid for your time. Whether doing this is a good use of your time and justifies the delay on the delivery of other tasks is entirely up to your manager. Ask your manager. Note that this should be a broader conversation about your role to determine how much initiative you should take and what to say to people who take issue with your work.
answered Aug 8 '16 at 12:02
Lilienthal♦
53.9k36183218
1
I like this, because this is what I would do sort of, tell my manager there is a bunch of other things I noticed and if they want me to allocate time to resolve them.
– Kilisi
Aug 9 '16 at 0:39
suggest improvements |Â
up vote
22
down vote
up vote
22
down vote
I won't have time to work on projects that I actually get paid for.
There are two simply answers depending on whether you're a contractor or not:
Contractor: you reply that this wasn't part of the contract or wasn't included in estimate or specification of the project you were hired for. You're happy to do these tasks at your usual rate with the understanding that it will delay other deliverables. If the tasks are too menial (e.g. you're a database specialist and they're asking you to clear up the documentation or refactor stuff) you can either say that that's not a service you provide or that you're happy to do it but your rate is still X$/h (i.e. too much for that kind of work). If you say the latter you can make it even clearer by recommending someone else for the work or pointing out that others can do it for less.
Regular employee: you are being paid for your time. Whether doing this is a good use of your time and justifies the delay on the delivery of other tasks is entirely up to your manager. Ask your manager. Note that this should be a broader conversation about your role to determine how much initiative you should take and what to say to people who take issue with your work.
answered Aug 8 '16 at 12:02
Lilienthal♦
53.9k36183218
I won't have time to work on projects that I actually get paid for.
There are two simply answers depending on whether you're a contractor or not:
Contractor: you reply that this wasn't part of the contract or wasn't included in estimate or specification of the project you were hired for. You're happy to do these tasks at your usual rate with the understanding that it will delay other deliverables. If the tasks are too menial (e.g. you're a database specialist and they're asking you to clear up the documentation or refactor stuff) you can either say that that's not a service you provide or that you're happy to do it but your rate is still X$/h (i.e. too much for that kind of work). If you say the latter you can make it even clearer by recommending someone else for the work or pointing out that others can do it for less.
Regular employee: you are being paid for your time. Whether doing this is a good use of your time and justifies the delay on the delivery of other tasks is entirely up to your manager. Ask your manager. Note that this should be a broader conversation about your role to determine how much initiative you should take and what to say to people who take issue with your work.
answered Aug 8 '16 at 12:02
Lilienthal♦
53.9k36183218
answered Aug 8 '16 at 12:02
Lilienthal♦
53.9k36183218
answered Aug 8 '16 at 12:02
Lilienthal♦
53.9k36183218
answered Aug 8 '16 at 12:02
Lilienthal♦
53.9k36183218
53.9k36183218
1
I like this, because this is what I would do sort of, tell my manager there is a bunch of other things I noticed and if they want me to allocate time to resolve them.
– Kilisi
Aug 9 '16 at 0:39
suggest improvements |Â
1
I like this, because this is what I would do sort of, tell my manager there is a bunch of other things I noticed and if they want me to allocate time to resolve them.
– Kilisi
Aug 9 '16 at 0:39
1
1
I like this, because this is what I would do sort of, tell my manager there is a bunch of other things I noticed and if they want me to allocate time to resolve them.
– Kilisi
Aug 9 '16 at 0:39
I like this, because this is what I would do sort of, tell my manager there is a bunch of other things I noticed and if they want me to allocate time to resolve them.
– Kilisi
Aug 9 '16 at 0:39
suggest improvements |Â
up vote
5
down vote
Based on your statement implying multiple projects, I'm wondering if you have multiple managers or clients, which definitely makes things complicated. However, in the case of a single manager, I would suggest that:
It is your manager's job to prioritize your workload, and it is your job to manage their expectations.
In my positions both as an employee and as a manager, it has been my experience that if the work you have been assigned is beyond your capacity, it is specifically your manager's job to prioritize it or assign it to another employee. It is your job to manage your manager's expectations.
Suppose your manager assigns you several tasks which seems doable in the allotted time, but later something changes: the deadline is moved up, some preliminary research reveals that a task will take longer than you originally thought, or an unforeseen complication arises. It is up to you to promptly notify your manager of the issue along with proposed solutions and estimates if the issue is within your area of expertise. The manager needs this information ASAP to make good decisions for the project overall.
Right now, you are preempting your manager by deciding that it is always better to check the boxes of your task list, but your manager might decide, for example:
- It is more important that you hold off on the other tasks until the issue is resolved.
- The issue can be resolved by another employee so that you can focus on the rest of your tasks.
- The issue doesn't really matter, you can safely ignore it.
- It actually is more important that you check off everything in your list of tasks, so you should ignore the issue and move on for now.
While it isn't always feasible or practical with small issues, like the one you describe, to continually run to your boss with a presentation explaining the error and a list of proposed solutions, you can at least send a note to your manager explaining the issue and then move on to the next task until you have a response from them on how they want you to prioritize your time.
answered Aug 8 '16 at 22:26
Blackhawk
36915
By way of example, I once worked on the side to help a client with tax depreciation tool that was made with recorded Excel macros :'( Because of the poor structure of the code and the utter lack of any reasonable naming convention, simple requests might take orders of magnitude longer. I would notify the client and explain the situation ASAP and give them a few options: the quick and dirty hack, the compromise or the future-proof Right Way™. That way, whatever happens was on them. They consistently chose dirty hack until they realized how much pain it caused, and finally let me rewrite.
– Blackhawk
Aug 8 '16 at 22:38
suggest improvements |Â
up vote
5
down vote
Based on your statement implying multiple projects, I'm wondering if you have multiple managers or clients, which definitely makes things complicated. However, in the case of a single manager, I would suggest that:
It is your manager's job to prioritize your workload, and it is your job to manage their expectations.
In my positions both as an employee and as a manager, it has been my experience that if the work you have been assigned is beyond your capacity, it is specifically your manager's job to prioritize it or assign it to another employee. It is your job to manage your manager's expectations.
Suppose your manager assigns you several tasks which seems doable in the allotted time, but later something changes: the deadline is moved up, some preliminary research reveals that a task will take longer than you originally thought, or an unforeseen complication arises. It is up to you to promptly notify your manager of the issue along with proposed solutions and estimates if the issue is within your area of expertise. The manager needs this information ASAP to make good decisions for the project overall.
Right now, you are preempting your manager by deciding that it is always better to check the boxes of your task list, but your manager might decide, for example:
- It is more important that you hold off on the other tasks until the issue is resolved.
- The issue can be resolved by another employee so that you can focus on the rest of your tasks.
- The issue doesn't really matter, you can safely ignore it.
- It actually is more important that you check off everything in your list of tasks, so you should ignore the issue and move on for now.
While it isn't always feasible or practical with small issues, like the one you describe, to continually run to your boss with a presentation explaining the error and a list of proposed solutions, you can at least send a note to your manager explaining the issue and then move on to the next task until you have a response from them on how they want you to prioritize your time.
answered Aug 8 '16 at 22:26
Blackhawk
36915
By way of example, I once worked on the side to help a client with tax depreciation tool that was made with recorded Excel macros :'( Because of the poor structure of the code and the utter lack of any reasonable naming convention, simple requests might take orders of magnitude longer. I would notify the client and explain the situation ASAP and give them a few options: the quick and dirty hack, the compromise or the future-proof Right Way™. That way, whatever happens was on them. They consistently chose dirty hack until they realized how much pain it caused, and finally let me rewrite.
– Blackhawk
Aug 8 '16 at 22:38
suggest improvements |Â
up vote
5
down vote
up vote
5
down vote
Based on your statement implying multiple projects, I'm wondering if you have multiple managers or clients, which definitely makes things complicated. However, in the case of a single manager, I would suggest that:
It is your manager's job to prioritize your workload, and it is your job to manage their expectations.
In my positions both as an employee and as a manager, it has been my experience that if the work you have been assigned is beyond your capacity, it is specifically your manager's job to prioritize it or assign it to another employee. It is your job to manage your manager's expectations.
Suppose your manager assigns you several tasks which seems doable in the allotted time, but later something changes: the deadline is moved up, some preliminary research reveals that a task will take longer than you originally thought, or an unforeseen complication arises. It is up to you to promptly notify your manager of the issue along with proposed solutions and estimates if the issue is within your area of expertise. The manager needs this information ASAP to make good decisions for the project overall.
Right now, you are preempting your manager by deciding that it is always better to check the boxes of your task list, but your manager might decide, for example:
- It is more important that you hold off on the other tasks until the issue is resolved.
- The issue can be resolved by another employee so that you can focus on the rest of your tasks.
- The issue doesn't really matter, you can safely ignore it.
- It actually is more important that you check off everything in your list of tasks, so you should ignore the issue and move on for now.
While it isn't always feasible or practical with small issues, like the one you describe, to continually run to your boss with a presentation explaining the error and a list of proposed solutions, you can at least send a note to your manager explaining the issue and then move on to the next task until you have a response from them on how they want you to prioritize your time.
answered Aug 8 '16 at 22:26
Blackhawk
36915
Based on your statement implying multiple projects, I'm wondering if you have multiple managers or clients, which definitely makes things complicated. However, in the case of a single manager, I would suggest that:
It is your manager's job to prioritize your workload, and it is your job to manage their expectations.
In my positions both as an employee and as a manager, it has been my experience that if the work you have been assigned is beyond your capacity, it is specifically your manager's job to prioritize it or assign it to another employee. It is your job to manage your manager's expectations.
Suppose your manager assigns you several tasks which seems doable in the allotted time, but later something changes: the deadline is moved up, some preliminary research reveals that a task will take longer than you originally thought, or an unforeseen complication arises. It is up to you to promptly notify your manager of the issue along with proposed solutions and estimates if the issue is within your area of expertise. The manager needs this information ASAP to make good decisions for the project overall.
Right now, you are preempting your manager by deciding that it is always better to check the boxes of your task list, but your manager might decide, for example:
- It is more important that you hold off on the other tasks until the issue is resolved.
- The issue can be resolved by another employee so that you can focus on the rest of your tasks.
- The issue doesn't really matter, you can safely ignore it.
- It actually is more important that you check off everything in your list of tasks, so you should ignore the issue and move on for now.
While it isn't always feasible or practical with small issues, like the one you describe, to continually run to your boss with a presentation explaining the error and a list of proposed solutions, you can at least send a note to your manager explaining the issue and then move on to the next task until you have a response from them on how they want you to prioritize your time.
answered Aug 8 '16 at 22:26
Blackhawk
36915
answered Aug 8 '16 at 22:26
Blackhawk
36915
answered Aug 8 '16 at 22:26
Blackhawk
36915
answered Aug 8 '16 at 22:26
Blackhawk
36915
36915
By way of example, I once worked on the side to help a client with tax depreciation tool that was made with recorded Excel macros :'( Because of the poor structure of the code and the utter lack of any reasonable naming convention, simple requests might take orders of magnitude longer. I would notify the client and explain the situation ASAP and give them a few options: the quick and dirty hack, the compromise or the future-proof Right Way™. That way, whatever happens was on them. They consistently chose dirty hack until they realized how much pain it caused, and finally let me rewrite.
– Blackhawk
Aug 8 '16 at 22:38
suggest improvements |Â
By way of example, I once worked on the side to help a client with tax depreciation tool that was made with recorded Excel macros :'( Because of the poor structure of the code and the utter lack of any reasonable naming convention, simple requests might take orders of magnitude longer. I would notify the client and explain the situation ASAP and give them a few options: the quick and dirty hack, the compromise or the future-proof Right Way™. That way, whatever happens was on them. They consistently chose dirty hack until they realized how much pain it caused, and finally let me rewrite.
– Blackhawk
Aug 8 '16 at 22:38
By way of example, I once worked on the side to help a client with tax depreciation tool that was made with recorded Excel macros :'( Because of the poor structure of the code and the utter lack of any reasonable naming convention, simple requests might take orders of magnitude longer. I would notify the client and explain the situation ASAP and give them a few options: the quick and dirty hack, the compromise or the future-proof Right Way™. That way, whatever happens was on them. They consistently chose dirty hack until they realized how much pain it caused, and finally let me rewrite.
– Blackhawk
Aug 8 '16 at 22:38
By way of example, I once worked on the side to help a client with tax depreciation tool that was made with recorded Excel macros :'( Because of the poor structure of the code and the utter lack of any reasonable naming convention, simple requests might take orders of magnitude longer. I would notify the client and explain the situation ASAP and give them a few options: the quick and dirty hack, the compromise or the future-proof Right Way™. That way, whatever happens was on them. They consistently chose dirty hack until they realized how much pain it caused, and finally let me rewrite.
– Blackhawk
Aug 8 '16 at 22:38
suggest improvements |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f73874%2fhow-do-i-manage-the-expectation-of-detail-orientation-at-work%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
"I did these as they had been done in the past" is not a way to get ahead. If the client wanted it how it had been done in the past, why are they hiring you? Anticipating your clients' needs goes a long way.
– Chris
Aug 8 '16 at 14:49
6
@Chris didn't hire me to make these updates, I do something totally different. Just got stuck with the task as the person is on maternity leave
– Lukas_T
Aug 8 '16 at 14:50
2
@Lukas_T what does your boss tell you to do in these cases?
– WorkerDrone
Aug 8 '16 at 16:26
2
What is your work environment? If you have a single manager assigning you all of your tasks, it is their job to prioritize your work, and your job to manage their expectations.
– Blackhawk
Aug 8 '16 at 22:18
1
Why should it be your fault your "customers" are not doing their side of the job, and that you are overworked? Document all requests.
– Rui F Ribeiro
Aug 9 '16 at 19:57