The Right and Wrong Ways to Delegate

Written by Azat Mardan

My main jobs are software engineering and writing. They are crafts and as with many crafts they are harder to delegate. Think mass produced car vs. designing a car and the factory to mass produce it. Software and books are scalable because they can be replicated infinitely without any loss, but the actual act of writing them is a creative hard-to-scale process.

Over the years of writing software and books, I’ve been learning to identify and delegate some repeatable tasks. I learned that the right way to delegate is to find a repeatable task which you know a) cannot be easily automated b) needs to be performed 100+ times or 2+ hours, and c) straightforward to document and explain.

There’s a cost of review. Do not skip reviewing the end work and either fixing mistakes yourself or sending it back for a re-work (in this case always review again). Reviewing helps not only to make a better product but it’ll give you the confidence in your product and your team (or not but then you at least know and can fix issue later).

Some leader say, never delegate things you are not willing to do yourself. It’s B.S. Everything is situational. I delegated things I dreaded doing and they got done. If I didn’t delegate them, they could have taken longer (procrastination) or would have never materialized at all. Done is better than perfect in this case. However, running at least the first 3-4 times through the routine will help you greatly in writing instructions and standard operation procedures (SOPs).

Do not delegate to perform things which do not make sense financially and don’t be cheap on things which will generate revenue.

Delegate at things you think you are okay or good (even worse), but in reality you suck at. For example, a lot of programmers think they are good at design and their confidence leads to terrible websites, book covers and software which prevents them from making more sales.

To summarize this post, do:

  • Delegate to get better supplemental skill to your own and don’t be cheap, e.g.,design
  • Change process to eliminate or automate, e.g., create a self-service instead of customer support or use AWS RDS instead of maintaining a database
  • Delegate repeatable tasks by having detailed easy to follow instructions
  • Always review before the final step
  • Delegate scary for you tasks but only after you’ve done them a few times and they’ve stopped being scary
  • Constantly re-evaluate, i.e., look for opportunities to change to a cheaper provider or simplify the process
  • Delegate to get a second opinion, e.g., tech review, copy editing

Example of things you probably shouldn’t be doing yourself:

  • Design (for programmers or writers)
  • Scheduling appointments by phone
  • Fixing formatting, links, code, fonts, etc. in MS Word, Markdown, and other formats
  • First pass at creating captions and transcriptons
  • First pass at video editing
  • Spinning up and maintaining your own database instead of using BaaS
  • Spinning up and maintaining your own servers (virtual machines) instead of using PaaS
  • Importing, exporting, enrolling instead of automating
  • Submitting to any forms: job boards, conferences (request for proposals), clients, etc.
  • Posting to social media
  • Deploying code instead of having CD
  • Testing code instead of having CI

Do not delegate (or automate) things when one or more applies:

  • It will faster for you to do it and it’s not a repeatable task then to train and review (review can take a long time)
  • It’s a last step review
  • It’s hard to describe (means creative)
  • It’s a core function for you
  • It requires extremely high standards which will cost you too much or hard to find people to do
  • It’s marketing/sales