Delegating Is Not Just for Managers

written by erik dietrich for infragistics .

i remember most the tiredness that would come and stick around through the next day.  after late nights where the effort had been successful, the tiredness was kind of a companion that had accompanied me through battle.  after late nights of futility, it was a taunting adversary that wouldn’t go away.  but whatever came, there was always tiredness.

i have a personality quirk that probably explains whatever success i’ve enjoyed as well as my frequent tiredness.  i am a relentless diy-er and inveterate tinkerer.  in my life i’ve figured out and become serviceable at things ranging from home improvement to cooking to technology.  this relentless quest toward complete understanding back to first principles has given me a lot of knowledge, practice, and drive; staying up late re-assembling a garbage disposal when others might have called a handyman is the sort of behavior that’s helped me advance myself and my career.  on a long timeline, i’ll figure the problem out, whatever it is, out of a stubborn refusal to be defeated and/or a desire to know and understand more.

and so, throughout my career, i’ve labored on things long after i should have gone to bed.  i’ve gotten 3 hours of sleep because i refused to go to bed before hacking some linux driver to work with a wireless networking usb dongle that i had.  i’ve stayed up late doing passion projects, tracking down bugs, and everything in between.  and wheels, oh, how i’ve re-invented them.  it’s not so much that i suffered from “not invented here” syndrome , but that i wanted the practice, satisfaction, and knowledge that accompanied doing it myself.  i did these things for the same reason that i learned to cook or fix things around the house: i could pay someone else, but why do that when i’m sure i could figure it out myself?

in more recent years, i’ve revisited this practice.  i’m in business for myself now and absolutely maxed out with demands for my time.  i coach software development teams.  i make videos for pluralsight.com .   i blog 3 times per week and sometimes more.  and i still try to find time to write code and do some application development work when i can.  juggling all of these things has caused me to economize for time in all possible ways, and i’ve read books like getting things done , the 4-hour work week , and the lean startup for ideas on how better to manage my time.

a consistent theme of being more productive and more successful is to be selective about what you do versus what you rely on others to do.  i could spend 4 hours wrangling the garbage disposal, anticipating the satisfied tiredness the next day when i finally emerged victorious… or, i could spend those 4 hours as billable ones, coaching a software team, and hire someone better than me at fixing disposals to come and fix the disposal.  it’s hard to ask someone to help you for a task that you know you could do yourself, but coping with and overcoming that difficulty is the stuff leadership is made of.  it’s the stuff success is made of.  people who become tech leads and architects and do well in these roles are those who learn and understand this lesson.

the closer the task to your area of expertise, the harder it becomes to apply this lesson.  it’s one thing for me to hire people to do plumbing tasks, but quite another for me to hire someone to improve the performance of my website or build me a nuget package.  and yet, i have to because i simply don’t have time not to.  the field of software development is growing exponentially more specialized, which means that i need to learn the lesson, “just because it’s code doesn’t mean i’m the person for the job.”

it’s in this context that i appreciate the work done by infragistics.  i can’t tell you how many times i’ve implemented some kind of grid in some gui somewhere and hand-rolled logic for sorting and filtration.  i can’t tell you how many times i’ve thought to myself, “okay, next up, using some kind of text box template so that the user can click and edit inline.”  this may have made me a better programmer through practice, but it was not a valuable use of my time.  practice and learning are activities unto themselves, and it’s important to set aside time to do them and to come to understand the problem being solved by the tools that you use, but when you’re on the clock and getting things done, you should not be solving those solved problems.  let experts solve them for you while you solve business problems.

it took me years to learn this lesson and then to start applying it.  learn from my mistakes.  let the experts in their areas help you so that you can find, build, and profit from your own area of expertise.