Ask HN: How to deal with 0.1X programmer colleagues?

[startupfreak]

I worked at tech-team-of-one startups for years. Now I'm working at a big organisation.

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?

[neilv]

Questions to maybe consider:

* 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.

[fnimick]

How can you be so sure all your colleagues are useless? Are they doing any important but non-flashy work (planning, documentation, cleanup, etc) that isn't captured by the "story point" metric, which is a pretty bad tool to gauge productivity anyway?

[icedchai]

Keep in mind all of that important but non-flashy work can also be used as a cover for not doing anything of consequence. Yes, sometimes it is important, but 70% of the time when I see someone has been "planning" they've done absolutely jack... (Recent example: How can a PM plan a software engineering project without talking to the people actually doing the work? Then they wonder why the "plan" makes no sense...)

[Fire-Dragon-DoL]

I hear your point but I wouldn't dismiss the op point, those situations do happen.

In this case the problem could be just miscommunication, it's worth asking some help from the team

[that_guy_iain]

Realistically shouldn't those tasks be given story points too if they're done separaterly from the team?

[agentultra]

I used to manage a developer whose claim to fame was how many "story points" they crushed. There was no rhyme or reason to their work, they would never say no to anything, and it didn't matter if their changes caused performance regressions or added broken windows to the code base: closed was closed and nothing else mattered. Working with them was difficult: they saw themselves as this productivity machine but the rest of the team was dealing with all of the extra work their productivity brought: more outages and incidents, code complexity, 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

[sambeau]

Are you sure that's all they are doing?

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, …

[itake]

You’re probably optimizing for the wrong metrics. Look at the people that are promoted quickly and copy what they are doing.

It probably isn’t number of JIRA tickets.

[snapplebobapple]

This is the right answer if your goal is make more money (which it probably should be). Other right answer is find a place that rewards based on JIRA tickets if you want to be a highly productive programmer.

[that_guy_iain]

This makes a few assumptions while not answering the question or even really understanding what OP has to say.

They don't seem to be bothered about promotion. More that they think they're doing a lot more work than everyone else.

[ghotli]

I didn't see this observation in the comments so chiming in. Your 'team-of-one' comment resonated with me. Another way to frame what you're saying is that you're years behind when it comes to professional development working together on a team of engineers.

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.

[qrohlf]

Before you attempt to do anything, first try to assess whether your organization and/or management has a strong “don’t rock the boat” culture. In my experience, an isolated contributor moving super slow might be down to the individual, but a whole team moving slow is usually due to systemic factors.

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.

[icedchai]

I'd agree. If the organization is dysfunctional, there's nothing you can do. These problems start at the top.

[ryandvm]

This is how big orgs ALWAYS work. You have to get used to it or go back to the startup trenches.

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.

[noirbot]

The other aspect of it is that with a big company, it's often much more about choosing what is valuable to work on vs. just doing everything you can put your hands on. Large organizations generate large numbers of requests and suggestions, many of which aren't worth anyone's time. You're usually not working on a project where you're needing to add new features or fix bugs ASAP or else the company disappears. The low-hanging fruit of time spent to value created has already been picked years or decades ago.

Ironically, part of the point of having so many people accomplish so little is agility. It's the HR equivalent of owning a gigabit internet line when you're mostly browsing HN and checking your email. Most of the time, it's a waste and no doing anything for you, but when you need it, you don't want to be calling your ISP to try to upgrade. Having tens of "hot spare" engineers who are already used to the product and system who can jump on a big product need on a week's notice can be worth paying them the rest of the time to do very little.

It doesn't mean you're going to feel like you're solving amazing problems every day, but it doesn't mean those other engineers aren't sharp people who can get through a meaningful ticket when it needs to be done. They just know when it doesn't need to be done.

[brd529]

Talk to your manager or find a mentor within the company and ask for advice. Rather than framing it as “my colleges are all slackers” frame it as “what am I missing?” At big tech orgs success can mean a lot more than coding. It’s possible you are not doing things the others are doing… writing specs, documenting, interviewing, planning, etc. the bigger the engineering org the more time spent communicating. It may be they are doing more testing than you as well. It may be that this isn’t for you and you should return to the world of tiny teams where you really can code all day and “feel” much more productive because the communication overhead is so low.

[Apreche]

Your mistake is caring. Are you being rewarded for working much harder than your colleagues? Are they being punished for working hardly at all? Why are you working hard for the benefit of the company's bottom line? It's a big company, why do you care about its bottom line?

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.

[CookieCrisp]

I made the same "mistake" this person did. Companies didn't reward me. But you know what? I kept improving, they didn't, and I was eventually able to launch my own company while they stay stuck in that job. Obviously companies should reward us for doing better, but, when they don't it still doesn't mean there's no potential benefit from "practicing" doing good work while at work.

[michaelmior]

> Caring about your job is only acceptable if…

This suggests that it's unacceptable to care about doing your job well because you enjoy it or simply because your morals compel you to work hard at what you do. I don't think there's anything wrong with someone choosing to work hard for these reasons if that's their choice.

[ojhughes]

This is a terrible take, if you are passionate about your work then those 8 hours go a whole lot quicker. If you’re not passionate then I would question if the position is a good fit

[neilv]

> 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.

We don't know that. That's one stereotype theory that comes to mind when we hear "big company", but that's not the only plausible explanation.

Also, some people told to do the bare minimum at their jobs will think "Alrighty!" But the same advice could be very counterproductive for people who take pride in their craft or professionalism, or who want to see the mission happen. Those people should be nudged towards improving their situation (either at the current place, or somewhere else), not destroying their strengths.

[Arch-TK]

I need a job I can care about or else I struggle to do the work.

[agg23]

Passion can be good, but it must also be measured. I was in a similar situation for several years where I ended up running the show. Was super passionate about the project and doing all the things...

Ended up horribly burnt out, to the point that I'm still struggling with the idea of working 2 years later.

[basicallybones]

You are asking how to change the culture at a big organization. It is not possible unless you are C-Suite. This is true of most smaller organizations as well, though in smaller organizations the C-Suite may be more accessible.

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.

[basicallybones]

By the way, it sounds like you are frustrated with how companies work in general. You should read this excellent essay: https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-....

Under this loser/clueless/sociopath framework, the skilled engineers at many organizations (including yours, it seems) simply are highly paid "losers" with cushy benefits (I do not mean this as a personal insult!). Your colleagues may have an experience-driven grasp of this and are acting rationally, in a way.

[n_time]

You sound like a very competitive person. You might want to consider that a lot of software development is actually the navigation of socio-technical systems. Heavy emphasis on the socio. Your competitive drive isn't bad, but it might lead you to local optima in your career in the long-run.

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...).

[phoe-krk]

Mature companies can't afford being as fast as startups simply because their different size causes 1) a completely different level of decision inertia, 2) a completely different level of communication issues.

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.

[mettamage]

Take more time into learning technologies and stuff you find fun and call it work. It actually is work, but employers don't tend to see that. Make coding fun for yourself.

[crop_rotation]

Everyone works slowly at a big company. What you should do is try to see how you can leverage your contributions to grow faster. People not only work very slowly at big companies, but saying something like that might land you in HR issues. People will work at different pace, and the company has decided that their pace is acceptable too. Just ensure that you get credit for your own work and rise fast.

[WhatsName]

"It's a marathon, not a sprint". I've only ever heared this phrase working for a big corp during my first large incident response engagement.

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.

[sonicshadow]

Then they proceed to call the samn things “sprints” and except us to do them back to back to no end

[JacobDotVI]

A formula 1 race car is _much_ faster than a freight truck. However a freight truck can deliver a lot more goods across the country than an F1 car. Which is your big organization optimizing for?

[jrochkind1]

I'm guessing you enjoy doing the work of writing software, because I think most people who are productive like that do.

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.

[onion2k]

I worked at tech-team-of-one startups for years.

I wonder if you picked up any bad habits, like forgetting how to work on a team.

[superchroma]

You're working too hard. And you're stupid. You set your own high watermark super high, now you can't back it off without getting questions directed at you.

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.

[hoosieree]

Cynical take: being this much more effective than their colleagues won't get OP promoted, but it might get the rest of the team fired.