If we end up in a project with too little test coverage, our strategy is usually to then formulate unit tests before touching old code.

So, first you figure out what the hell that old code does, then you formulate a unit test until it's green, then you make a commit. And then you tweak your unit test to include the new requirements and make the production code match it (i.e. make the unit test green again).

I am already seen as the "automated testing guy" on my (separate) project, and it doesn't really look like I'm that much faster than anyone else.

This isn't about you being faster, as you write a feature. I mean, it often does help, even during first implementation, because you can iterate much quicker than starting up the whole application. But especially for small applications, it will slow you down when you first write a feature.

Who's sped up by your automated tests are your team members and you-in-three-months.
You should definitely push for automated tests, but you need to make it clear that this needs to be a team effort for it to succeed. You're doing it as a service to everyone else.

If it's only you who's writing automated tests, then that doesn't diminish the value of your automated tests, but it will make it look like you're slower at actually completing a feature, and it will make everyone else look faster at tweaking the features you implemented. You want your management to understand that and be on board with it, so that they don't rate you badly.