Slow coworker receiving compliments while I receive complaintsKeep getting called on my personal phoneHow to deal with your co worker telling you “not to do stuff so fast”?A major investor asked me (the software lead) whether the board should fire my boss (the Co-Founder and CTO). What should I do?
Is the number of federal judges appointed by Trump unusual?
Java OOP Temperature Converter
How can I create a n way Cartesian product of type lists in C++?
Why was LEGO reluctant to use additional colours for regular bricks in former times?
How can there exist a profession consisting of investing others' money?
How can communicating in human language with an unconscious alien species be treated as an attack?
Would it have been possible to re-fuel the planes in the air?
How bad is 1. e4 c5 2. Nf3 d6 3. a3?
Putting tools you use (but can't configure) on resume?
(x | y) - y why can't it simply be x or even `x | 0`
Forgot item in a hotel in Spain; hotel says I have to send a courier myself because they don't handle international shipments
Is it common to use pinky (little finger) on black keys?
Implementation gap in logistics
Creating 123456 in the fewest number of steps
Should I invest ~18k being 19 years old?
What would happen if a Cleric blessed a Warlock with a fiend patron?
Why would a table with a Clustered Columnstore Index have many open rowgroups?
Should I sign a NDA that holds me liable for legal fees even if I am in the right?
What is the moral difference between abortion and infanticide?
Why is an unbiased random walk non-ergodic?
Visting the UK with my own car
What would be the effect(s) of this asteroid?
Excel countif doesn't work on range denoted by
Texas gun laws - can an overseas visitor buy ammunition?
Slow coworker receiving compliments while I receive complaints
Keep getting called on my personal phoneHow to deal with your co worker telling you “not to do stuff so fast”?A major investor asked me (the software lead) whether the board should fire my boss (the Co-Founder and CTO). What should I do?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty
margin-bottom:0;
Long story short, how can a good/fast professional receive compliments about how fast and exact their fixes are?
I don't want to hear like "oh great job buddy" every time I solve a problem. But I can solve problems really fast, I'm an SQL server dba for more than 5 years and I've experienced a lot of problems that I already have scripts to solve, or I know what to do and etc. So every time there's a problem, I just fix it in minutes. But I keep hearing that I do nothing, that what I do is simple because I solve it really fast.
And there are some co-workers here that take like 2 days to solve something simple and my boss just loves it. "They're working really hard, 2 days coding nonstop" and the problem is a wrong IP, or for some reason, some setting changed.
How can I improve this? Should I work slowly? Should I send emails with the step by step of what I did?
Again, I don't want to receive a "good boy" every time, for everything I do, I just don't want to look a simple professional that just solves easy problems because I can solve them faster than other people.
professionalism brazil
add a comment
|
Long story short, how can a good/fast professional receive compliments about how fast and exact their fixes are?
I don't want to hear like "oh great job buddy" every time I solve a problem. But I can solve problems really fast, I'm an SQL server dba for more than 5 years and I've experienced a lot of problems that I already have scripts to solve, or I know what to do and etc. So every time there's a problem, I just fix it in minutes. But I keep hearing that I do nothing, that what I do is simple because I solve it really fast.
And there are some co-workers here that take like 2 days to solve something simple and my boss just loves it. "They're working really hard, 2 days coding nonstop" and the problem is a wrong IP, or for some reason, some setting changed.
How can I improve this? Should I work slowly? Should I send emails with the step by step of what I did?
Again, I don't want to receive a "good boy" every time, for everything I do, I just don't want to look a simple professional that just solves easy problems because I can solve them faster than other people.
professionalism brazil
1
Comments are not for extended discussion; this conversation has been moved to chat.
– Mister Positive♦
Oct 4 at 21:15
add a comment
|
Long story short, how can a good/fast professional receive compliments about how fast and exact their fixes are?
I don't want to hear like "oh great job buddy" every time I solve a problem. But I can solve problems really fast, I'm an SQL server dba for more than 5 years and I've experienced a lot of problems that I already have scripts to solve, or I know what to do and etc. So every time there's a problem, I just fix it in minutes. But I keep hearing that I do nothing, that what I do is simple because I solve it really fast.
And there are some co-workers here that take like 2 days to solve something simple and my boss just loves it. "They're working really hard, 2 days coding nonstop" and the problem is a wrong IP, or for some reason, some setting changed.
How can I improve this? Should I work slowly? Should I send emails with the step by step of what I did?
Again, I don't want to receive a "good boy" every time, for everything I do, I just don't want to look a simple professional that just solves easy problems because I can solve them faster than other people.
professionalism brazil
Long story short, how can a good/fast professional receive compliments about how fast and exact their fixes are?
I don't want to hear like "oh great job buddy" every time I solve a problem. But I can solve problems really fast, I'm an SQL server dba for more than 5 years and I've experienced a lot of problems that I already have scripts to solve, or I know what to do and etc. So every time there's a problem, I just fix it in minutes. But I keep hearing that I do nothing, that what I do is simple because I solve it really fast.
And there are some co-workers here that take like 2 days to solve something simple and my boss just loves it. "They're working really hard, 2 days coding nonstop" and the problem is a wrong IP, or for some reason, some setting changed.
How can I improve this? Should I work slowly? Should I send emails with the step by step of what I did?
Again, I don't want to receive a "good boy" every time, for everything I do, I just don't want to look a simple professional that just solves easy problems because I can solve them faster than other people.
professionalism brazil
professionalism brazil
edited Oct 4 at 14:06
LP154
4,11512 silver badges29 bronze badges
4,11512 silver badges29 bronze badges
asked Oct 2 at 16:09
Green BaloonGreen Baloon
1,9244 gold badges9 silver badges17 bronze badges
1,9244 gold badges9 silver badges17 bronze badges
1
Comments are not for extended discussion; this conversation has been moved to chat.
– Mister Positive♦
Oct 4 at 21:15
add a comment
|
1
Comments are not for extended discussion; this conversation has been moved to chat.
– Mister Positive♦
Oct 4 at 21:15
1
1
Comments are not for extended discussion; this conversation has been moved to chat.
– Mister Positive♦
Oct 4 at 21:15
Comments are not for extended discussion; this conversation has been moved to chat.
– Mister Positive♦
Oct 4 at 21:15
add a comment
|
10 Answers
10
active
oldest
votes
A lot of this depends on how you communicate when you fix a problem. Compare:
Ok, that's good now.
With
That problem is solved: I ran a script I wrote last year when that sort of thing started happening more frequently. It used to take a day to fix, now the script takes care of it in minutes!
People can't know that you're using your great skills if you shrug it off when you do it. And reminding people of the asset base of scripts etc you are building up is always helpful. As for the comments about what a hard worker the code-for-two-days person is, if you really must you could reply "I heard it was a misconfiguration in the end so I don't know why it needed days of coding to solve." But a better approach might be to offer to help prevent these things from spiraling into so much work. Your coworkers almost certainly don't enjoy those days of wasted effort, even if they're praised for them.
Back to you, you can also remind people of your experience when you take a task:
OK, sure, that reminds me of something I tackled a few years ago on the X project, so I can probably do it quicker than those who haven't seen it before. I'll let you know if it's what I think it is.
Then when you see it, you can be
Yup, it's something I've seen before, expect a fix within the hour
And people understand, these aren't necessarily easy problems, they have an experienced employee.
90
Also, at least weekly let your boss know how many of those you've fixed, or make sure they are tracked in your bug tracking system. Boss needs to see that you've fixed 36 issues when co-worker fixed 4.
– thursdaysgeek
Oct 2 at 17:30
96
These are basically sales and marketing tricks that Engineers need to learn.
– Nav
Oct 3 at 6:26
7
I am this 'slow' co-worker, albeit in a different context. I would not say I am less productive, just more reserved. Our development relies heavily on quality control, and it is often more important to make the right fix in more time, than making the quick fix right away. Making the right trade-off, and selling it right, is often more important in my line of work. What I'm trying to say is: maybe keep your boss in the loop more tightly on the kind of trade-offs that you are making to show that your choices are the right ones, in addition to just selling yourself better anyway.
– SBI
Oct 3 at 8:18
3
this. If you fix an issue, you should always make sure to explain what you did, and why it works. As a dev, whenever I fix an issue, I make sure to explain what the issue is, and it's impact. What causes the issue. What I did to fix the issue, and why it fixes the issue. This has several benefits : nobody can undermine what you did, if you give enough details. And if somebody has a similar issue, they have something to learn from.
– user3399
Oct 3 at 9:32
7
I'm an engineer (literally, several engineering degrees) and very technical. Running a company means persuading people to buy our services, among other things, so I have some skills at that. I don't like the word "tricks" to describe this advice. Reminding people what you did, that you are good at your job, and why you're delivering what they need quickly is not a trick: it's honest and important. Without it, the firm might make bad choices and lose a good contributor. They need full information including how this worker is getting things done quickly because they are experienced.
– Kate Gregory
Oct 4 at 11:28
|
show 10 more comments
I have a similar problem.
Word for word from my boss "He can do things in 15 minutes that would take someone else a week to do"
There is a phrase out there that I hate to use but here goes...
You need to learn to "manage expectations"
People often mistake the fact that since something is easy FOR YOU it must be easy to do.
I know people, myself included, who were doing their jobs, and THOUGHT they were appreciated, move on (either voluntarily or otherwise) and then the company realizes what they did, and need to be replaced by three people.
FULL DISCLOSURE:
I have used the following book personally, and do not get any compensation from any author or retailer.
The book "Brag, the art of tooting your own horn without blowing it" Has been a god-send to me.
Like you I used to assume that my work would just speak for itself, it doesn't, get the book.
Now, the rest of your problem takes a bit of finesse because it's a perception problem.
If the standard turnaround is 2 days, and you do it in twenty minutes, the ASSUMPTION is going to be that you took shortcuts or something. Remember, you are being managed by people who don't understand how you do what you do.
- SLOW YOUR ROLL: Seriously, sit on projects a bit. Instead of turning things around in 20 minutes, make it a few hours before you implement them.
- Let everyone know just how much you are doing (see the book reccomendation above)
- Act with enthusiasm! WOW! THIS IS GREAT! I THOUGHT THIS WAS GOING TO TAKE MUCH LONGER
As a CEO once told me "Always take the credit because you WILL take the blame!"
Dramatize your solutions, and TALK TO PEOPLE.
Everything is sales, my friend, everything.
33
Geordi La Forge: "Yeah, well, I told the Captain I’d have this analysis done in an hour." Scotty: "How long will it really take?" - The Montgomery Scott Guide To Project Management Skills
– Mazura
Oct 3 at 1:59
9
Always take the credit because you WILL take the blame!
that has put my whole morning into perspective
– PeterH
Oct 3 at 7:25
11
If you can fix something in 20 minutes, I think it's bad to make it several hours instead. Don't waste time. If anything, use a little time logging the fix to make your work visible, but don't waste the time just to make a quick fix seem like a complicated problem. It could reflect poorly on your if people find out later.
– Gertsen
Oct 3 at 7:52
7
(3) might fly in the US, but certainly won't in all cultures. In germany, if you act that way, you'd be seen as unprofessional and weird. OP specified brazil, so I'm not sure if this would be a good idea. managing expectations is good, fake enthusiasm might not be.
– Polygnome
Oct 3 at 8:47
5
"Everything is sales, my friend, everything" and this is one of the reasons our current society is so f**d up. It is not relevant what you do, but how you sell it!
– Thomas
Oct 3 at 10:24
|
show 14 more comments
Teach
If the problem is that your coworker is slow, your whole team will do better if you help them get faster. Of course, they need to want assistance, so the way you offer it makes all the difference in the world. Next time they are working on a bug, just casually ask if you can help them look at anything. If they accept the help, give gentle advice and pointers on how to speed up the investigation.
Lead
If your coworker realizes that you are really helpful, then soon they will start coming to you for assistance. That's great, because eventually people will see them at your desk getting consultation and helping them work through problems. If several coworkers are seen coming your desk regularly for help, then others will eventually realize that you are a thought leader and problem solver, and your coworkers will eventually start saying things like: "Well, this would go a lot faster if we had Green Baloon here. Ted, can you go see if he's at his desk?"
The goal is not for your boss to see that you work 5x faster than the rest of your team. The goal is for your boss to say: "Huh...it used to take 3-4 days for you guys to turn around these bugs, but now you're destroying them in a few hours. What's the difference?" At this point, the responses will depend very much on how your coworkers view you. If they think you are arrogant or will try to steal all the credit, they will just take credit themselves and say that they've been leveling up their skills, while you appear to be sitting still. If, on the other hand, they see you as someone who is generous with his time and willing to do what it takes to move the whole team forward, then they will be happy to give you credit for helping them out. They might do it indirectly, like: "Well, Green Baloon shared some scripts with the team that have really helped us power through some issues", but if you have done a very good job of being a team player, they should feel comfortable saying something like: "Green Baloon is the go-to guy when we get stuck, truth be told."
Judgment Call
You have to use your own personal judgment to decide what kind of coworkers you have, and what kind of responses they are likely to give in the scenario above when you decide to invest in them as team members. If they are a bit selfish, then you should probably do the minimum to keep the team unblocked and working on the good stuff. If they are fair-minded, then investing extra time in skilling them up will eventually turn into positive press for you one way or another. The key is to make it clear that you are trying to help them and help the team, and not just taking credit for fixing stuff.
Document
When it comes time for reviews, you want to have a history of good work that you've done. So when you contribute tools to the team, write it down in your personal journal. When you help other people, write it down. When your boss asks why you think you deserve a raise/promotion, bring out your journal. Don't focus on who you have helped, but rather, how you have become a force multiplier that makes the whole team faster and more efficient, which also helps your boss look better. It's not about: "I'm 5x faster than Ted." It's about: "Well, you may have noticed that the team is getting stuff done faster. Let me show you some of the reasons why."
Once your boss figures out that you are improving the whole team, if they have two brain cells to rub together, they will realize that you are their meal ticket to advancement. If they are a bit slow on the uptake, spell out this obvious fact for them, as diplomatically as possible: "So, what do the other directors say about our department? How have you been selling our work? Did your boss notice our throughput has gone up? Surely that's been good for you, hasn't it?" Make it clear that your boss gets to take credit for your whole team improving. They will figure out that it didn't happen magically, and if they want more improvement, they have to reward the person who is actually driving the changes.
If your team and/or boss don't respond positively to your best efforts, then it's time to switch teams/company.
Good answer there +
– QHarr
Oct 5 at 19:18
add a comment
|
What you need to achieve that every problem gets recorded, assigned to someone to fix, and then it needs to be recorded who fixed it. Then it should be a simple count, how many problems you fixed and how many someone else fixed.
If you are still told that you only solve easy problems then you need to demonstrate that you are solving hard problems by taking two days for a problem like your colleague. (Assume that this is sarcastic).
If you are really annoyed, and you are sure that your colleague takes two days for five minute problems then you can start systematically providing solutions for his problems after a day.
PS. Estimating every task works wonders as well.
1
That's what happened today. There was a problem and I knew they would take a lot of time to solve and I just say loudly " try this this this, I got a script that does that, and then you can x". I must say it worked.
– Green Baloon
Oct 2 at 17:24
1
Task tracking needs to include the expected effort to fix the problem in order for it to be effective at review time. Agile is a great way to formally handle this. The numbers put on each task include time as well as other factors to add up to a better qualifier. Ex: Jimmy solved 500 tasks in a year and each was only an effort of 1; Susan solved 250 tasks with efforts from 2 - 8 and the average was 3; Susan's effort was greater than Jimmy's, even though Jimmy did more tasks. This shows Susan did more work in the same time in a better way than simple quantity of tasks.
– computercarguy
Oct 3 at 23:01
2
@computercarguy That is an excellent way to note contributor value. I once worked at a call center where the first employee to reach "500" calls completed was openly celebrated. I couldn't help but notice that 80% of their calls were password resets that only took 10 minutes. Other people were solving far more difficult issues that sometimes took multiple calls over multiple days that I know that "Agent 500" would never have been able to solve at all. This isn't to say that those calls weren't important, but the contributions of other agents were probably more valuable in the long term.
– Booga Roo
Oct 4 at 19:59
@BoogaRoo, I know, right? I worked at call centers before and saw similar things. Agents with average call times way below the required max and a high callback rate. I've also seen "senior" devs that do "quick fixes" on tasks that end up recurring dozens of times because they keep recurring. That's somewhat to be expected of juniors, but not seniors. Yeah, expected effort and recurrence need tracked, too.
– computercarguy
Oct 4 at 21:01
@GreenBaloon - "That's what happened today. There was a problem and I knew they would take a lot of time to solve and I just say loudly " try this this this, I got a script that does that, and then you can x". I must say it worked." My advice: don't give it away. Track the work, make sure to show the data on how much you've done. Wait until you boss asks you to teach the others.
– Diagon
Oct 5 at 1:16
|
show 1 more comment
Enumerate the problems with some kind of tracking system.
A tracking system would be a good thing to have anyway because it would help prevent duplicated work, highlight recurring problems, and allow you to build a clearer picture of how the team functions. Amongst other things your boss could use the stats to demonstrate how good his department is (we solved 90% of problems within 2 days).
The secret objective here is that once you track the problems your boss will realise how much work you do. Especially if they use the stats to demonstrate departmental performance.
Using Agile is one method I've used to track tasks. It allows for tracking effort as well and that is voted on by several devs. If a task is "changing the IP", it'll be low and expect to take next to no time. If a task is developing a new form with a new DB table and server code to handle it, it'll be high. So if a low value effort takes more time than necessary or a high value takes less time, it's much more obvious, along with repeats of the same task(s). You can also track dev to see why the tasks didn't stay fixed, if that's what's actually happening, too.
– computercarguy
Oct 3 at 23:06
This is an ideal way to go. You should have an issue management system anyway. It is very useful tool for making productivity visible, with many other benefits.
– Keith
Oct 5 at 4:51
add a comment
|
Can you become a star?
Since you're able to get tasks done quicker than others, is it feasible for you to take on a larger chunk of the team's work? Volunteer for more tasks, especially hard tasks that you know you can solve quickly.
Then as long as you also make it clear [1] (as others have suggested) that these tasks aren't easy, they're just easy for you, you will be perceived as a star on the team, not a slacker.
I would also recommend what others have suggested: train others, teach your processes, and share your tools [2] so you can lift up your entire team.
NOTE:
- Figure out how to do this with humility; arrogance is incompatible with professionalism.
- Make sure your tools work well enough first though.
It seems he is taking on more of the work already.
– gnasher729
Oct 5 at 6:15
add a comment
|
There's one thing I can think of but I don't know how appropriate it is. Because it's going on the offensive. Caveat emptor.
Next time you get that comment, keep your posture friendly and deliver a short script you've already prepared, similar to this:
I'm sorry $Boss, this is not the first time you've made this comment and it simply isn't true. I didn't say anything before because I don't want to be perceived as throwing $Coworker under the bus / I found the situation stressful / I could not think how to properly object to this. I propose that, going forward, every ticket we receive must be estimated by both me and $Coworker before they are added to the backlog. It's a good idea anyway, and while I think $Coworker is indeed good at his job, this should not be judged solely on how long tickets take. But I don't know how to communicate this to someone non-technical.
Whoa, bit of a poem. As I said, going on the offensive. The objective here is not to actually do estimates, but to demonstrate your confidence in your skills. If you wanna go even harder, you can propose to setup environments that replicate each complex issue when they come in, and then have each of you work on the other's issues every second Friday after lunch.
1
I'd add that this should be in private, and OP should see how the boss responds to the first bit before proposing competitive estimates - it may be that the boss is well aware of the situation and just feels that the slow guy needs encouragement.
– Robin Bennett
Oct 3 at 8:28
add a comment
|
I'm not sure you necessarily need to do anything here.
In my experience, while people might comment on someone working hard, what they really care about is how quickly you fix things for them. They might not comment on it, but after a few years, the best project managers know how to find the resource that will fix the problem the fastest when it's important. They know, because in the past when they assign you things they get done quickly. That will translate to you getting the more important and challenging work, which will translate to your boss giving you better reviews - if you are properly showing your boss what you did that is worth said review, of course.
On Thursday, perhaps the programmer working diligently on the problem will get the kudos. On review day, the programmer who saved the company's bacon in minutes when the client facing application was down, four times, will get them.
While this can be a way to go, it hinges on the "halo effect", which is the OP's problem. If "Kevin" fixes a problem on the Thursday before review, they get the halo, when the "4x major customer save" was several months previous and forgotten, unless it's brought up specifically by the fixer. Unfortunately, doing that can seem like bragging and work against you. It can also be diminished by how quick it was done and 20/20 hindsight. "Oh, it wasn't really as big of a problem as we originally thought." Good managers don't forget saves, but everyone else does.
– computercarguy
Oct 4 at 22:10
add a comment
|
Don't worry about it and focus your energy on something else that matters in life. With experience you will find that it all comes out in the end.
3
I wish it worked like this. In reality, and I've been there many time before, you just end up a doormat that gets fired because you are invisible and the idiot is "the star" for "working so hard" on things that are simple. There's definitely a lot to be said for living life outside of your job, but job satisfaction is a major factor in having a happy life. Dreading work each morning isn't healthy.
– computercarguy
Oct 3 at 23:13
add a comment
|
I think you have some pretty blah answers here that seem to be more concerned on you marketing yourself than the reality of your job.
Here are the facts:
- your manager has no clue on a "technical" level
- your company is very low tech
- your fellow coworkers on the tech side are mediocre at best
- being better at your job no way ensures you of moving up or getting paid more because of the knowledge debt at your company
What would I do?
- Be a d*ck. Yep be the guy that is a hard ass and bluntly honest about how long something should take whatever. Not trying to belittle coworkers but an honesty that is kind of backstabbing but only because they aren't very good.
- Be slower. Take your time doing things. Teach yourself other things while you are troubleshooting and make everything take 5 times longer.
- Work on other co-workers things when they are taking to long. This goes with points 1 and 2. Anytime you know a coworker is struggling with something that is "easy" then start working on that and just link that troubleshooting to something you were doing or just act like you accidentally stumbled on the solution. This will bring context to your abilities vs. your coworkers. Don't just do it a few times
If you want to be the nice guy just "market" yourself better. If you want to be everyone's boss in two years be a d*ck.
Edit: For those who think this could backfire or OP could have issues taking this route.
- Yes I get it. I don't think I was beating around the bush. This employee is really much better than the rest of his team but management is treating him as the same or less. So he can sit around and accept this and watch some morons or lesser skilled employees advance and possibly be his future boss or he can take action. My point is he has nothing to lose. Worst case scenario is that the company thinks is is a dck and doesn't like him but understands he is much more qualified than others. So yea he could lose his job for personal reasons (I highly doubt this and he shouldn't give a crap working for a company in this situation). But another scenario is management thinks he is a dck but also really smart, aggressive and take charge - you know like a really good tech director. And then the other is he can do this without people thinking he is a d*ck and the company will think they have some genius on their hands. To me the risk is well worth the effort here. If he gets canned he will surely have notice and if he doesn't this is the tactic to move up the quickest.
3 before 1. OP needs evidence and backing from management before 1 will work
– aidan.plenert.macdonald
Oct 3 at 22:03
FYI, this can really backfire badly. The dck will get fired before the slow guy, since the slow guy is "good" and no one likes the dck. "He's just a poser anyway." You need to prove yourself to be a "known good" first before trying this, which it appears the OP doesn't have on their side right now. So I definitely agree: 3 before 1.
– computercarguy
Oct 3 at 23:10
1
-1 "Be a dick and do nice backstabbing". This is not the advice that I would give even if it works. I have to stick to my morals and ethics. I consider them to be very important.
– Michael Durrant
Oct 4 at 11:28
3
Also 'your management has no clue' is insanely arrogant (because it is a blanket statement) and will lead you to an attitude that will others will find disturbing when trying to work with you.
– Michael Durrant
Oct 4 at 11:29
@computercarguy - sure it is a bit risky. I will update my response.
– blankip
Oct 4 at 21:44
add a comment
|
10 Answers
10
active
oldest
votes
10 Answers
10
active
oldest
votes
active
oldest
votes
active
oldest
votes
A lot of this depends on how you communicate when you fix a problem. Compare:
Ok, that's good now.
With
That problem is solved: I ran a script I wrote last year when that sort of thing started happening more frequently. It used to take a day to fix, now the script takes care of it in minutes!
People can't know that you're using your great skills if you shrug it off when you do it. And reminding people of the asset base of scripts etc you are building up is always helpful. As for the comments about what a hard worker the code-for-two-days person is, if you really must you could reply "I heard it was a misconfiguration in the end so I don't know why it needed days of coding to solve." But a better approach might be to offer to help prevent these things from spiraling into so much work. Your coworkers almost certainly don't enjoy those days of wasted effort, even if they're praised for them.
Back to you, you can also remind people of your experience when you take a task:
OK, sure, that reminds me of something I tackled a few years ago on the X project, so I can probably do it quicker than those who haven't seen it before. I'll let you know if it's what I think it is.
Then when you see it, you can be
Yup, it's something I've seen before, expect a fix within the hour
And people understand, these aren't necessarily easy problems, they have an experienced employee.
90
Also, at least weekly let your boss know how many of those you've fixed, or make sure they are tracked in your bug tracking system. Boss needs to see that you've fixed 36 issues when co-worker fixed 4.
– thursdaysgeek
Oct 2 at 17:30
96
These are basically sales and marketing tricks that Engineers need to learn.
– Nav
Oct 3 at 6:26
7
I am this 'slow' co-worker, albeit in a different context. I would not say I am less productive, just more reserved. Our development relies heavily on quality control, and it is often more important to make the right fix in more time, than making the quick fix right away. Making the right trade-off, and selling it right, is often more important in my line of work. What I'm trying to say is: maybe keep your boss in the loop more tightly on the kind of trade-offs that you are making to show that your choices are the right ones, in addition to just selling yourself better anyway.
– SBI
Oct 3 at 8:18
3
this. If you fix an issue, you should always make sure to explain what you did, and why it works. As a dev, whenever I fix an issue, I make sure to explain what the issue is, and it's impact. What causes the issue. What I did to fix the issue, and why it fixes the issue. This has several benefits : nobody can undermine what you did, if you give enough details. And if somebody has a similar issue, they have something to learn from.
– user3399
Oct 3 at 9:32
7
I'm an engineer (literally, several engineering degrees) and very technical. Running a company means persuading people to buy our services, among other things, so I have some skills at that. I don't like the word "tricks" to describe this advice. Reminding people what you did, that you are good at your job, and why you're delivering what they need quickly is not a trick: it's honest and important. Without it, the firm might make bad choices and lose a good contributor. They need full information including how this worker is getting things done quickly because they are experienced.
– Kate Gregory
Oct 4 at 11:28
|
show 10 more comments
A lot of this depends on how you communicate when you fix a problem. Compare:
Ok, that's good now.
With
That problem is solved: I ran a script I wrote last year when that sort of thing started happening more frequently. It used to take a day to fix, now the script takes care of it in minutes!
People can't know that you're using your great skills if you shrug it off when you do it. And reminding people of the asset base of scripts etc you are building up is always helpful. As for the comments about what a hard worker the code-for-two-days person is, if you really must you could reply "I heard it was a misconfiguration in the end so I don't know why it needed days of coding to solve." But a better approach might be to offer to help prevent these things from spiraling into so much work. Your coworkers almost certainly don't enjoy those days of wasted effort, even if they're praised for them.
Back to you, you can also remind people of your experience when you take a task:
OK, sure, that reminds me of something I tackled a few years ago on the X project, so I can probably do it quicker than those who haven't seen it before. I'll let you know if it's what I think it is.
Then when you see it, you can be
Yup, it's something I've seen before, expect a fix within the hour
And people understand, these aren't necessarily easy problems, they have an experienced employee.
90
Also, at least weekly let your boss know how many of those you've fixed, or make sure they are tracked in your bug tracking system. Boss needs to see that you've fixed 36 issues when co-worker fixed 4.
– thursdaysgeek
Oct 2 at 17:30
96
These are basically sales and marketing tricks that Engineers need to learn.
– Nav
Oct 3 at 6:26
7
I am this 'slow' co-worker, albeit in a different context. I would not say I am less productive, just more reserved. Our development relies heavily on quality control, and it is often more important to make the right fix in more time, than making the quick fix right away. Making the right trade-off, and selling it right, is often more important in my line of work. What I'm trying to say is: maybe keep your boss in the loop more tightly on the kind of trade-offs that you are making to show that your choices are the right ones, in addition to just selling yourself better anyway.
– SBI
Oct 3 at 8:18
3
this. If you fix an issue, you should always make sure to explain what you did, and why it works. As a dev, whenever I fix an issue, I make sure to explain what the issue is, and it's impact. What causes the issue. What I did to fix the issue, and why it fixes the issue. This has several benefits : nobody can undermine what you did, if you give enough details. And if somebody has a similar issue, they have something to learn from.
– user3399
Oct 3 at 9:32
7
I'm an engineer (literally, several engineering degrees) and very technical. Running a company means persuading people to buy our services, among other things, so I have some skills at that. I don't like the word "tricks" to describe this advice. Reminding people what you did, that you are good at your job, and why you're delivering what they need quickly is not a trick: it's honest and important. Without it, the firm might make bad choices and lose a good contributor. They need full information including how this worker is getting things done quickly because they are experienced.
– Kate Gregory
Oct 4 at 11:28
|
show 10 more comments
A lot of this depends on how you communicate when you fix a problem. Compare:
Ok, that's good now.
With
That problem is solved: I ran a script I wrote last year when that sort of thing started happening more frequently. It used to take a day to fix, now the script takes care of it in minutes!
People can't know that you're using your great skills if you shrug it off when you do it. And reminding people of the asset base of scripts etc you are building up is always helpful. As for the comments about what a hard worker the code-for-two-days person is, if you really must you could reply "I heard it was a misconfiguration in the end so I don't know why it needed days of coding to solve." But a better approach might be to offer to help prevent these things from spiraling into so much work. Your coworkers almost certainly don't enjoy those days of wasted effort, even if they're praised for them.
Back to you, you can also remind people of your experience when you take a task:
OK, sure, that reminds me of something I tackled a few years ago on the X project, so I can probably do it quicker than those who haven't seen it before. I'll let you know if it's what I think it is.
Then when you see it, you can be
Yup, it's something I've seen before, expect a fix within the hour
And people understand, these aren't necessarily easy problems, they have an experienced employee.
A lot of this depends on how you communicate when you fix a problem. Compare:
Ok, that's good now.
With
That problem is solved: I ran a script I wrote last year when that sort of thing started happening more frequently. It used to take a day to fix, now the script takes care of it in minutes!
People can't know that you're using your great skills if you shrug it off when you do it. And reminding people of the asset base of scripts etc you are building up is always helpful. As for the comments about what a hard worker the code-for-two-days person is, if you really must you could reply "I heard it was a misconfiguration in the end so I don't know why it needed days of coding to solve." But a better approach might be to offer to help prevent these things from spiraling into so much work. Your coworkers almost certainly don't enjoy those days of wasted effort, even if they're praised for them.
Back to you, you can also remind people of your experience when you take a task:
OK, sure, that reminds me of something I tackled a few years ago on the X project, so I can probably do it quicker than those who haven't seen it before. I'll let you know if it's what I think it is.
Then when you see it, you can be
Yup, it's something I've seen before, expect a fix within the hour
And people understand, these aren't necessarily easy problems, they have an experienced employee.
answered Oct 2 at 16:34
Kate GregoryKate Gregory
118k47 gold badges264 silver badges366 bronze badges
118k47 gold badges264 silver badges366 bronze badges
90
Also, at least weekly let your boss know how many of those you've fixed, or make sure they are tracked in your bug tracking system. Boss needs to see that you've fixed 36 issues when co-worker fixed 4.
– thursdaysgeek
Oct 2 at 17:30
96
These are basically sales and marketing tricks that Engineers need to learn.
– Nav
Oct 3 at 6:26
7
I am this 'slow' co-worker, albeit in a different context. I would not say I am less productive, just more reserved. Our development relies heavily on quality control, and it is often more important to make the right fix in more time, than making the quick fix right away. Making the right trade-off, and selling it right, is often more important in my line of work. What I'm trying to say is: maybe keep your boss in the loop more tightly on the kind of trade-offs that you are making to show that your choices are the right ones, in addition to just selling yourself better anyway.
– SBI
Oct 3 at 8:18
3
this. If you fix an issue, you should always make sure to explain what you did, and why it works. As a dev, whenever I fix an issue, I make sure to explain what the issue is, and it's impact. What causes the issue. What I did to fix the issue, and why it fixes the issue. This has several benefits : nobody can undermine what you did, if you give enough details. And if somebody has a similar issue, they have something to learn from.
– user3399
Oct 3 at 9:32
7
I'm an engineer (literally, several engineering degrees) and very technical. Running a company means persuading people to buy our services, among other things, so I have some skills at that. I don't like the word "tricks" to describe this advice. Reminding people what you did, that you are good at your job, and why you're delivering what they need quickly is not a trick: it's honest and important. Without it, the firm might make bad choices and lose a good contributor. They need full information including how this worker is getting things done quickly because they are experienced.
– Kate Gregory
Oct 4 at 11:28
|
show 10 more comments
90
Also, at least weekly let your boss know how many of those you've fixed, or make sure they are tracked in your bug tracking system. Boss needs to see that you've fixed 36 issues when co-worker fixed 4.
– thursdaysgeek
Oct 2 at 17:30
96
These are basically sales and marketing tricks that Engineers need to learn.
– Nav
Oct 3 at 6:26
7
I am this 'slow' co-worker, albeit in a different context. I would not say I am less productive, just more reserved. Our development relies heavily on quality control, and it is often more important to make the right fix in more time, than making the quick fix right away. Making the right trade-off, and selling it right, is often more important in my line of work. What I'm trying to say is: maybe keep your boss in the loop more tightly on the kind of trade-offs that you are making to show that your choices are the right ones, in addition to just selling yourself better anyway.
– SBI
Oct 3 at 8:18
3
this. If you fix an issue, you should always make sure to explain what you did, and why it works. As a dev, whenever I fix an issue, I make sure to explain what the issue is, and it's impact. What causes the issue. What I did to fix the issue, and why it fixes the issue. This has several benefits : nobody can undermine what you did, if you give enough details. And if somebody has a similar issue, they have something to learn from.
– user3399
Oct 3 at 9:32
7
I'm an engineer (literally, several engineering degrees) and very technical. Running a company means persuading people to buy our services, among other things, so I have some skills at that. I don't like the word "tricks" to describe this advice. Reminding people what you did, that you are good at your job, and why you're delivering what they need quickly is not a trick: it's honest and important. Without it, the firm might make bad choices and lose a good contributor. They need full information including how this worker is getting things done quickly because they are experienced.
– Kate Gregory
Oct 4 at 11:28
90
90
Also, at least weekly let your boss know how many of those you've fixed, or make sure they are tracked in your bug tracking system. Boss needs to see that you've fixed 36 issues when co-worker fixed 4.
– thursdaysgeek
Oct 2 at 17:30
Also, at least weekly let your boss know how many of those you've fixed, or make sure they are tracked in your bug tracking system. Boss needs to see that you've fixed 36 issues when co-worker fixed 4.
– thursdaysgeek
Oct 2 at 17:30
96
96
These are basically sales and marketing tricks that Engineers need to learn.
– Nav
Oct 3 at 6:26
These are basically sales and marketing tricks that Engineers need to learn.
– Nav
Oct 3 at 6:26
7
7
I am this 'slow' co-worker, albeit in a different context. I would not say I am less productive, just more reserved. Our development relies heavily on quality control, and it is often more important to make the right fix in more time, than making the quick fix right away. Making the right trade-off, and selling it right, is often more important in my line of work. What I'm trying to say is: maybe keep your boss in the loop more tightly on the kind of trade-offs that you are making to show that your choices are the right ones, in addition to just selling yourself better anyway.
– SBI
Oct 3 at 8:18
I am this 'slow' co-worker, albeit in a different context. I would not say I am less productive, just more reserved. Our development relies heavily on quality control, and it is often more important to make the right fix in more time, than making the quick fix right away. Making the right trade-off, and selling it right, is often more important in my line of work. What I'm trying to say is: maybe keep your boss in the loop more tightly on the kind of trade-offs that you are making to show that your choices are the right ones, in addition to just selling yourself better anyway.
– SBI
Oct 3 at 8:18
3
3
this. If you fix an issue, you should always make sure to explain what you did, and why it works. As a dev, whenever I fix an issue, I make sure to explain what the issue is, and it's impact. What causes the issue. What I did to fix the issue, and why it fixes the issue. This has several benefits : nobody can undermine what you did, if you give enough details. And if somebody has a similar issue, they have something to learn from.
– user3399
Oct 3 at 9:32
this. If you fix an issue, you should always make sure to explain what you did, and why it works. As a dev, whenever I fix an issue, I make sure to explain what the issue is, and it's impact. What causes the issue. What I did to fix the issue, and why it fixes the issue. This has several benefits : nobody can undermine what you did, if you give enough details. And if somebody has a similar issue, they have something to learn from.
– user3399
Oct 3 at 9:32
7
7
I'm an engineer (literally, several engineering degrees) and very technical. Running a company means persuading people to buy our services, among other things, so I have some skills at that. I don't like the word "tricks" to describe this advice. Reminding people what you did, that you are good at your job, and why you're delivering what they need quickly is not a trick: it's honest and important. Without it, the firm might make bad choices and lose a good contributor. They need full information including how this worker is getting things done quickly because they are experienced.
– Kate Gregory
Oct 4 at 11:28
I'm an engineer (literally, several engineering degrees) and very technical. Running a company means persuading people to buy our services, among other things, so I have some skills at that. I don't like the word "tricks" to describe this advice. Reminding people what you did, that you are good at your job, and why you're delivering what they need quickly is not a trick: it's honest and important. Without it, the firm might make bad choices and lose a good contributor. They need full information including how this worker is getting things done quickly because they are experienced.
– Kate Gregory
Oct 4 at 11:28
|
show 10 more comments
I have a similar problem.
Word for word from my boss "He can do things in 15 minutes that would take someone else a week to do"
There is a phrase out there that I hate to use but here goes...
You need to learn to "manage expectations"
People often mistake the fact that since something is easy FOR YOU it must be easy to do.
I know people, myself included, who were doing their jobs, and THOUGHT they were appreciated, move on (either voluntarily or otherwise) and then the company realizes what they did, and need to be replaced by three people.
FULL DISCLOSURE:
I have used the following book personally, and do not get any compensation from any author or retailer.
The book "Brag, the art of tooting your own horn without blowing it" Has been a god-send to me.
Like you I used to assume that my work would just speak for itself, it doesn't, get the book.
Now, the rest of your problem takes a bit of finesse because it's a perception problem.
If the standard turnaround is 2 days, and you do it in twenty minutes, the ASSUMPTION is going to be that you took shortcuts or something. Remember, you are being managed by people who don't understand how you do what you do.
- SLOW YOUR ROLL: Seriously, sit on projects a bit. Instead of turning things around in 20 minutes, make it a few hours before you implement them.
- Let everyone know just how much you are doing (see the book reccomendation above)
- Act with enthusiasm! WOW! THIS IS GREAT! I THOUGHT THIS WAS GOING TO TAKE MUCH LONGER
As a CEO once told me "Always take the credit because you WILL take the blame!"
Dramatize your solutions, and TALK TO PEOPLE.
Everything is sales, my friend, everything.
33
Geordi La Forge: "Yeah, well, I told the Captain I’d have this analysis done in an hour." Scotty: "How long will it really take?" - The Montgomery Scott Guide To Project Management Skills
– Mazura
Oct 3 at 1:59
9
Always take the credit because you WILL take the blame!
that has put my whole morning into perspective
– PeterH
Oct 3 at 7:25
11
If you can fix something in 20 minutes, I think it's bad to make it several hours instead. Don't waste time. If anything, use a little time logging the fix to make your work visible, but don't waste the time just to make a quick fix seem like a complicated problem. It could reflect poorly on your if people find out later.
– Gertsen
Oct 3 at 7:52
7
(3) might fly in the US, but certainly won't in all cultures. In germany, if you act that way, you'd be seen as unprofessional and weird. OP specified brazil, so I'm not sure if this would be a good idea. managing expectations is good, fake enthusiasm might not be.
– Polygnome
Oct 3 at 8:47
5
"Everything is sales, my friend, everything" and this is one of the reasons our current society is so f**d up. It is not relevant what you do, but how you sell it!
– Thomas
Oct 3 at 10:24
|
show 14 more comments
I have a similar problem.
Word for word from my boss "He can do things in 15 minutes that would take someone else a week to do"
There is a phrase out there that I hate to use but here goes...
You need to learn to "manage expectations"
People often mistake the fact that since something is easy FOR YOU it must be easy to do.
I know people, myself included, who were doing their jobs, and THOUGHT they were appreciated, move on (either voluntarily or otherwise) and then the company realizes what they did, and need to be replaced by three people.
FULL DISCLOSURE:
I have used the following book personally, and do not get any compensation from any author or retailer.
The book "Brag, the art of tooting your own horn without blowing it" Has been a god-send to me.
Like you I used to assume that my work would just speak for itself, it doesn't, get the book.
Now, the rest of your problem takes a bit of finesse because it's a perception problem.
If the standard turnaround is 2 days, and you do it in twenty minutes, the ASSUMPTION is going to be that you took shortcuts or something. Remember, you are being managed by people who don't understand how you do what you do.
- SLOW YOUR ROLL: Seriously, sit on projects a bit. Instead of turning things around in 20 minutes, make it a few hours before you implement them.
- Let everyone know just how much you are doing (see the book reccomendation above)
- Act with enthusiasm! WOW! THIS IS GREAT! I THOUGHT THIS WAS GOING TO TAKE MUCH LONGER
As a CEO once told me "Always take the credit because you WILL take the blame!"
Dramatize your solutions, and TALK TO PEOPLE.
Everything is sales, my friend, everything.
33
Geordi La Forge: "Yeah, well, I told the Captain I’d have this analysis done in an hour." Scotty: "How long will it really take?" - The Montgomery Scott Guide To Project Management Skills
– Mazura
Oct 3 at 1:59
9
Always take the credit because you WILL take the blame!
that has put my whole morning into perspective
– PeterH
Oct 3 at 7:25
11
If you can fix something in 20 minutes, I think it's bad to make it several hours instead. Don't waste time. If anything, use a little time logging the fix to make your work visible, but don't waste the time just to make a quick fix seem like a complicated problem. It could reflect poorly on your if people find out later.
– Gertsen
Oct 3 at 7:52
7
(3) might fly in the US, but certainly won't in all cultures. In germany, if you act that way, you'd be seen as unprofessional and weird. OP specified brazil, so I'm not sure if this would be a good idea. managing expectations is good, fake enthusiasm might not be.
– Polygnome
Oct 3 at 8:47
5
"Everything is sales, my friend, everything" and this is one of the reasons our current society is so f**d up. It is not relevant what you do, but how you sell it!
– Thomas
Oct 3 at 10:24
|
show 14 more comments
I have a similar problem.
Word for word from my boss "He can do things in 15 minutes that would take someone else a week to do"
There is a phrase out there that I hate to use but here goes...
You need to learn to "manage expectations"
People often mistake the fact that since something is easy FOR YOU it must be easy to do.
I know people, myself included, who were doing their jobs, and THOUGHT they were appreciated, move on (either voluntarily or otherwise) and then the company realizes what they did, and need to be replaced by three people.
FULL DISCLOSURE:
I have used the following book personally, and do not get any compensation from any author or retailer.
The book "Brag, the art of tooting your own horn without blowing it" Has been a god-send to me.
Like you I used to assume that my work would just speak for itself, it doesn't, get the book.
Now, the rest of your problem takes a bit of finesse because it's a perception problem.
If the standard turnaround is 2 days, and you do it in twenty minutes, the ASSUMPTION is going to be that you took shortcuts or something. Remember, you are being managed by people who don't understand how you do what you do.
- SLOW YOUR ROLL: Seriously, sit on projects a bit. Instead of turning things around in 20 minutes, make it a few hours before you implement them.
- Let everyone know just how much you are doing (see the book reccomendation above)
- Act with enthusiasm! WOW! THIS IS GREAT! I THOUGHT THIS WAS GOING TO TAKE MUCH LONGER
As a CEO once told me "Always take the credit because you WILL take the blame!"
Dramatize your solutions, and TALK TO PEOPLE.
Everything is sales, my friend, everything.
I have a similar problem.
Word for word from my boss "He can do things in 15 minutes that would take someone else a week to do"
There is a phrase out there that I hate to use but here goes...
You need to learn to "manage expectations"
People often mistake the fact that since something is easy FOR YOU it must be easy to do.
I know people, myself included, who were doing their jobs, and THOUGHT they were appreciated, move on (either voluntarily or otherwise) and then the company realizes what they did, and need to be replaced by three people.
FULL DISCLOSURE:
I have used the following book personally, and do not get any compensation from any author or retailer.
The book "Brag, the art of tooting your own horn without blowing it" Has been a god-send to me.
Like you I used to assume that my work would just speak for itself, it doesn't, get the book.
Now, the rest of your problem takes a bit of finesse because it's a perception problem.
If the standard turnaround is 2 days, and you do it in twenty minutes, the ASSUMPTION is going to be that you took shortcuts or something. Remember, you are being managed by people who don't understand how you do what you do.
- SLOW YOUR ROLL: Seriously, sit on projects a bit. Instead of turning things around in 20 minutes, make it a few hours before you implement them.
- Let everyone know just how much you are doing (see the book reccomendation above)
- Act with enthusiasm! WOW! THIS IS GREAT! I THOUGHT THIS WAS GOING TO TAKE MUCH LONGER
As a CEO once told me "Always take the credit because you WILL take the blame!"
Dramatize your solutions, and TALK TO PEOPLE.
Everything is sales, my friend, everything.
answered Oct 2 at 18:03
Richard Says Reinstate MonicaRichard Says Reinstate Monica
115k83 gold badges318 silver badges445 bronze badges
115k83 gold badges318 silver badges445 bronze badges
33
Geordi La Forge: "Yeah, well, I told the Captain I’d have this analysis done in an hour." Scotty: "How long will it really take?" - The Montgomery Scott Guide To Project Management Skills
– Mazura
Oct 3 at 1:59
9
Always take the credit because you WILL take the blame!
that has put my whole morning into perspective
– PeterH
Oct 3 at 7:25
11
If you can fix something in 20 minutes, I think it's bad to make it several hours instead. Don't waste time. If anything, use a little time logging the fix to make your work visible, but don't waste the time just to make a quick fix seem like a complicated problem. It could reflect poorly on your if people find out later.
– Gertsen
Oct 3 at 7:52
7
(3) might fly in the US, but certainly won't in all cultures. In germany, if you act that way, you'd be seen as unprofessional and weird. OP specified brazil, so I'm not sure if this would be a good idea. managing expectations is good, fake enthusiasm might not be.
– Polygnome
Oct 3 at 8:47
5
"Everything is sales, my friend, everything" and this is one of the reasons our current society is so f**d up. It is not relevant what you do, but how you sell it!
– Thomas
Oct 3 at 10:24
|
show 14 more comments
33
Geordi La Forge: "Yeah, well, I told the Captain I’d have this analysis done in an hour." Scotty: "How long will it really take?" - The Montgomery Scott Guide To Project Management Skills
– Mazura
Oct 3 at 1:59
9
Always take the credit because you WILL take the blame!
that has put my whole morning into perspective
– PeterH
Oct 3 at 7:25
11
If you can fix something in 20 minutes, I think it's bad to make it several hours instead. Don't waste time. If anything, use a little time logging the fix to make your work visible, but don't waste the time just to make a quick fix seem like a complicated problem. It could reflect poorly on your if people find out later.
– Gertsen
Oct 3 at 7:52
7
(3) might fly in the US, but certainly won't in all cultures. In germany, if you act that way, you'd be seen as unprofessional and weird. OP specified brazil, so I'm not sure if this would be a good idea. managing expectations is good, fake enthusiasm might not be.
– Polygnome
Oct 3 at 8:47
5
"Everything is sales, my friend, everything" and this is one of the reasons our current society is so f**d up. It is not relevant what you do, but how you sell it!
– Thomas
Oct 3 at 10:24
33
33
Geordi La Forge: "Yeah, well, I told the Captain I’d have this analysis done in an hour." Scotty: "How long will it really take?" - The Montgomery Scott Guide To Project Management Skills
– Mazura
Oct 3 at 1:59
Geordi La Forge: "Yeah, well, I told the Captain I’d have this analysis done in an hour." Scotty: "How long will it really take?" - The Montgomery Scott Guide To Project Management Skills
– Mazura
Oct 3 at 1:59
9
9
Always take the credit because you WILL take the blame!
that has put my whole morning into perspective– PeterH
Oct 3 at 7:25
Always take the credit because you WILL take the blame!
that has put my whole morning into perspective– PeterH
Oct 3 at 7:25
11
11
If you can fix something in 20 minutes, I think it's bad to make it several hours instead. Don't waste time. If anything, use a little time logging the fix to make your work visible, but don't waste the time just to make a quick fix seem like a complicated problem. It could reflect poorly on your if people find out later.
– Gertsen
Oct 3 at 7:52
If you can fix something in 20 minutes, I think it's bad to make it several hours instead. Don't waste time. If anything, use a little time logging the fix to make your work visible, but don't waste the time just to make a quick fix seem like a complicated problem. It could reflect poorly on your if people find out later.
– Gertsen
Oct 3 at 7:52
7
7
(3) might fly in the US, but certainly won't in all cultures. In germany, if you act that way, you'd be seen as unprofessional and weird. OP specified brazil, so I'm not sure if this would be a good idea. managing expectations is good, fake enthusiasm might not be.
– Polygnome
Oct 3 at 8:47
(3) might fly in the US, but certainly won't in all cultures. In germany, if you act that way, you'd be seen as unprofessional and weird. OP specified brazil, so I'm not sure if this would be a good idea. managing expectations is good, fake enthusiasm might not be.
– Polygnome
Oct 3 at 8:47
5
5
"Everything is sales, my friend, everything" and this is one of the reasons our current society is so f**d up. It is not relevant what you do, but how you sell it!
– Thomas
Oct 3 at 10:24
"Everything is sales, my friend, everything" and this is one of the reasons our current society is so f**d up. It is not relevant what you do, but how you sell it!
– Thomas
Oct 3 at 10:24
|
show 14 more comments
Teach
If the problem is that your coworker is slow, your whole team will do better if you help them get faster. Of course, they need to want assistance, so the way you offer it makes all the difference in the world. Next time they are working on a bug, just casually ask if you can help them look at anything. If they accept the help, give gentle advice and pointers on how to speed up the investigation.
Lead
If your coworker realizes that you are really helpful, then soon they will start coming to you for assistance. That's great, because eventually people will see them at your desk getting consultation and helping them work through problems. If several coworkers are seen coming your desk regularly for help, then others will eventually realize that you are a thought leader and problem solver, and your coworkers will eventually start saying things like: "Well, this would go a lot faster if we had Green Baloon here. Ted, can you go see if he's at his desk?"
The goal is not for your boss to see that you work 5x faster than the rest of your team. The goal is for your boss to say: "Huh...it used to take 3-4 days for you guys to turn around these bugs, but now you're destroying them in a few hours. What's the difference?" At this point, the responses will depend very much on how your coworkers view you. If they think you are arrogant or will try to steal all the credit, they will just take credit themselves and say that they've been leveling up their skills, while you appear to be sitting still. If, on the other hand, they see you as someone who is generous with his time and willing to do what it takes to move the whole team forward, then they will be happy to give you credit for helping them out. They might do it indirectly, like: "Well, Green Baloon shared some scripts with the team that have really helped us power through some issues", but if you have done a very good job of being a team player, they should feel comfortable saying something like: "Green Baloon is the go-to guy when we get stuck, truth be told."
Judgment Call
You have to use your own personal judgment to decide what kind of coworkers you have, and what kind of responses they are likely to give in the scenario above when you decide to invest in them as team members. If they are a bit selfish, then you should probably do the minimum to keep the team unblocked and working on the good stuff. If they are fair-minded, then investing extra time in skilling them up will eventually turn into positive press for you one way or another. The key is to make it clear that you are trying to help them and help the team, and not just taking credit for fixing stuff.
Document
When it comes time for reviews, you want to have a history of good work that you've done. So when you contribute tools to the team, write it down in your personal journal. When you help other people, write it down. When your boss asks why you think you deserve a raise/promotion, bring out your journal. Don't focus on who you have helped, but rather, how you have become a force multiplier that makes the whole team faster and more efficient, which also helps your boss look better. It's not about: "I'm 5x faster than Ted." It's about: "Well, you may have noticed that the team is getting stuff done faster. Let me show you some of the reasons why."
Once your boss figures out that you are improving the whole team, if they have two brain cells to rub together, they will realize that you are their meal ticket to advancement. If they are a bit slow on the uptake, spell out this obvious fact for them, as diplomatically as possible: "So, what do the other directors say about our department? How have you been selling our work? Did your boss notice our throughput has gone up? Surely that's been good for you, hasn't it?" Make it clear that your boss gets to take credit for your whole team improving. They will figure out that it didn't happen magically, and if they want more improvement, they have to reward the person who is actually driving the changes.
If your team and/or boss don't respond positively to your best efforts, then it's time to switch teams/company.
Good answer there +
– QHarr
Oct 5 at 19:18
add a comment
|
Teach
If the problem is that your coworker is slow, your whole team will do better if you help them get faster. Of course, they need to want assistance, so the way you offer it makes all the difference in the world. Next time they are working on a bug, just casually ask if you can help them look at anything. If they accept the help, give gentle advice and pointers on how to speed up the investigation.
Lead
If your coworker realizes that you are really helpful, then soon they will start coming to you for assistance. That's great, because eventually people will see them at your desk getting consultation and helping them work through problems. If several coworkers are seen coming your desk regularly for help, then others will eventually realize that you are a thought leader and problem solver, and your coworkers will eventually start saying things like: "Well, this would go a lot faster if we had Green Baloon here. Ted, can you go see if he's at his desk?"
The goal is not for your boss to see that you work 5x faster than the rest of your team. The goal is for your boss to say: "Huh...it used to take 3-4 days for you guys to turn around these bugs, but now you're destroying them in a few hours. What's the difference?" At this point, the responses will depend very much on how your coworkers view you. If they think you are arrogant or will try to steal all the credit, they will just take credit themselves and say that they've been leveling up their skills, while you appear to be sitting still. If, on the other hand, they see you as someone who is generous with his time and willing to do what it takes to move the whole team forward, then they will be happy to give you credit for helping them out. They might do it indirectly, like: "Well, Green Baloon shared some scripts with the team that have really helped us power through some issues", but if you have done a very good job of being a team player, they should feel comfortable saying something like: "Green Baloon is the go-to guy when we get stuck, truth be told."
Judgment Call
You have to use your own personal judgment to decide what kind of coworkers you have, and what kind of responses they are likely to give in the scenario above when you decide to invest in them as team members. If they are a bit selfish, then you should probably do the minimum to keep the team unblocked and working on the good stuff. If they are fair-minded, then investing extra time in skilling them up will eventually turn into positive press for you one way or another. The key is to make it clear that you are trying to help them and help the team, and not just taking credit for fixing stuff.
Document
When it comes time for reviews, you want to have a history of good work that you've done. So when you contribute tools to the team, write it down in your personal journal. When you help other people, write it down. When your boss asks why you think you deserve a raise/promotion, bring out your journal. Don't focus on who you have helped, but rather, how you have become a force multiplier that makes the whole team faster and more efficient, which also helps your boss look better. It's not about: "I'm 5x faster than Ted." It's about: "Well, you may have noticed that the team is getting stuff done faster. Let me show you some of the reasons why."
Once your boss figures out that you are improving the whole team, if they have two brain cells to rub together, they will realize that you are their meal ticket to advancement. If they are a bit slow on the uptake, spell out this obvious fact for them, as diplomatically as possible: "So, what do the other directors say about our department? How have you been selling our work? Did your boss notice our throughput has gone up? Surely that's been good for you, hasn't it?" Make it clear that your boss gets to take credit for your whole team improving. They will figure out that it didn't happen magically, and if they want more improvement, they have to reward the person who is actually driving the changes.
If your team and/or boss don't respond positively to your best efforts, then it's time to switch teams/company.
Good answer there +
– QHarr
Oct 5 at 19:18
add a comment
|
Teach
If the problem is that your coworker is slow, your whole team will do better if you help them get faster. Of course, they need to want assistance, so the way you offer it makes all the difference in the world. Next time they are working on a bug, just casually ask if you can help them look at anything. If they accept the help, give gentle advice and pointers on how to speed up the investigation.
Lead
If your coworker realizes that you are really helpful, then soon they will start coming to you for assistance. That's great, because eventually people will see them at your desk getting consultation and helping them work through problems. If several coworkers are seen coming your desk regularly for help, then others will eventually realize that you are a thought leader and problem solver, and your coworkers will eventually start saying things like: "Well, this would go a lot faster if we had Green Baloon here. Ted, can you go see if he's at his desk?"
The goal is not for your boss to see that you work 5x faster than the rest of your team. The goal is for your boss to say: "Huh...it used to take 3-4 days for you guys to turn around these bugs, but now you're destroying them in a few hours. What's the difference?" At this point, the responses will depend very much on how your coworkers view you. If they think you are arrogant or will try to steal all the credit, they will just take credit themselves and say that they've been leveling up their skills, while you appear to be sitting still. If, on the other hand, they see you as someone who is generous with his time and willing to do what it takes to move the whole team forward, then they will be happy to give you credit for helping them out. They might do it indirectly, like: "Well, Green Baloon shared some scripts with the team that have really helped us power through some issues", but if you have done a very good job of being a team player, they should feel comfortable saying something like: "Green Baloon is the go-to guy when we get stuck, truth be told."
Judgment Call
You have to use your own personal judgment to decide what kind of coworkers you have, and what kind of responses they are likely to give in the scenario above when you decide to invest in them as team members. If they are a bit selfish, then you should probably do the minimum to keep the team unblocked and working on the good stuff. If they are fair-minded, then investing extra time in skilling them up will eventually turn into positive press for you one way or another. The key is to make it clear that you are trying to help them and help the team, and not just taking credit for fixing stuff.
Document
When it comes time for reviews, you want to have a history of good work that you've done. So when you contribute tools to the team, write it down in your personal journal. When you help other people, write it down. When your boss asks why you think you deserve a raise/promotion, bring out your journal. Don't focus on who you have helped, but rather, how you have become a force multiplier that makes the whole team faster and more efficient, which also helps your boss look better. It's not about: "I'm 5x faster than Ted." It's about: "Well, you may have noticed that the team is getting stuff done faster. Let me show you some of the reasons why."
Once your boss figures out that you are improving the whole team, if they have two brain cells to rub together, they will realize that you are their meal ticket to advancement. If they are a bit slow on the uptake, spell out this obvious fact for them, as diplomatically as possible: "So, what do the other directors say about our department? How have you been selling our work? Did your boss notice our throughput has gone up? Surely that's been good for you, hasn't it?" Make it clear that your boss gets to take credit for your whole team improving. They will figure out that it didn't happen magically, and if they want more improvement, they have to reward the person who is actually driving the changes.
If your team and/or boss don't respond positively to your best efforts, then it's time to switch teams/company.
Teach
If the problem is that your coworker is slow, your whole team will do better if you help them get faster. Of course, they need to want assistance, so the way you offer it makes all the difference in the world. Next time they are working on a bug, just casually ask if you can help them look at anything. If they accept the help, give gentle advice and pointers on how to speed up the investigation.
Lead
If your coworker realizes that you are really helpful, then soon they will start coming to you for assistance. That's great, because eventually people will see them at your desk getting consultation and helping them work through problems. If several coworkers are seen coming your desk regularly for help, then others will eventually realize that you are a thought leader and problem solver, and your coworkers will eventually start saying things like: "Well, this would go a lot faster if we had Green Baloon here. Ted, can you go see if he's at his desk?"
The goal is not for your boss to see that you work 5x faster than the rest of your team. The goal is for your boss to say: "Huh...it used to take 3-4 days for you guys to turn around these bugs, but now you're destroying them in a few hours. What's the difference?" At this point, the responses will depend very much on how your coworkers view you. If they think you are arrogant or will try to steal all the credit, they will just take credit themselves and say that they've been leveling up their skills, while you appear to be sitting still. If, on the other hand, they see you as someone who is generous with his time and willing to do what it takes to move the whole team forward, then they will be happy to give you credit for helping them out. They might do it indirectly, like: "Well, Green Baloon shared some scripts with the team that have really helped us power through some issues", but if you have done a very good job of being a team player, they should feel comfortable saying something like: "Green Baloon is the go-to guy when we get stuck, truth be told."
Judgment Call
You have to use your own personal judgment to decide what kind of coworkers you have, and what kind of responses they are likely to give in the scenario above when you decide to invest in them as team members. If they are a bit selfish, then you should probably do the minimum to keep the team unblocked and working on the good stuff. If they are fair-minded, then investing extra time in skilling them up will eventually turn into positive press for you one way or another. The key is to make it clear that you are trying to help them and help the team, and not just taking credit for fixing stuff.
Document
When it comes time for reviews, you want to have a history of good work that you've done. So when you contribute tools to the team, write it down in your personal journal. When you help other people, write it down. When your boss asks why you think you deserve a raise/promotion, bring out your journal. Don't focus on who you have helped, but rather, how you have become a force multiplier that makes the whole team faster and more efficient, which also helps your boss look better. It's not about: "I'm 5x faster than Ted." It's about: "Well, you may have noticed that the team is getting stuff done faster. Let me show you some of the reasons why."
Once your boss figures out that you are improving the whole team, if they have two brain cells to rub together, they will realize that you are their meal ticket to advancement. If they are a bit slow on the uptake, spell out this obvious fact for them, as diplomatically as possible: "So, what do the other directors say about our department? How have you been selling our work? Did your boss notice our throughput has gone up? Surely that's been good for you, hasn't it?" Make it clear that your boss gets to take credit for your whole team improving. They will figure out that it didn't happen magically, and if they want more improvement, they have to reward the person who is actually driving the changes.
If your team and/or boss don't respond positively to your best efforts, then it's time to switch teams/company.
answered Oct 3 at 1:36
Lawnmower ManLawnmower Man
1,3121 silver badge10 bronze badges
1,3121 silver badge10 bronze badges
Good answer there +
– QHarr
Oct 5 at 19:18
add a comment
|
Good answer there +
– QHarr
Oct 5 at 19:18
Good answer there +
– QHarr
Oct 5 at 19:18
Good answer there +
– QHarr
Oct 5 at 19:18
add a comment
|
What you need to achieve that every problem gets recorded, assigned to someone to fix, and then it needs to be recorded who fixed it. Then it should be a simple count, how many problems you fixed and how many someone else fixed.
If you are still told that you only solve easy problems then you need to demonstrate that you are solving hard problems by taking two days for a problem like your colleague. (Assume that this is sarcastic).
If you are really annoyed, and you are sure that your colleague takes two days for five minute problems then you can start systematically providing solutions for his problems after a day.
PS. Estimating every task works wonders as well.
1
That's what happened today. There was a problem and I knew they would take a lot of time to solve and I just say loudly " try this this this, I got a script that does that, and then you can x". I must say it worked.
– Green Baloon
Oct 2 at 17:24
1
Task tracking needs to include the expected effort to fix the problem in order for it to be effective at review time. Agile is a great way to formally handle this. The numbers put on each task include time as well as other factors to add up to a better qualifier. Ex: Jimmy solved 500 tasks in a year and each was only an effort of 1; Susan solved 250 tasks with efforts from 2 - 8 and the average was 3; Susan's effort was greater than Jimmy's, even though Jimmy did more tasks. This shows Susan did more work in the same time in a better way than simple quantity of tasks.
– computercarguy
Oct 3 at 23:01
2
@computercarguy That is an excellent way to note contributor value. I once worked at a call center where the first employee to reach "500" calls completed was openly celebrated. I couldn't help but notice that 80% of their calls were password resets that only took 10 minutes. Other people were solving far more difficult issues that sometimes took multiple calls over multiple days that I know that "Agent 500" would never have been able to solve at all. This isn't to say that those calls weren't important, but the contributions of other agents were probably more valuable in the long term.
– Booga Roo
Oct 4 at 19:59
@BoogaRoo, I know, right? I worked at call centers before and saw similar things. Agents with average call times way below the required max and a high callback rate. I've also seen "senior" devs that do "quick fixes" on tasks that end up recurring dozens of times because they keep recurring. That's somewhat to be expected of juniors, but not seniors. Yeah, expected effort and recurrence need tracked, too.
– computercarguy
Oct 4 at 21:01
@GreenBaloon - "That's what happened today. There was a problem and I knew they would take a lot of time to solve and I just say loudly " try this this this, I got a script that does that, and then you can x". I must say it worked." My advice: don't give it away. Track the work, make sure to show the data on how much you've done. Wait until you boss asks you to teach the others.
– Diagon
Oct 5 at 1:16
|
show 1 more comment
What you need to achieve that every problem gets recorded, assigned to someone to fix, and then it needs to be recorded who fixed it. Then it should be a simple count, how many problems you fixed and how many someone else fixed.
If you are still told that you only solve easy problems then you need to demonstrate that you are solving hard problems by taking two days for a problem like your colleague. (Assume that this is sarcastic).
If you are really annoyed, and you are sure that your colleague takes two days for five minute problems then you can start systematically providing solutions for his problems after a day.
PS. Estimating every task works wonders as well.
1
That's what happened today. There was a problem and I knew they would take a lot of time to solve and I just say loudly " try this this this, I got a script that does that, and then you can x". I must say it worked.
– Green Baloon
Oct 2 at 17:24
1
Task tracking needs to include the expected effort to fix the problem in order for it to be effective at review time. Agile is a great way to formally handle this. The numbers put on each task include time as well as other factors to add up to a better qualifier. Ex: Jimmy solved 500 tasks in a year and each was only an effort of 1; Susan solved 250 tasks with efforts from 2 - 8 and the average was 3; Susan's effort was greater than Jimmy's, even though Jimmy did more tasks. This shows Susan did more work in the same time in a better way than simple quantity of tasks.
– computercarguy
Oct 3 at 23:01
2
@computercarguy That is an excellent way to note contributor value. I once worked at a call center where the first employee to reach "500" calls completed was openly celebrated. I couldn't help but notice that 80% of their calls were password resets that only took 10 minutes. Other people were solving far more difficult issues that sometimes took multiple calls over multiple days that I know that "Agent 500" would never have been able to solve at all. This isn't to say that those calls weren't important, but the contributions of other agents were probably more valuable in the long term.
– Booga Roo
Oct 4 at 19:59
@BoogaRoo, I know, right? I worked at call centers before and saw similar things. Agents with average call times way below the required max and a high callback rate. I've also seen "senior" devs that do "quick fixes" on tasks that end up recurring dozens of times because they keep recurring. That's somewhat to be expected of juniors, but not seniors. Yeah, expected effort and recurrence need tracked, too.
– computercarguy
Oct 4 at 21:01
@GreenBaloon - "That's what happened today. There was a problem and I knew they would take a lot of time to solve and I just say loudly " try this this this, I got a script that does that, and then you can x". I must say it worked." My advice: don't give it away. Track the work, make sure to show the data on how much you've done. Wait until you boss asks you to teach the others.
– Diagon
Oct 5 at 1:16
|
show 1 more comment
What you need to achieve that every problem gets recorded, assigned to someone to fix, and then it needs to be recorded who fixed it. Then it should be a simple count, how many problems you fixed and how many someone else fixed.
If you are still told that you only solve easy problems then you need to demonstrate that you are solving hard problems by taking two days for a problem like your colleague. (Assume that this is sarcastic).
If you are really annoyed, and you are sure that your colleague takes two days for five minute problems then you can start systematically providing solutions for his problems after a day.
PS. Estimating every task works wonders as well.
What you need to achieve that every problem gets recorded, assigned to someone to fix, and then it needs to be recorded who fixed it. Then it should be a simple count, how many problems you fixed and how many someone else fixed.
If you are still told that you only solve easy problems then you need to demonstrate that you are solving hard problems by taking two days for a problem like your colleague. (Assume that this is sarcastic).
If you are really annoyed, and you are sure that your colleague takes two days for five minute problems then you can start systematically providing solutions for his problems after a day.
PS. Estimating every task works wonders as well.
edited Oct 2 at 21:11
answered Oct 2 at 16:33
gnasher729gnasher729
111k54 gold badges202 silver badges355 bronze badges
111k54 gold badges202 silver badges355 bronze badges
1
That's what happened today. There was a problem and I knew they would take a lot of time to solve and I just say loudly " try this this this, I got a script that does that, and then you can x". I must say it worked.
– Green Baloon
Oct 2 at 17:24
1
Task tracking needs to include the expected effort to fix the problem in order for it to be effective at review time. Agile is a great way to formally handle this. The numbers put on each task include time as well as other factors to add up to a better qualifier. Ex: Jimmy solved 500 tasks in a year and each was only an effort of 1; Susan solved 250 tasks with efforts from 2 - 8 and the average was 3; Susan's effort was greater than Jimmy's, even though Jimmy did more tasks. This shows Susan did more work in the same time in a better way than simple quantity of tasks.
– computercarguy
Oct 3 at 23:01
2
@computercarguy That is an excellent way to note contributor value. I once worked at a call center where the first employee to reach "500" calls completed was openly celebrated. I couldn't help but notice that 80% of their calls were password resets that only took 10 minutes. Other people were solving far more difficult issues that sometimes took multiple calls over multiple days that I know that "Agent 500" would never have been able to solve at all. This isn't to say that those calls weren't important, but the contributions of other agents were probably more valuable in the long term.
– Booga Roo
Oct 4 at 19:59
@BoogaRoo, I know, right? I worked at call centers before and saw similar things. Agents with average call times way below the required max and a high callback rate. I've also seen "senior" devs that do "quick fixes" on tasks that end up recurring dozens of times because they keep recurring. That's somewhat to be expected of juniors, but not seniors. Yeah, expected effort and recurrence need tracked, too.
– computercarguy
Oct 4 at 21:01
@GreenBaloon - "That's what happened today. There was a problem and I knew they would take a lot of time to solve and I just say loudly " try this this this, I got a script that does that, and then you can x". I must say it worked." My advice: don't give it away. Track the work, make sure to show the data on how much you've done. Wait until you boss asks you to teach the others.
– Diagon
Oct 5 at 1:16
|
show 1 more comment
1
That's what happened today. There was a problem and I knew they would take a lot of time to solve and I just say loudly " try this this this, I got a script that does that, and then you can x". I must say it worked.
– Green Baloon
Oct 2 at 17:24
1
Task tracking needs to include the expected effort to fix the problem in order for it to be effective at review time. Agile is a great way to formally handle this. The numbers put on each task include time as well as other factors to add up to a better qualifier. Ex: Jimmy solved 500 tasks in a year and each was only an effort of 1; Susan solved 250 tasks with efforts from 2 - 8 and the average was 3; Susan's effort was greater than Jimmy's, even though Jimmy did more tasks. This shows Susan did more work in the same time in a better way than simple quantity of tasks.
– computercarguy
Oct 3 at 23:01
2
@computercarguy That is an excellent way to note contributor value. I once worked at a call center where the first employee to reach "500" calls completed was openly celebrated. I couldn't help but notice that 80% of their calls were password resets that only took 10 minutes. Other people were solving far more difficult issues that sometimes took multiple calls over multiple days that I know that "Agent 500" would never have been able to solve at all. This isn't to say that those calls weren't important, but the contributions of other agents were probably more valuable in the long term.
– Booga Roo
Oct 4 at 19:59
@BoogaRoo, I know, right? I worked at call centers before and saw similar things. Agents with average call times way below the required max and a high callback rate. I've also seen "senior" devs that do "quick fixes" on tasks that end up recurring dozens of times because they keep recurring. That's somewhat to be expected of juniors, but not seniors. Yeah, expected effort and recurrence need tracked, too.
– computercarguy
Oct 4 at 21:01
@GreenBaloon - "That's what happened today. There was a problem and I knew they would take a lot of time to solve and I just say loudly " try this this this, I got a script that does that, and then you can x". I must say it worked." My advice: don't give it away. Track the work, make sure to show the data on how much you've done. Wait until you boss asks you to teach the others.
– Diagon
Oct 5 at 1:16
1
1
That's what happened today. There was a problem and I knew they would take a lot of time to solve and I just say loudly " try this this this, I got a script that does that, and then you can x". I must say it worked.
– Green Baloon
Oct 2 at 17:24
That's what happened today. There was a problem and I knew they would take a lot of time to solve and I just say loudly " try this this this, I got a script that does that, and then you can x". I must say it worked.
– Green Baloon
Oct 2 at 17:24
1
1
Task tracking needs to include the expected effort to fix the problem in order for it to be effective at review time. Agile is a great way to formally handle this. The numbers put on each task include time as well as other factors to add up to a better qualifier. Ex: Jimmy solved 500 tasks in a year and each was only an effort of 1; Susan solved 250 tasks with efforts from 2 - 8 and the average was 3; Susan's effort was greater than Jimmy's, even though Jimmy did more tasks. This shows Susan did more work in the same time in a better way than simple quantity of tasks.
– computercarguy
Oct 3 at 23:01
Task tracking needs to include the expected effort to fix the problem in order for it to be effective at review time. Agile is a great way to formally handle this. The numbers put on each task include time as well as other factors to add up to a better qualifier. Ex: Jimmy solved 500 tasks in a year and each was only an effort of 1; Susan solved 250 tasks with efforts from 2 - 8 and the average was 3; Susan's effort was greater than Jimmy's, even though Jimmy did more tasks. This shows Susan did more work in the same time in a better way than simple quantity of tasks.
– computercarguy
Oct 3 at 23:01
2
2
@computercarguy That is an excellent way to note contributor value. I once worked at a call center where the first employee to reach "500" calls completed was openly celebrated. I couldn't help but notice that 80% of their calls were password resets that only took 10 minutes. Other people were solving far more difficult issues that sometimes took multiple calls over multiple days that I know that "Agent 500" would never have been able to solve at all. This isn't to say that those calls weren't important, but the contributions of other agents were probably more valuable in the long term.
– Booga Roo
Oct 4 at 19:59
@computercarguy That is an excellent way to note contributor value. I once worked at a call center where the first employee to reach "500" calls completed was openly celebrated. I couldn't help but notice that 80% of their calls were password resets that only took 10 minutes. Other people were solving far more difficult issues that sometimes took multiple calls over multiple days that I know that "Agent 500" would never have been able to solve at all. This isn't to say that those calls weren't important, but the contributions of other agents were probably more valuable in the long term.
– Booga Roo
Oct 4 at 19:59
@BoogaRoo, I know, right? I worked at call centers before and saw similar things. Agents with average call times way below the required max and a high callback rate. I've also seen "senior" devs that do "quick fixes" on tasks that end up recurring dozens of times because they keep recurring. That's somewhat to be expected of juniors, but not seniors. Yeah, expected effort and recurrence need tracked, too.
– computercarguy
Oct 4 at 21:01
@BoogaRoo, I know, right? I worked at call centers before and saw similar things. Agents with average call times way below the required max and a high callback rate. I've also seen "senior" devs that do "quick fixes" on tasks that end up recurring dozens of times because they keep recurring. That's somewhat to be expected of juniors, but not seniors. Yeah, expected effort and recurrence need tracked, too.
– computercarguy
Oct 4 at 21:01
@GreenBaloon - "That's what happened today. There was a problem and I knew they would take a lot of time to solve and I just say loudly " try this this this, I got a script that does that, and then you can x". I must say it worked." My advice: don't give it away. Track the work, make sure to show the data on how much you've done. Wait until you boss asks you to teach the others.
– Diagon
Oct 5 at 1:16
@GreenBaloon - "That's what happened today. There was a problem and I knew they would take a lot of time to solve and I just say loudly " try this this this, I got a script that does that, and then you can x". I must say it worked." My advice: don't give it away. Track the work, make sure to show the data on how much you've done. Wait until you boss asks you to teach the others.
– Diagon
Oct 5 at 1:16
|
show 1 more comment
Enumerate the problems with some kind of tracking system.
A tracking system would be a good thing to have anyway because it would help prevent duplicated work, highlight recurring problems, and allow you to build a clearer picture of how the team functions. Amongst other things your boss could use the stats to demonstrate how good his department is (we solved 90% of problems within 2 days).
The secret objective here is that once you track the problems your boss will realise how much work you do. Especially if they use the stats to demonstrate departmental performance.
Using Agile is one method I've used to track tasks. It allows for tracking effort as well and that is voted on by several devs. If a task is "changing the IP", it'll be low and expect to take next to no time. If a task is developing a new form with a new DB table and server code to handle it, it'll be high. So if a low value effort takes more time than necessary or a high value takes less time, it's much more obvious, along with repeats of the same task(s). You can also track dev to see why the tasks didn't stay fixed, if that's what's actually happening, too.
– computercarguy
Oct 3 at 23:06
This is an ideal way to go. You should have an issue management system anyway. It is very useful tool for making productivity visible, with many other benefits.
– Keith
Oct 5 at 4:51
add a comment
|
Enumerate the problems with some kind of tracking system.
A tracking system would be a good thing to have anyway because it would help prevent duplicated work, highlight recurring problems, and allow you to build a clearer picture of how the team functions. Amongst other things your boss could use the stats to demonstrate how good his department is (we solved 90% of problems within 2 days).
The secret objective here is that once you track the problems your boss will realise how much work you do. Especially if they use the stats to demonstrate departmental performance.
Using Agile is one method I've used to track tasks. It allows for tracking effort as well and that is voted on by several devs. If a task is "changing the IP", it'll be low and expect to take next to no time. If a task is developing a new form with a new DB table and server code to handle it, it'll be high. So if a low value effort takes more time than necessary or a high value takes less time, it's much more obvious, along with repeats of the same task(s). You can also track dev to see why the tasks didn't stay fixed, if that's what's actually happening, too.
– computercarguy
Oct 3 at 23:06
This is an ideal way to go. You should have an issue management system anyway. It is very useful tool for making productivity visible, with many other benefits.
– Keith
Oct 5 at 4:51
add a comment
|
Enumerate the problems with some kind of tracking system.
A tracking system would be a good thing to have anyway because it would help prevent duplicated work, highlight recurring problems, and allow you to build a clearer picture of how the team functions. Amongst other things your boss could use the stats to demonstrate how good his department is (we solved 90% of problems within 2 days).
The secret objective here is that once you track the problems your boss will realise how much work you do. Especially if they use the stats to demonstrate departmental performance.
Enumerate the problems with some kind of tracking system.
A tracking system would be a good thing to have anyway because it would help prevent duplicated work, highlight recurring problems, and allow you to build a clearer picture of how the team functions. Amongst other things your boss could use the stats to demonstrate how good his department is (we solved 90% of problems within 2 days).
The secret objective here is that once you track the problems your boss will realise how much work you do. Especially if they use the stats to demonstrate departmental performance.
answered Oct 2 at 23:06
P. HopkinsonP. Hopkinson
4,7731 gold badge10 silver badges23 bronze badges
4,7731 gold badge10 silver badges23 bronze badges
Using Agile is one method I've used to track tasks. It allows for tracking effort as well and that is voted on by several devs. If a task is "changing the IP", it'll be low and expect to take next to no time. If a task is developing a new form with a new DB table and server code to handle it, it'll be high. So if a low value effort takes more time than necessary or a high value takes less time, it's much more obvious, along with repeats of the same task(s). You can also track dev to see why the tasks didn't stay fixed, if that's what's actually happening, too.
– computercarguy
Oct 3 at 23:06
This is an ideal way to go. You should have an issue management system anyway. It is very useful tool for making productivity visible, with many other benefits.
– Keith
Oct 5 at 4:51
add a comment
|
Using Agile is one method I've used to track tasks. It allows for tracking effort as well and that is voted on by several devs. If a task is "changing the IP", it'll be low and expect to take next to no time. If a task is developing a new form with a new DB table and server code to handle it, it'll be high. So if a low value effort takes more time than necessary or a high value takes less time, it's much more obvious, along with repeats of the same task(s). You can also track dev to see why the tasks didn't stay fixed, if that's what's actually happening, too.
– computercarguy
Oct 3 at 23:06
This is an ideal way to go. You should have an issue management system anyway. It is very useful tool for making productivity visible, with many other benefits.
– Keith
Oct 5 at 4:51
Using Agile is one method I've used to track tasks. It allows for tracking effort as well and that is voted on by several devs. If a task is "changing the IP", it'll be low and expect to take next to no time. If a task is developing a new form with a new DB table and server code to handle it, it'll be high. So if a low value effort takes more time than necessary or a high value takes less time, it's much more obvious, along with repeats of the same task(s). You can also track dev to see why the tasks didn't stay fixed, if that's what's actually happening, too.
– computercarguy
Oct 3 at 23:06
Using Agile is one method I've used to track tasks. It allows for tracking effort as well and that is voted on by several devs. If a task is "changing the IP", it'll be low and expect to take next to no time. If a task is developing a new form with a new DB table and server code to handle it, it'll be high. So if a low value effort takes more time than necessary or a high value takes less time, it's much more obvious, along with repeats of the same task(s). You can also track dev to see why the tasks didn't stay fixed, if that's what's actually happening, too.
– computercarguy
Oct 3 at 23:06
This is an ideal way to go. You should have an issue management system anyway. It is very useful tool for making productivity visible, with many other benefits.
– Keith
Oct 5 at 4:51
This is an ideal way to go. You should have an issue management system anyway. It is very useful tool for making productivity visible, with many other benefits.
– Keith
Oct 5 at 4:51
add a comment
|
Can you become a star?
Since you're able to get tasks done quicker than others, is it feasible for you to take on a larger chunk of the team's work? Volunteer for more tasks, especially hard tasks that you know you can solve quickly.
Then as long as you also make it clear [1] (as others have suggested) that these tasks aren't easy, they're just easy for you, you will be perceived as a star on the team, not a slacker.
I would also recommend what others have suggested: train others, teach your processes, and share your tools [2] so you can lift up your entire team.
NOTE:
- Figure out how to do this with humility; arrogance is incompatible with professionalism.
- Make sure your tools work well enough first though.
It seems he is taking on more of the work already.
– gnasher729
Oct 5 at 6:15
add a comment
|
Can you become a star?
Since you're able to get tasks done quicker than others, is it feasible for you to take on a larger chunk of the team's work? Volunteer for more tasks, especially hard tasks that you know you can solve quickly.
Then as long as you also make it clear [1] (as others have suggested) that these tasks aren't easy, they're just easy for you, you will be perceived as a star on the team, not a slacker.
I would also recommend what others have suggested: train others, teach your processes, and share your tools [2] so you can lift up your entire team.
NOTE:
- Figure out how to do this with humility; arrogance is incompatible with professionalism.
- Make sure your tools work well enough first though.
It seems he is taking on more of the work already.
– gnasher729
Oct 5 at 6:15
add a comment
|
Can you become a star?
Since you're able to get tasks done quicker than others, is it feasible for you to take on a larger chunk of the team's work? Volunteer for more tasks, especially hard tasks that you know you can solve quickly.
Then as long as you also make it clear [1] (as others have suggested) that these tasks aren't easy, they're just easy for you, you will be perceived as a star on the team, not a slacker.
I would also recommend what others have suggested: train others, teach your processes, and share your tools [2] so you can lift up your entire team.
NOTE:
- Figure out how to do this with humility; arrogance is incompatible with professionalism.
- Make sure your tools work well enough first though.
Can you become a star?
Since you're able to get tasks done quicker than others, is it feasible for you to take on a larger chunk of the team's work? Volunteer for more tasks, especially hard tasks that you know you can solve quickly.
Then as long as you also make it clear [1] (as others have suggested) that these tasks aren't easy, they're just easy for you, you will be perceived as a star on the team, not a slacker.
I would also recommend what others have suggested: train others, teach your processes, and share your tools [2] so you can lift up your entire team.
NOTE:
- Figure out how to do this with humility; arrogance is incompatible with professionalism.
- Make sure your tools work well enough first though.
edited Oct 3 at 16:09
answered Oct 3 at 16:04
bobbob
3,8391 gold badge8 silver badges29 bronze badges
3,8391 gold badge8 silver badges29 bronze badges
It seems he is taking on more of the work already.
– gnasher729
Oct 5 at 6:15
add a comment
|
It seems he is taking on more of the work already.
– gnasher729
Oct 5 at 6:15
It seems he is taking on more of the work already.
– gnasher729
Oct 5 at 6:15
It seems he is taking on more of the work already.
– gnasher729
Oct 5 at 6:15
add a comment
|
There's one thing I can think of but I don't know how appropriate it is. Because it's going on the offensive. Caveat emptor.
Next time you get that comment, keep your posture friendly and deliver a short script you've already prepared, similar to this:
I'm sorry $Boss, this is not the first time you've made this comment and it simply isn't true. I didn't say anything before because I don't want to be perceived as throwing $Coworker under the bus / I found the situation stressful / I could not think how to properly object to this. I propose that, going forward, every ticket we receive must be estimated by both me and $Coworker before they are added to the backlog. It's a good idea anyway, and while I think $Coworker is indeed good at his job, this should not be judged solely on how long tickets take. But I don't know how to communicate this to someone non-technical.
Whoa, bit of a poem. As I said, going on the offensive. The objective here is not to actually do estimates, but to demonstrate your confidence in your skills. If you wanna go even harder, you can propose to setup environments that replicate each complex issue when they come in, and then have each of you work on the other's issues every second Friday after lunch.
1
I'd add that this should be in private, and OP should see how the boss responds to the first bit before proposing competitive estimates - it may be that the boss is well aware of the situation and just feels that the slow guy needs encouragement.
– Robin Bennett
Oct 3 at 8:28
add a comment
|
There's one thing I can think of but I don't know how appropriate it is. Because it's going on the offensive. Caveat emptor.
Next time you get that comment, keep your posture friendly and deliver a short script you've already prepared, similar to this:
I'm sorry $Boss, this is not the first time you've made this comment and it simply isn't true. I didn't say anything before because I don't want to be perceived as throwing $Coworker under the bus / I found the situation stressful / I could not think how to properly object to this. I propose that, going forward, every ticket we receive must be estimated by both me and $Coworker before they are added to the backlog. It's a good idea anyway, and while I think $Coworker is indeed good at his job, this should not be judged solely on how long tickets take. But I don't know how to communicate this to someone non-technical.
Whoa, bit of a poem. As I said, going on the offensive. The objective here is not to actually do estimates, but to demonstrate your confidence in your skills. If you wanna go even harder, you can propose to setup environments that replicate each complex issue when they come in, and then have each of you work on the other's issues every second Friday after lunch.
1
I'd add that this should be in private, and OP should see how the boss responds to the first bit before proposing competitive estimates - it may be that the boss is well aware of the situation and just feels that the slow guy needs encouragement.
– Robin Bennett
Oct 3 at 8:28
add a comment
|
There's one thing I can think of but I don't know how appropriate it is. Because it's going on the offensive. Caveat emptor.
Next time you get that comment, keep your posture friendly and deliver a short script you've already prepared, similar to this:
I'm sorry $Boss, this is not the first time you've made this comment and it simply isn't true. I didn't say anything before because I don't want to be perceived as throwing $Coworker under the bus / I found the situation stressful / I could not think how to properly object to this. I propose that, going forward, every ticket we receive must be estimated by both me and $Coworker before they are added to the backlog. It's a good idea anyway, and while I think $Coworker is indeed good at his job, this should not be judged solely on how long tickets take. But I don't know how to communicate this to someone non-technical.
Whoa, bit of a poem. As I said, going on the offensive. The objective here is not to actually do estimates, but to demonstrate your confidence in your skills. If you wanna go even harder, you can propose to setup environments that replicate each complex issue when they come in, and then have each of you work on the other's issues every second Friday after lunch.
There's one thing I can think of but I don't know how appropriate it is. Because it's going on the offensive. Caveat emptor.
Next time you get that comment, keep your posture friendly and deliver a short script you've already prepared, similar to this:
I'm sorry $Boss, this is not the first time you've made this comment and it simply isn't true. I didn't say anything before because I don't want to be perceived as throwing $Coworker under the bus / I found the situation stressful / I could not think how to properly object to this. I propose that, going forward, every ticket we receive must be estimated by both me and $Coworker before they are added to the backlog. It's a good idea anyway, and while I think $Coworker is indeed good at his job, this should not be judged solely on how long tickets take. But I don't know how to communicate this to someone non-technical.
Whoa, bit of a poem. As I said, going on the offensive. The objective here is not to actually do estimates, but to demonstrate your confidence in your skills. If you wanna go even harder, you can propose to setup environments that replicate each complex issue when they come in, and then have each of you work on the other's issues every second Friday after lunch.
answered Oct 2 at 16:36
rathrath
27k18 gold badges85 silver badges126 bronze badges
27k18 gold badges85 silver badges126 bronze badges
1
I'd add that this should be in private, and OP should see how the boss responds to the first bit before proposing competitive estimates - it may be that the boss is well aware of the situation and just feels that the slow guy needs encouragement.
– Robin Bennett
Oct 3 at 8:28
add a comment
|
1
I'd add that this should be in private, and OP should see how the boss responds to the first bit before proposing competitive estimates - it may be that the boss is well aware of the situation and just feels that the slow guy needs encouragement.
– Robin Bennett
Oct 3 at 8:28
1
1
I'd add that this should be in private, and OP should see how the boss responds to the first bit before proposing competitive estimates - it may be that the boss is well aware of the situation and just feels that the slow guy needs encouragement.
– Robin Bennett
Oct 3 at 8:28
I'd add that this should be in private, and OP should see how the boss responds to the first bit before proposing competitive estimates - it may be that the boss is well aware of the situation and just feels that the slow guy needs encouragement.
– Robin Bennett
Oct 3 at 8:28
add a comment
|
I'm not sure you necessarily need to do anything here.
In my experience, while people might comment on someone working hard, what they really care about is how quickly you fix things for them. They might not comment on it, but after a few years, the best project managers know how to find the resource that will fix the problem the fastest when it's important. They know, because in the past when they assign you things they get done quickly. That will translate to you getting the more important and challenging work, which will translate to your boss giving you better reviews - if you are properly showing your boss what you did that is worth said review, of course.
On Thursday, perhaps the programmer working diligently on the problem will get the kudos. On review day, the programmer who saved the company's bacon in minutes when the client facing application was down, four times, will get them.
While this can be a way to go, it hinges on the "halo effect", which is the OP's problem. If "Kevin" fixes a problem on the Thursday before review, they get the halo, when the "4x major customer save" was several months previous and forgotten, unless it's brought up specifically by the fixer. Unfortunately, doing that can seem like bragging and work against you. It can also be diminished by how quick it was done and 20/20 hindsight. "Oh, it wasn't really as big of a problem as we originally thought." Good managers don't forget saves, but everyone else does.
– computercarguy
Oct 4 at 22:10
add a comment
|
I'm not sure you necessarily need to do anything here.
In my experience, while people might comment on someone working hard, what they really care about is how quickly you fix things for them. They might not comment on it, but after a few years, the best project managers know how to find the resource that will fix the problem the fastest when it's important. They know, because in the past when they assign you things they get done quickly. That will translate to you getting the more important and challenging work, which will translate to your boss giving you better reviews - if you are properly showing your boss what you did that is worth said review, of course.
On Thursday, perhaps the programmer working diligently on the problem will get the kudos. On review day, the programmer who saved the company's bacon in minutes when the client facing application was down, four times, will get them.
While this can be a way to go, it hinges on the "halo effect", which is the OP's problem. If "Kevin" fixes a problem on the Thursday before review, they get the halo, when the "4x major customer save" was several months previous and forgotten, unless it's brought up specifically by the fixer. Unfortunately, doing that can seem like bragging and work against you. It can also be diminished by how quick it was done and 20/20 hindsight. "Oh, it wasn't really as big of a problem as we originally thought." Good managers don't forget saves, but everyone else does.
– computercarguy
Oct 4 at 22:10
add a comment
|
I'm not sure you necessarily need to do anything here.
In my experience, while people might comment on someone working hard, what they really care about is how quickly you fix things for them. They might not comment on it, but after a few years, the best project managers know how to find the resource that will fix the problem the fastest when it's important. They know, because in the past when they assign you things they get done quickly. That will translate to you getting the more important and challenging work, which will translate to your boss giving you better reviews - if you are properly showing your boss what you did that is worth said review, of course.
On Thursday, perhaps the programmer working diligently on the problem will get the kudos. On review day, the programmer who saved the company's bacon in minutes when the client facing application was down, four times, will get them.
I'm not sure you necessarily need to do anything here.
In my experience, while people might comment on someone working hard, what they really care about is how quickly you fix things for them. They might not comment on it, but after a few years, the best project managers know how to find the resource that will fix the problem the fastest when it's important. They know, because in the past when they assign you things they get done quickly. That will translate to you getting the more important and challenging work, which will translate to your boss giving you better reviews - if you are properly showing your boss what you did that is worth said review, of course.
On Thursday, perhaps the programmer working diligently on the problem will get the kudos. On review day, the programmer who saved the company's bacon in minutes when the client facing application was down, four times, will get them.
answered Oct 2 at 19:59
JoeJoe
9,2201 gold badge24 silver badges51 bronze badges
9,2201 gold badge24 silver badges51 bronze badges
While this can be a way to go, it hinges on the "halo effect", which is the OP's problem. If "Kevin" fixes a problem on the Thursday before review, they get the halo, when the "4x major customer save" was several months previous and forgotten, unless it's brought up specifically by the fixer. Unfortunately, doing that can seem like bragging and work against you. It can also be diminished by how quick it was done and 20/20 hindsight. "Oh, it wasn't really as big of a problem as we originally thought." Good managers don't forget saves, but everyone else does.
– computercarguy
Oct 4 at 22:10
add a comment
|
While this can be a way to go, it hinges on the "halo effect", which is the OP's problem. If "Kevin" fixes a problem on the Thursday before review, they get the halo, when the "4x major customer save" was several months previous and forgotten, unless it's brought up specifically by the fixer. Unfortunately, doing that can seem like bragging and work against you. It can also be diminished by how quick it was done and 20/20 hindsight. "Oh, it wasn't really as big of a problem as we originally thought." Good managers don't forget saves, but everyone else does.
– computercarguy
Oct 4 at 22:10
While this can be a way to go, it hinges on the "halo effect", which is the OP's problem. If "Kevin" fixes a problem on the Thursday before review, they get the halo, when the "4x major customer save" was several months previous and forgotten, unless it's brought up specifically by the fixer. Unfortunately, doing that can seem like bragging and work against you. It can also be diminished by how quick it was done and 20/20 hindsight. "Oh, it wasn't really as big of a problem as we originally thought." Good managers don't forget saves, but everyone else does.
– computercarguy
Oct 4 at 22:10
While this can be a way to go, it hinges on the "halo effect", which is the OP's problem. If "Kevin" fixes a problem on the Thursday before review, they get the halo, when the "4x major customer save" was several months previous and forgotten, unless it's brought up specifically by the fixer. Unfortunately, doing that can seem like bragging and work against you. It can also be diminished by how quick it was done and 20/20 hindsight. "Oh, it wasn't really as big of a problem as we originally thought." Good managers don't forget saves, but everyone else does.
– computercarguy
Oct 4 at 22:10
add a comment
|
Don't worry about it and focus your energy on something else that matters in life. With experience you will find that it all comes out in the end.
3
I wish it worked like this. In reality, and I've been there many time before, you just end up a doormat that gets fired because you are invisible and the idiot is "the star" for "working so hard" on things that are simple. There's definitely a lot to be said for living life outside of your job, but job satisfaction is a major factor in having a happy life. Dreading work each morning isn't healthy.
– computercarguy
Oct 3 at 23:13
add a comment
|
Don't worry about it and focus your energy on something else that matters in life. With experience you will find that it all comes out in the end.
3
I wish it worked like this. In reality, and I've been there many time before, you just end up a doormat that gets fired because you are invisible and the idiot is "the star" for "working so hard" on things that are simple. There's definitely a lot to be said for living life outside of your job, but job satisfaction is a major factor in having a happy life. Dreading work each morning isn't healthy.
– computercarguy
Oct 3 at 23:13
add a comment
|
Don't worry about it and focus your energy on something else that matters in life. With experience you will find that it all comes out in the end.
Don't worry about it and focus your energy on something else that matters in life. With experience you will find that it all comes out in the end.
answered Oct 3 at 18:57
matt smithmatt smith
191 bronze badge
191 bronze badge
3
I wish it worked like this. In reality, and I've been there many time before, you just end up a doormat that gets fired because you are invisible and the idiot is "the star" for "working so hard" on things that are simple. There's definitely a lot to be said for living life outside of your job, but job satisfaction is a major factor in having a happy life. Dreading work each morning isn't healthy.
– computercarguy
Oct 3 at 23:13
add a comment
|
3
I wish it worked like this. In reality, and I've been there many time before, you just end up a doormat that gets fired because you are invisible and the idiot is "the star" for "working so hard" on things that are simple. There's definitely a lot to be said for living life outside of your job, but job satisfaction is a major factor in having a happy life. Dreading work each morning isn't healthy.
– computercarguy
Oct 3 at 23:13
3
3
I wish it worked like this. In reality, and I've been there many time before, you just end up a doormat that gets fired because you are invisible and the idiot is "the star" for "working so hard" on things that are simple. There's definitely a lot to be said for living life outside of your job, but job satisfaction is a major factor in having a happy life. Dreading work each morning isn't healthy.
– computercarguy
Oct 3 at 23:13
I wish it worked like this. In reality, and I've been there many time before, you just end up a doormat that gets fired because you are invisible and the idiot is "the star" for "working so hard" on things that are simple. There's definitely a lot to be said for living life outside of your job, but job satisfaction is a major factor in having a happy life. Dreading work each morning isn't healthy.
– computercarguy
Oct 3 at 23:13
add a comment
|
I think you have some pretty blah answers here that seem to be more concerned on you marketing yourself than the reality of your job.
Here are the facts:
- your manager has no clue on a "technical" level
- your company is very low tech
- your fellow coworkers on the tech side are mediocre at best
- being better at your job no way ensures you of moving up or getting paid more because of the knowledge debt at your company
What would I do?
- Be a d*ck. Yep be the guy that is a hard ass and bluntly honest about how long something should take whatever. Not trying to belittle coworkers but an honesty that is kind of backstabbing but only because they aren't very good.
- Be slower. Take your time doing things. Teach yourself other things while you are troubleshooting and make everything take 5 times longer.
- Work on other co-workers things when they are taking to long. This goes with points 1 and 2. Anytime you know a coworker is struggling with something that is "easy" then start working on that and just link that troubleshooting to something you were doing or just act like you accidentally stumbled on the solution. This will bring context to your abilities vs. your coworkers. Don't just do it a few times
If you want to be the nice guy just "market" yourself better. If you want to be everyone's boss in two years be a d*ck.
Edit: For those who think this could backfire or OP could have issues taking this route.
- Yes I get it. I don't think I was beating around the bush. This employee is really much better than the rest of his team but management is treating him as the same or less. So he can sit around and accept this and watch some morons or lesser skilled employees advance and possibly be his future boss or he can take action. My point is he has nothing to lose. Worst case scenario is that the company thinks is is a dck and doesn't like him but understands he is much more qualified than others. So yea he could lose his job for personal reasons (I highly doubt this and he shouldn't give a crap working for a company in this situation). But another scenario is management thinks he is a dck but also really smart, aggressive and take charge - you know like a really good tech director. And then the other is he can do this without people thinking he is a d*ck and the company will think they have some genius on their hands. To me the risk is well worth the effort here. If he gets canned he will surely have notice and if he doesn't this is the tactic to move up the quickest.
3 before 1. OP needs evidence and backing from management before 1 will work
– aidan.plenert.macdonald
Oct 3 at 22:03
FYI, this can really backfire badly. The dck will get fired before the slow guy, since the slow guy is "good" and no one likes the dck. "He's just a poser anyway." You need to prove yourself to be a "known good" first before trying this, which it appears the OP doesn't have on their side right now. So I definitely agree: 3 before 1.
– computercarguy
Oct 3 at 23:10
1
-1 "Be a dick and do nice backstabbing". This is not the advice that I would give even if it works. I have to stick to my morals and ethics. I consider them to be very important.
– Michael Durrant
Oct 4 at 11:28
3
Also 'your management has no clue' is insanely arrogant (because it is a blanket statement) and will lead you to an attitude that will others will find disturbing when trying to work with you.
– Michael Durrant
Oct 4 at 11:29
@computercarguy - sure it is a bit risky. I will update my response.
– blankip
Oct 4 at 21:44
add a comment
|
I think you have some pretty blah answers here that seem to be more concerned on you marketing yourself than the reality of your job.
Here are the facts:
- your manager has no clue on a "technical" level
- your company is very low tech
- your fellow coworkers on the tech side are mediocre at best
- being better at your job no way ensures you of moving up or getting paid more because of the knowledge debt at your company
What would I do?
- Be a d*ck. Yep be the guy that is a hard ass and bluntly honest about how long something should take whatever. Not trying to belittle coworkers but an honesty that is kind of backstabbing but only because they aren't very good.
- Be slower. Take your time doing things. Teach yourself other things while you are troubleshooting and make everything take 5 times longer.
- Work on other co-workers things when they are taking to long. This goes with points 1 and 2. Anytime you know a coworker is struggling with something that is "easy" then start working on that and just link that troubleshooting to something you were doing or just act like you accidentally stumbled on the solution. This will bring context to your abilities vs. your coworkers. Don't just do it a few times
If you want to be the nice guy just "market" yourself better. If you want to be everyone's boss in two years be a d*ck.
Edit: For those who think this could backfire or OP could have issues taking this route.
- Yes I get it. I don't think I was beating around the bush. This employee is really much better than the rest of his team but management is treating him as the same or less. So he can sit around and accept this and watch some morons or lesser skilled employees advance and possibly be his future boss or he can take action. My point is he has nothing to lose. Worst case scenario is that the company thinks is is a dck and doesn't like him but understands he is much more qualified than others. So yea he could lose his job for personal reasons (I highly doubt this and he shouldn't give a crap working for a company in this situation). But another scenario is management thinks he is a dck but also really smart, aggressive and take charge - you know like a really good tech director. And then the other is he can do this without people thinking he is a d*ck and the company will think they have some genius on their hands. To me the risk is well worth the effort here. If he gets canned he will surely have notice and if he doesn't this is the tactic to move up the quickest.
3 before 1. OP needs evidence and backing from management before 1 will work
– aidan.plenert.macdonald
Oct 3 at 22:03
FYI, this can really backfire badly. The dck will get fired before the slow guy, since the slow guy is "good" and no one likes the dck. "He's just a poser anyway." You need to prove yourself to be a "known good" first before trying this, which it appears the OP doesn't have on their side right now. So I definitely agree: 3 before 1.
– computercarguy
Oct 3 at 23:10
1
-1 "Be a dick and do nice backstabbing". This is not the advice that I would give even if it works. I have to stick to my morals and ethics. I consider them to be very important.
– Michael Durrant
Oct 4 at 11:28
3
Also 'your management has no clue' is insanely arrogant (because it is a blanket statement) and will lead you to an attitude that will others will find disturbing when trying to work with you.
– Michael Durrant
Oct 4 at 11:29
@computercarguy - sure it is a bit risky. I will update my response.
– blankip
Oct 4 at 21:44
add a comment
|
I think you have some pretty blah answers here that seem to be more concerned on you marketing yourself than the reality of your job.
Here are the facts:
- your manager has no clue on a "technical" level
- your company is very low tech
- your fellow coworkers on the tech side are mediocre at best
- being better at your job no way ensures you of moving up or getting paid more because of the knowledge debt at your company
What would I do?
- Be a d*ck. Yep be the guy that is a hard ass and bluntly honest about how long something should take whatever. Not trying to belittle coworkers but an honesty that is kind of backstabbing but only because they aren't very good.
- Be slower. Take your time doing things. Teach yourself other things while you are troubleshooting and make everything take 5 times longer.
- Work on other co-workers things when they are taking to long. This goes with points 1 and 2. Anytime you know a coworker is struggling with something that is "easy" then start working on that and just link that troubleshooting to something you were doing or just act like you accidentally stumbled on the solution. This will bring context to your abilities vs. your coworkers. Don't just do it a few times
If you want to be the nice guy just "market" yourself better. If you want to be everyone's boss in two years be a d*ck.
Edit: For those who think this could backfire or OP could have issues taking this route.
- Yes I get it. I don't think I was beating around the bush. This employee is really much better than the rest of his team but management is treating him as the same or less. So he can sit around and accept this and watch some morons or lesser skilled employees advance and possibly be his future boss or he can take action. My point is he has nothing to lose. Worst case scenario is that the company thinks is is a dck and doesn't like him but understands he is much more qualified than others. So yea he could lose his job for personal reasons (I highly doubt this and he shouldn't give a crap working for a company in this situation). But another scenario is management thinks he is a dck but also really smart, aggressive and take charge - you know like a really good tech director. And then the other is he can do this without people thinking he is a d*ck and the company will think they have some genius on their hands. To me the risk is well worth the effort here. If he gets canned he will surely have notice and if he doesn't this is the tactic to move up the quickest.
I think you have some pretty blah answers here that seem to be more concerned on you marketing yourself than the reality of your job.
Here are the facts:
- your manager has no clue on a "technical" level
- your company is very low tech
- your fellow coworkers on the tech side are mediocre at best
- being better at your job no way ensures you of moving up or getting paid more because of the knowledge debt at your company
What would I do?
- Be a d*ck. Yep be the guy that is a hard ass and bluntly honest about how long something should take whatever. Not trying to belittle coworkers but an honesty that is kind of backstabbing but only because they aren't very good.
- Be slower. Take your time doing things. Teach yourself other things while you are troubleshooting and make everything take 5 times longer.
- Work on other co-workers things when they are taking to long. This goes with points 1 and 2. Anytime you know a coworker is struggling with something that is "easy" then start working on that and just link that troubleshooting to something you were doing or just act like you accidentally stumbled on the solution. This will bring context to your abilities vs. your coworkers. Don't just do it a few times
If you want to be the nice guy just "market" yourself better. If you want to be everyone's boss in two years be a d*ck.
Edit: For those who think this could backfire or OP could have issues taking this route.
- Yes I get it. I don't think I was beating around the bush. This employee is really much better than the rest of his team but management is treating him as the same or less. So he can sit around and accept this and watch some morons or lesser skilled employees advance and possibly be his future boss or he can take action. My point is he has nothing to lose. Worst case scenario is that the company thinks is is a dck and doesn't like him but understands he is much more qualified than others. So yea he could lose his job for personal reasons (I highly doubt this and he shouldn't give a crap working for a company in this situation). But another scenario is management thinks he is a dck but also really smart, aggressive and take charge - you know like a really good tech director. And then the other is he can do this without people thinking he is a d*ck and the company will think they have some genius on their hands. To me the risk is well worth the effort here. If he gets canned he will surely have notice and if he doesn't this is the tactic to move up the quickest.
edited Oct 4 at 21:50
answered Oct 3 at 16:23
blankipblankip
21.4k7 gold badges50 silver badges83 bronze badges
21.4k7 gold badges50 silver badges83 bronze badges
3 before 1. OP needs evidence and backing from management before 1 will work
– aidan.plenert.macdonald
Oct 3 at 22:03
FYI, this can really backfire badly. The dck will get fired before the slow guy, since the slow guy is "good" and no one likes the dck. "He's just a poser anyway." You need to prove yourself to be a "known good" first before trying this, which it appears the OP doesn't have on their side right now. So I definitely agree: 3 before 1.
– computercarguy
Oct 3 at 23:10
1
-1 "Be a dick and do nice backstabbing". This is not the advice that I would give even if it works. I have to stick to my morals and ethics. I consider them to be very important.
– Michael Durrant
Oct 4 at 11:28
3
Also 'your management has no clue' is insanely arrogant (because it is a blanket statement) and will lead you to an attitude that will others will find disturbing when trying to work with you.
– Michael Durrant
Oct 4 at 11:29
@computercarguy - sure it is a bit risky. I will update my response.
– blankip
Oct 4 at 21:44
add a comment
|
3 before 1. OP needs evidence and backing from management before 1 will work
– aidan.plenert.macdonald
Oct 3 at 22:03
FYI, this can really backfire badly. The dck will get fired before the slow guy, since the slow guy is "good" and no one likes the dck. "He's just a poser anyway." You need to prove yourself to be a "known good" first before trying this, which it appears the OP doesn't have on their side right now. So I definitely agree: 3 before 1.
– computercarguy
Oct 3 at 23:10
1
-1 "Be a dick and do nice backstabbing". This is not the advice that I would give even if it works. I have to stick to my morals and ethics. I consider them to be very important.
– Michael Durrant
Oct 4 at 11:28
3
Also 'your management has no clue' is insanely arrogant (because it is a blanket statement) and will lead you to an attitude that will others will find disturbing when trying to work with you.
– Michael Durrant
Oct 4 at 11:29
@computercarguy - sure it is a bit risky. I will update my response.
– blankip
Oct 4 at 21:44
3 before 1. OP needs evidence and backing from management before 1 will work
– aidan.plenert.macdonald
Oct 3 at 22:03
3 before 1. OP needs evidence and backing from management before 1 will work
– aidan.plenert.macdonald
Oct 3 at 22:03
FYI, this can really backfire badly. The dck will get fired before the slow guy, since the slow guy is "good" and no one likes the dck. "He's just a poser anyway." You need to prove yourself to be a "known good" first before trying this, which it appears the OP doesn't have on their side right now. So I definitely agree: 3 before 1.
– computercarguy
Oct 3 at 23:10
FYI, this can really backfire badly. The dck will get fired before the slow guy, since the slow guy is "good" and no one likes the dck. "He's just a poser anyway." You need to prove yourself to be a "known good" first before trying this, which it appears the OP doesn't have on their side right now. So I definitely agree: 3 before 1.
– computercarguy
Oct 3 at 23:10
1
1
-1 "Be a dick and do nice backstabbing". This is not the advice that I would give even if it works. I have to stick to my morals and ethics. I consider them to be very important.
– Michael Durrant
Oct 4 at 11:28
-1 "Be a dick and do nice backstabbing". This is not the advice that I would give even if it works. I have to stick to my morals and ethics. I consider them to be very important.
– Michael Durrant
Oct 4 at 11:28
3
3
Also 'your management has no clue' is insanely arrogant (because it is a blanket statement) and will lead you to an attitude that will others will find disturbing when trying to work with you.
– Michael Durrant
Oct 4 at 11:29
Also 'your management has no clue' is insanely arrogant (because it is a blanket statement) and will lead you to an attitude that will others will find disturbing when trying to work with you.
– Michael Durrant
Oct 4 at 11:29
@computercarguy - sure it is a bit risky. I will update my response.
– blankip
Oct 4 at 21:44
@computercarguy - sure it is a bit risky. I will update my response.
– blankip
Oct 4 at 21:44
add a comment
|
Highly active question. Earn 10 reputation in order to answer this question. The reputation requirement helps protect this question from spam and non-answer activity.
Highly active question. Earn 10 reputation in order to answer this question. The reputation requirement helps protect this question from spam and non-answer activity.
Highly active question. Earn 10 reputation in order to answer this question. The reputation requirement helps protect this question from spam and non-answer activity.
Highly active question. Earn 10 reputation in order to answer this question. The reputation requirement helps protect this question from spam and non-answer activity.
1
Comments are not for extended discussion; this conversation has been moved to chat.
– Mister Positive♦
Oct 4 at 21:15