How to deliver more output?

This is the kind of question where it's tricky without your company/level and more context in general - The expectations around productivity and how to achieve it will vary wildly based on those 2 factors.

That being said, here's some of my advice in a vacuum:

• [Masterclass] How To Write Better Code Faster As A Software Engineer - General advice on how to write more code in the time you do have
• [Masterclass] How To Learn Quickly In Tech - It seems like the learning phase is taking you too long, so here's our advice on how to compress that.
• Fighting Perfectionism As A Software Engineer - Another possibility is that you're "over-learning" before jumping into the execution. I've seen this with many software engineers (generally stemming from a lack of confidence in their own ability and very large fear of unknowns), and there's our advice on how to overcome that.

...not delivering as much results as my senior colleagues

Unless you are also senior level, that's perfectly fine! And even if you are senior level, that's fine if you're onboarding or something. My advice here is to turn this into learning and inspiration: Observe how these senior folks operate and see what you can emulate from them into your own working style. A lot of my growth at Instagram was mirroring a very talented iOS tech lead on my team, absorbing their communication/leadership style.

How to strike a balance?

At the end of the day, work backwards from your goals and then do whatever it takes to meet those goals. For example, if you have a task estimated at 2 weeks, then you obviously can't spend 1 week just learning things to do the task. After 1-2 days of learning/planning, you'll need to jump into the execution to have a real chance of completing the task.

Some questions to reflect on which may help:

• Do you have clarity on what you should work on? (i.e. what are you trying to deliver?)
• What do your colleagues/manager think about your output? Has anyone voiced a concern?
• Look at the output of your colleagues -- looking at their PRs/code descriptions, how much context do you think they had when they made the change? (we talk about learning a new codebase here) This will give you additional data on where you sit on the "learning vs doing" spectrum.