There are quite a few for me personally. But a few of the top ones:

1. When I am helping the team or especially an individual succeed at a task and move forward. It is when you see that lightbulb go off in someone when they are learning something new, or have been struggling and you can help them find the path to solving it. What is rewarding here is it is impossible to always know the answer, but the person working the problem usually is the most likely person to solve it and so just through talking it out, working together a little, asking questions and challenging them they find answers most of the time which is rewarding to me. Mentoring to me is probably one of the most fun aspects, and rewarding. This can also be the most frustrating situation when you are dealing with someone that is a negative individual and struggles to see that issues are just opportunities to learn or improve.

2. Finding a win-win solution to a task or issue. Whether that is an engineering challenge that has been raised, or it is a people or client issue where you find a solid win-win. Those are great, cause they don't happen everyday, so they are rewarding when they do.

3. Seeing the product actually making a difference, knowing choices we made, things we did impact people. In the place I am now, that is patients being helped given we are in healthcare, but in the past it has been saving a client a particularly large sum of money through our products or services, or making the client money based on the same. I think a lot of engineers (especially newer engineers) miss this aspect because they get so hung up on the technical details or implementation they don't understand the product itself (yes they can tell you what it does but they don't truly understand it). One of the key things I always strive for is making engineering aligned with the client, because when you can feel the pain the client feels, feel the benefits they feel, you will make better choices and be a better product engineer. Isolating engineering from the client/product is always a mistake IMO.

The theme here is I do love the team building and people side. My viewpoint on leadership is that a leader is the support person for their team, they are in front defending their team, leading the team, take responsibility for the mistakes but passing on the credit to the team and at all times support the team regardless of what that entails. If I need to get people food cause they are tackling a problem, then that's my job, if I need to get them the right tools to get their job done properly or make it easier, that's my job to find a way to get them what they need.

Don't get me wrong, I am a die hard and love solving technical problems and generally prefer to work on product, but as a CTO or similar you have to pull back and do what the organization needs at the stage it is in. You should always drive engineering excellence, but you shouldn't be driving day to day decisions/execution unless the company is very small and you are still having to play architect, coder etc. Once you have team leads and teams, you should be pulling back and setting direction and standards but not dictating implementations etc. That is IMO where most people struggle and fail to grow, which leads to them being replaced by a more experienced CTO.

As with everything, there are exceptions with some CTO roles, but IMO this is the way they should all be.