[barbiturique]

That's my tactic to blend-in in a engineering team and gain some respect / credibility. I try to find the most boring, utterly broken part, that nobody wants to touch... and I sink time into it.

Once I made it somewhat usable, I document it.

[mdpye]

I hadn't realised it til now, but I do the same. It's a really great way to get started, because it tends to coincide with not having yet gained a broad range of responsibilities pulling you in different directions. You become a domain expert in something (which was probably lacking across the team) and peers appreciate it.

After they've seen that, you organically start getting invited to all kinds of more interesting projects and discussions.

[piva00]

I don't like to chime in with "seconding" on HN but I had the same eureka moment about it. I have definitely always behaved like that and it was just a natural and organic way to start in any team or job.

I got a bit shocked because I realised this behaviour repeated this past year when I changed jobs. I became a domain expert in an obscure part of the codebase and have been documenting it and sharing the knowledge for a while now.

[hinkley]

One of my 'secrets of my success' moments was realizing that one of the grind areas I reject has to do with the all of the processes of building the application. You stare at that stuff long enough and you might not know how the application does what it does, but you have a pretty good idea of where it does them.

And inasmuch as you've also improved the testing situation, you've also created a system that allows you to iterate faster, which you are intimately familiar with, allowing you to poke at the system in a way that provides you feedback on your hypotheses. Meaning you can learn about the rest of the system on your own schedule instead of being hand-fed bits of tribal knowledge (which often turns out to no longer be entirely correct anyway).

[BossingAround]

Same here. I like doing things nobody wants to do, especially when I'm new in the team.

The problem I've identified is that you're then the go-to person for the task you did in the beginning.

Example: You need to figure out how to deploy X. This is poorly documented and nobody knows how to do it.

Action: You read the code, understand what needs to be done, deploy it. Then, you document it. Finally, you create fairly basic but working automation for future deployment.

Result: Every time there's a need for redeploy, even when the code/procedure hasn't changed, you're the person the team immediately asks to do it. After all, you've automated it, shouldn't take too long, right?

[mdpye]

It happens at first. But point to the docs you wrote. Politely, but firmly, every time. People actually prefer being empowered to do it themselves, so they will pick it up, it just not our default when we're unsure.

[Too]

Except redeploying is something that always must be done last minute in a hurry because the last version deployed has a bug that will explode any moment and launch-demo is approaching, so managements blood hounds are pushing for someone who really knows how to do it to make sure it's done swift and proper!

15 minutes earlier corporate sent out an email about their values and how important knowledge sharing is! Right after deployment is done the work on documenting or automating the process is put at the bottom of the backlog since it's highly unlikely we have to do this in a such a rush again!

Make sure you have some kind of handover agreement in writing that you can point to when this happens. It sucks to be the "i told you so" guy but in situations like this you really need to protect your own back and as you say be very firm on not doing the job next time.

[tonyedgecombe]

I used to be quite happy to do all the dirty jobs that needed doing until I had an epiphany and realised I wasn't getting any credit for this. In fact it seemed to be doing my career some harm.

I stopped and refused any work that wasn't directly linked to bringing money in. Within a couple of years my salary doubled.

[kache_]

Pair with someone else and have them do it, and be explicit about your intention to share the knowledge.

[pilchard123]

Never become the guy who can fix the printer.

[hinkley]

I think in some ways this strategy, which I also employ, is rejecting the grind, rather than embracing it.

Generally I have coworkers who embrace the grind - One group happily show up to do some mind numbingly manual and error prone process, even going beyond apologizing into protecting it. That's one form of job security, but it leeches talent from the company. The other group abhors it and will try to do literally anything else to avoid going through it, including making all new things that turn out to be almost as bad (and never quite managing to get rid of the original).

Going through the grind a couple times and making sure that nobody else has to go through it ever again is acknowledging the grind, and then doing something about it.

[dopidopHN]

Important distinction you’re making.

For me the litmus test is documentation.

Make a active effort to at least explain in plain English was the grind is and what it’s is purpose, then having a stab at documenting the steps.

It’s never a one time thing. Most likely you need to do it a few time manually. You won’t get all the steps right, and automating it will likely be a tall order; otherwise it would be done already.

But like you said I encounter groups of engineers that transform the grind into a cottage industry. They don’t publish their knowledge, they are the expert on it and one of the few group that can execute on those story. It’s depressing.

And you demasked me: by making it better and more documented I want to kill the grind. Or at least offload it to another group. ( BA, users, OPS running grind.sh )

[hinkley]

Some things are just very hard to explain for various reasons. One of them is that it's painful to look at how stupid some processes are.

But like the rubber duck technique, sometimes trying to 'document the bullshit' connects some dots in your brain and lets you either avoid the most frustrating part or at least chip away at it. And sometimes chipping away at a problem gets other people to contribute as well. Hope is a powerful thing.

It's kind of a Hail Mary Play but even the 'bad' outcome is far better than inaction.

[trentnix]

Good stuff.

I've found that, as a manager, forcing the grind is also a useful tactic to get a new team member involved. Assign a challenging task that addresses a shared pain point and that requires some measure of tedium and lots of effort.

Not only will the completed work result in a new team member being accepted and respected (as you've experienced), the new team member will also develop a sense of value and ownership in the project. The faster new team members get through that period where they feel like an outsider to where they feel like they are contributing value, the better.

[russellendicott]

This strategy is common in any skilled labor trade. For example, joining a carpentry team the first thing you have to do is tote lumber to earn respect.