But my problem is that similar to memory leak, I'm facing with the time leak. I spend a lot of time on meetings, or provide support to systems that nobody else knows about. Some of the I wrote, some of them I just get known and I left alone.
It's hard to get rid of that legacy baggage, so that I think a "fresh start" will be the only option to get some air - but it's almost impossible to stay in one company and have a fresh start.
If you are for a long time on one company: How did you survive? How do you optimize your time?
If there are aspects of your job, like the legacy systems you are talking about, that only you know about, you need to start the process of documenting those systems so that someone else can take them over.
This isn’t just raw documentation, but you need to build the “how to” guide for them.
Focus on one system first and then present it to the CEO and tell them that you have written up this function because you want to help remove the key person risk of knowledge being only in your head. Also tell them why you are doing it (you want to grow further into the company to bigger opportunities).
As a business owner, I can tell you that this sort of initiative is greatly appreciated and valued.
Once done on a hat, get it to a more junior engineer and help them get in control of that part of the job.
Then repeat as many times as needed.
Even if you don’t find someone to take over some aspect immediately, doing this is very therapeutic anyway and also means that when the opportunity does arrive for you to hand it over, you can!
This will also declutter tour mind and help give that “fresh start” you are after as you won’t have to remember everything.
Not all will react well to that, but those who are also looking to grow in the org will see there is an opportunity to grow some valuable expertise, with you as a mentor.
If that's the case, still write it all up. Tell them where it is. And leave. (Because the problem you're feeling is not fixable within that company.)
You have to intentionally give away ownership of the things you made and entrust other people to figure them out as well as you did.
Sounds like you should be telling us how to survive for a long time in one organization.
I don't get what the problem is - Meetings? (everyone has meetings). Being asked to support legacy stuff?
1. Meetings. Senior people have more meetings than junior people. Technical leads have more meetings than individual contributors. As you grow in an organization, you have more meetings. If you're an introvert, that's draining. If you get your dopamine hits from making things work, that feels like your time is being wasted. But in fact, you are more valuable to the organization. It's just less fun for you.
2. Being asked to support legacy stuff is almost inevitable, especially if you wrote it and it's important stuff. But if it's important stuff, the organization really needs to increase their bus factor on that stuff.
Also, supporting legacy stuff is often less than a full-time job. It means you can try to work on something else too. You just get interrupted, which destroys what you have loaded into your brain and kills your momentum. It's annoying, it's inefficient, and it would be better done by someone more junior.
The amount of helpfulness you show when people ask your questions will determine the amount of new questions you get :-)
You will get someone’s baggage anywhere you go. A new job will pile it on fast, but an old job you have to become the decider of your fate and workload. Just start saying no when it gets unattainable.
1/ 30m meeting. Everyone who wants to make a meeting with me must via the invitation ( send to my calendar ), and the meeting duration must be 30m ( or less than ).
2/ Document by priority. I track the top 3 problems by their frequency and make the document ( troubleshooting ) next week. Automate your work first, after that, do delegate.
3/ Keep the fire burning. I mean you have to find your top 3 reasons, why you are still here, and work for the company. If you tried but can't find them, leave.
Hope it can help.
If a company is big enough you simply get too detached from your previous projects, you might be asked for help here and there but the distance (physical, mental and managerial) will make it harder and harder to actually be productive.
The other type of company understands that it is not sustainable to keep a system maintained by someone with no commitment or dedicated time and will insist on a proper handover to a new owner.
For time management, there isn't any silver bullet, and we just have to work around hard constraints. Btw one solution might work for you, but not necessarily.
I'd agree. I'd love to say this to people. I'm in a similar position in that I need to offload legacy production code to my successor, but due to successive company policies of cutting staff to basically 1-person-1-job I have literally no-one to hand over to. It's going to get messy...
Until the migration is eventually fully complete (which can really drag on forever in some places) they will be in a way worse position to argue for other people spending time on understanding it. Basically no one will be motivated in doing so.
