At times, all of these things are interrelated, but it's most important to understand the source of the problem.

If you set deadlines without the consent of, or validation by, your brilliant technical programmer, they may not be realistic. Moreover, they may not be accepted as real deadlines but merely as estimates. In the mind of a programmer, there's a huge difference between estimates and deadlines.

If your programmer is setting his own deadlines, you may need to challenge him to become more accurate in his estimation and more liberal with buffer time. You may also want to challenge him to treat time as a design constraint rather than a schedule inconvenience. Again, you will also have to be clear with him about the difference between estimating how long something will take and committing to a specific delivery date.

If the deadlines are realistic but he merely lacks the will to meet them, you may have a bigger problem. Brilliance alone doesn't make for a productive employee. There are plenty of geniuses who are significantly underemployed because they lack the will to do more. If this is the case, your programmer may be able to deliver only limited value until he finds his own motivation.

This problem is most easily dealt with if it is a misunderstanding about the relative priorities of schedule, budget, feature set and quality. At the outset of any assignment, you and he should explicitly rank each of these priorities from top to bottom. Remember that as a manager, you can't demand that all four be first priorities. If deadlines are the most important success factor for the project, he needs to know it and adjust his work strategy appropriately.