Sure. On an individual contributor level: Right out of college, I tended to prefer building things on my own, rather than using existing patterns or frameworks

Sure. On an individual contributor level: Right out of college, I tended to prefer building things on my own, rather than using existing patterns or frameworks. I did this partly because I wanted to learn the "fundamentals", and partly because I was arrogant (or stupid, some probably said). One day, a senior developer gave me a book on design patterns. I was floored. I started applying them and found the quality (and maintainability, reusability, etc) of my code increase tremendously. Over time, others have given me more tips on improving my efficiency. From something as simple as learning keyboard shortcuts and customizing an IDE's UI, to unit testing and handy shell scripts, I found myself saving a lot of time. Of course, you may be doing all of these things already, in which case, you may already have a pretty optimized work technique already. On a managerial level: I'm a believer that if you put the right team together, 1+1=3. So my value has shifted from being an individual software developer to someone who can put together teams of developers insanely smarter than I am, then remove all the roadblocks out of their way so they can build great things. I still write some code, but while my value as a developer has dropped tremendously, my value in managing a team of developers means our overall output is greater than the sum of our parts. In other words, I increased my "value" by becoming a manager. Of course, that kind of a role change is not for everyone, but that's what I did. Another example is one of prioritization. Sometimes it's only realistically possible to do X units of work a day (let's say 10 units), and sometimes a person is asked to do Y units of work a day (let's say 30). That means 20 units aren't going to get done; it's just not possible. Trying to squeeze in more would result in a lack of quality (due to lack of sleep, exhaustion, etc). So what can one do? Do the most important 10 units first. It sounds pretty obvious, but in the heat of the moment, I sometimes found myself wanting to do the 10 easiest units first, not the 10 most important. Proper prioritization made a big increase in the quality of my output as well.