In the last sprint, I chalked up 41 story points. The rest of the team (3 other devs and a mostly hands-off tech lead) collectively achieved 9 story points. That's 1 medium-sized ticket each over the space of a fortnight. Everyone has a good excuse, but they ALWAYS have a good excuse.
It's driving me nuts. I'm a good coder, but this isn't about me being good, this is about them all being, on paper, completely ineffective. No one inside or outside the team seems to be batting an eyelid about this. I feel resentful and... confused.
It's hard to stay motivated when the bar is so low, but I would feel guilty slacking off all day. What do I do?
* If you're relatively new, are they giving you starter tasks?
* Are the other team member's tasks harder, less-straightforward, involving less-familiar tech, slowed/blocked by dependencies, less amenable to just crunching through mechanically, etc.?
* Are the other team members doing higher-quality work? (A big corp. might have very different ideas of what software engineering is than you did in a one-person-tech-team startups. Are you a one-person tech debt machine?)
* Do the other team members have more responsibilities separate from this code?
* Is the team in a catch-your-breath period, after a big push to ship something, and people also taking summer vacations, etc.?
* Is there a morale problem going on that you haven't picked up on? Were there layoffs recently? Or do people know something you don't know, like that the project is going to be canceled? Is this a team or company that people want to be in? Is everyone interviewing or practicing Leetcode?
* Why is the tech lead or people manager not on top of this, if it's a problem? (Or maybe they are, but they're handling it discreetly, one-on-one with people, rather than embarrassing people in front of the team?)
These questions also suggest one way to broach the topic with a tech lead or people manager, if you don't yet know whether it's safe to speak more candidly: you could ask how your work is fitting the conventions of the organization, are you blowing through tasks too quickly, is there something you should be doing differently, etc.
I can't tell if that's what you're doing but it was a good lesson for them to think more strategically and be focused on what matters to the team and to them. Being able to deliver and make progress at a reasonable pace is a good thing but, in our case, delivering lines per hour was not the metric we were measuring.
Maybe what you need to do is have an honest conversation with your team or team lead. What does the team value? What are the expectations?
Update: fixed spelling/grammar
When a new coder joined our team they always got loads done as they were left to completely concentrate on their work on the board. Meanwhile, the rest of the team where dealing with support requests, sales requests, pulling stats from the database for random execs, security audits, fixing the build system (again), CV reviews, design documents, code reviews, customer requests, 20 email or slack chains that they are somehow on, invites & menus for the staff party, …
It probably isn’t number of JIRA tickets.
The phrases 'driving me nuts' and 'them being completely ineffective' are what reinforce this view, to me at least. They may be working far less hard on the code than you are, but it sounds to me like you're working far less hard on being a good teammate and given your history that may take time.
To be completely honest it sort of sounds like you're taking stimulants and they aren't, at least from the way you wrote this up. Get in, get good work done, get out. If you work remotely, all the better. Do some laundry, read a book. Meet and exceeding expectations sounds like about half of what you're getting done and getting worked up about (which I assume is tanking your mood into your evenings).
Focus on the soft skills and be a part of raising your team's morale (yourself included) rather than torpedo-ing it. I suspect the look on your face in some meetings says everything you wrote up here already.
Attempting to create accountability or meaningful changes to velocity in a “don’t rock the boat” org is usually a one-way ticket to workplace politics hell. If you value building things, small-startup style, you will likely want to avoid this.
Finding a good manager who is willing to give you special-mission style projects to execute on quickly and effectively is often a far better strategy than trying to deal with widespread molasses speed dev culture. Even better, typically, is moving to an organization where the culture and peers match up better with your desired speed and quality of execution.
The startup pace can be grueling, it can have terrible hours, it can be unrewarding, but at least you're always working. At big orgs with plenty of funding you just sort of marvel at how so many people can accomplish so little. Everyone is always blocked by another team or some arcane bureaucratic process. It never ends and it never gets better.
The good news is you're probably well compensated and have complete job security. The bad news is you're at heightened risk for existential crisis.
Your colleagues have the right attitude. They are doing the absolute bare minimum to collect a paycheck and go home. I suggest you do the same.
Caring about your job is only acceptable if your labor is sufficiently rewarded, you own the company, or if it's some kind of non-profit or public service job that actually benefits society. If you're working for a for-profit organization, the goal is not to work hard, but to be exploited as little as possible.
This is the time to work on yourself. Do not let your team change you or slow you down. Do the work required, improve your skills, and go find a better team.
How do you get things done in a larger organization? At AWS it's solved by having APIs and documentation for everything. This leads to a janky UI, a lot of redundancy in their systems, and a pretty bad work environment from what I hear.
In a lot of technical organizations, this problem is solved instead informally through relationships between members of the organization. You want to get something done outside of your constrained contexts? You'll probably need some relationships. Getting a lot of cards done is great, but if you're pushing too hard all the time you're going to sour those relationships.
What I'm saying boils down to this: being a developer in a large organization is about 1-3 parts coding to 7-9 parts communication and relationships. Further, if you spend time communicating you can often realize that the feature you're implementing was already implemented two years ago and there's just a regression that's caused the line of code to no longer be executed.
You can say fuck it to the communications with your peers if you'd like. However, keep in mind that most of your jobs as you become senior are going to come from referrals from former colleagues. Your boss right now isn't going to help you get your next job–the people sitting around you might.
Consider reading [non-violent communication](https://www.amazon.com/Nonviolent-Communication-Language-Lif...).
You're not working with 0.1X colleagues, you're working at a 0.1X company. If that's too slow for you but acceptable for your manager, talk with them about it; in the best case, consider yourself free to spend the henceforth-saved time doing something else.
Having worked both at startups and large organizations, I can tell that there are two extremes and neither are healthy.
It seems like you got used to the constant crunch time that startups use to burn faster through their usually young human resources. From my experience, noone can sustain that pace without getting burned out or/and (willingly) compromising on their spouses and personal connections outside work.
Looking at the bigger picture you might realize that there are different point of views what progress means. In big corp it's usually about getting rid of/around obstacles, while startups focus on growth, happy VCs and other metrics that mean very little to a big corporate machine that by itself got enough intertia to keep moving even if it doesn't hit those metrics.
Conversely if your current business is running on billable hours. Finishing earlier and providing unrealistic client expectations might activly hurt your employer.
So I agree with you that "just do less" is not a good answer, and will not actually lead to satisfaction. The risk is not only guilt, but even worse, the soul-destroying feeling of being a useless person just keeping a seat warm. Although I agree with another commenter that doing things like learning new technologies and reading and commenting on Hacker News is "work" that you can definitely allow yourself to do if you would enjoy or appreciate it. If you start resolving somewhat fewer story points but still way more than anyone else, nobody is going to notice/call you on it.
But meanwhile, you are doing work you enjoy doing, what exactly is the nature of your annoyance? Just that it doesn't seem "fair" that they don't work very hard? I think you have to get over that. It's not your job to discipline them, and who knows how hard they are working (maybe they work very hard, they just aren't very skilled) or what else they have going on in their lives that may be very hard and distracting them.
If you would just appreciate working on a team with other people at your level you can collaborate with, if you would just enjoy that more -- you aren't going to get that on this team. That situation is really not going to change on this team, and there's no point in trying to. You will have to find another team/job/role (maybe at the same organization, possibly not) to find that.
Perhaps there is someone on your team who would like to learn from you and get more productive? You might enjoy mentoring them if so, including even pair programming etc.
If you can't control your disdain for the other team members, you will have to find a new job. Neither you nor they are going to be happy if it becomes clear you think they are incompetent slackers.
I wonder if you picked up any bad habits, like forgetting how to work on a team.
At no point in your career is holding your peers to account part of the role of a developer. Get that through your skull quickly.
Either find a job where you're under the hammer more and the comp is what you want or learn to live with this. Or work on your own projects on the side. Do anything but what you are doing.
The best employees don't get promoted or celebrated for working super hard. I've never yet met one who was.
In the grand scheme of things, your complaint is minuscule. Trying to adjust the world to sate your ego is the folly of many men. Think carefully about what you actually have control over, and count your blessings that this is all you have to complain about.
The members of your team are not reporting to you, so it isn’t your problem, or maybe isn’t a problem at all and the “big” company has enough money and people to get done what needs to get done at whatever pace is normal to them.
I handle a small corner of product development i.e. B2B 3D asset development from multimedia. Every weekly meeting my progress report is modest. You might bin me into that 0.1x engineering member.
Yet, I could tell you I remain quite busy. 33% of my time goes into product development. The other 67% are into quasi-employee management tasks (quarterly performance checks, their salary/bonus/increments, merging their code branches, keeping tabs on infrastructure), Capital generation (meeting investors, putting engineering-sensible business plans, correspondence etc) & PR (showing up at conferences, keeping updated with latest tech by reading papers, building professional networks to access talent/ investors/ experts on corp's behalf.)
If looking at purely my LOC, I probably add half or a third of the average guy right now. I know it could be better - and I keep trying to improve my IC role. But the message I want to let know is: A lot of things are going on without others being plastered with updates. And that happens with gradual seniority in org chart.
Do I miss my TopCoder days? Yes absolutely. Will I start doing that now? Probably not. Someone has to help run the engineering team. All that coding might is useless if we run out of workplace cohesion and investor money. And I am uniquely positioned to do that. I would like to see the team run rumbling along rather than few Usain Bolts sprinting in their chosen directions.
Maybe some other startup-to-large-company folks will have interesting insights. I feel your pain, though. I'm also used to a fast environment, I can't imagine slowing down like that.
Also just chill out about perceived relative effort! If deadlines slip, if bad code is being shipped, then you should be concerned about your coworkers effort. If your team is meeting deadlines, then it is managements responsibility to fill the work queue, if you want more work ask for it. Your job isn't to manage your coworkers who all have their own lives and relationships to the work. If you are worried that you are doing more work for less money, do less work or ask for a raise.
Did you talk to your manager and the team? How was it like in planning when you take far more points than the other? What is your opinion on the validity of the team's excuse? Was your code done in the sense that it is now running on production?
Working for a company, on a team, is different than just being a solo contributor. Teammate relations can be leveraged to create a better product through, well, teamwork. I want people to be happy and effective at their jobs, myself included. I try to work with others, understand what they are doing, and do things that directly or indirectly contribute to their efforts and even unite efforts across individuals and teams. There are usually inefficiencies that come from lack of communication. Talk to your coworkers and manager and adjacent teams and understand better why things work the way they do, stop just running off and racking up story points, it is not a race.
Raise your quality bar. Work on things that are peripheral to the original issue but makes everyone's lives better. Improve effectiveness of testing, make invalid situations impossible or unlikely to arise. Document what you learn, which is ideally done when information is new to you.
Another thing you can do is pair with some of the other devs. Maybe you can offer some insights that make their work go more smoothly, or maybe you'll get some context as to what complications exist that aren't in the original estimate.
The only good use for points anywhere I've worked was that we could measure 'firefighting hours' per sprint for the whole team relative to the stories that got done. I wish there was a way of connecting slow delivery with tech debt to allow focusing on reducing it.
OTOH I've also worked at a supposed-tech-startup where other team members were literally telling me not to work so hard, it's making everyone look bad.
In teams bound by certain process, whatever reason they may have, and that process may well be stupid, but it is there and agreed upon, the velocity is usually adjusted within a few sprints such that it’s mostly even. Outliers this big are a smell, and whoever is the outlier is suspect.
Maybe your definition of what a story point is off the mark. Maybe their stories require lots of yak shaving. Maybe it’s what I said in the beginning. But in general I won’t for a second buy that the whole thing keeps ticking because of your valiant effort and they all are lazy asses. This is easily provable by your going on an extended leave. Either you come back and it’s all unmoved or ruined and they are indeed bumbling lazy asses, or your effort don’t move the needle as much as you think they do, or they all deliver more because you’re not there.
If you're new then there will be a bunch of stuff you're probably not doing which others may be doing. Meetings with other teams, code review of other teams work, meetings with clients or other departments, chasing up things that are just lying around that don't really have tickets but yet somehow you need to deal with.
The fact they have a good excuse is really the thing. They have a good reason why. They're telling you all the other stuff they're working on but you're focused on the basic tasks because you're not used to dealing with the other stuff.
You may just not be cut out for working in teams for big companies. You may be someone who should work by themselves on small products. They're two totally different things and people who are good at one aren't always good at the other.
There seems to always be a finite amount of completable work at any workplace. Let's say for purpose of your example it's 72 story points worth of work.
By completing about 30 story points yourself in a 4 member team you might inadvertendly end up taking work that could be comfortably completed by your team mates leaving them with work that is either very challenging or work that they are not motivated to complete.
At the same time they see you overperforming and basically "carrying" the team. Imagine yourself in your next job, after this experience, having a team mate that is able to do 400% of the work you can do.
Would you fight this teammate for the finite amount of completable work or would you sit back letting them do all the work ?
It's a job, if the execs are happy with the output that's enough, not everyone gets a hard on from typing code all day long.
That's your problem. It's very difficult to keep competency high in a large organization. The system is designed to get predictable output, and be robust to variations in human capital. The low performance of your peers is known and expected by the organization.
The reverse is also true. People who are low competency, or only want to put in minimal effort choose employment at large corporations. It's easier to hide, they have to make less important decisions themselves, less accountability, expectations are lower.
The mismatch here is you. The system you are operating in is not trying to identify or reward hyper-competency, and hyper-compentents are not trying to enter the system.
If you do, then that should be a sufficient motivator. If not, then prepare your exit.
Other questions to consider: Do you need the paycheck? Is this position beneficial to your long term career growth?
If nothing else helps and you don't want to be the best guy, go work in another place with better people.
If it's just the principle of the thing that's bothering you, my advice would be to either go someplace where your peers will be closer to your level, or to just choose to not be bothered by things that don't actually negatively affect you.
Maybe you are the outlier that moves fast and breaks things, while the rest prefer sustainable progress over the long periods?
If you work remote, get overemployed and collect multiple paychecks and be decent at those jobs instead of a rockstar.
Else, continue crushing it, this job looks WAY too easy for you and you wont grow here without having the right challenges and learnings. Look for roles in other teams in the company where you are not the smartest one in the room. Once you grow there and start crushing it, you will grow naturally.
You need to work sustainably at a big company. Because there's lots of road blocks to frustrate you. Managing frustration is a skill. Working at 50% capacity is a tactic.
I believe it's all about you thinking that you are too good
Maybe you should start your own company and code the next twitter, facebook or something
So, everything looks good from a org stand point. Maybe you are looking at the wrong metric, or maybe you are not a good fit for them.
And if you are irreplaceable in your current role, how do you expect to get promoted into another role?
Don't feel guilty slacking off, unless it's your business.
Frankly, it sounds like you're the problem here.