Delegation is never really well taught. However, it is an activity that has a lifecycle that starts before you give somebody a task, and ends after they give you back the resulting work product.
A "task" is often hard for software engineers to grasp because they think in terms of units of coding activity, like handling a ticket in a Sprint queue, but a task in a business sense is generally a larger activity than that.
For example, think of a work project. One of your responsibilities as a manager is likely to break that project down into smaller pieces. If you keep breaking these pieces down, the atomic-sized piece is a "task", which should map more or less onto the work (some sequence of actions) a single person can accomplish in a short period of easily projected time.
However, tasks also come with a kind of protocol, you must define the task, the expected projected delivery time, the success criteria, and then know how to integrate the delivered work back into the larger project.
Very important, you have to try to carve the task out so that it can be accomplished by your staff given their capabilities, and if there are elements of that task that are outside of those capabilities marshal resources from elsewhere to fill in the gaps.
Here's a semi-technical notional example:
Project: Integrate with upgraded vendor supplied data source.
You might break this down into tasks one of which might be some database work to be accomplished by your Database person "Jane". The task might be "prepare database to receive upgraded data source".
Jane receives this task, thinks about the sequence of actions she has to do to accomplish this task, then goes about doing them. Perhaps she's unclear about one of the tasking requirements, and decides instead of dropping the old table, or renaming it, she'll put the new data into a table called "new_vendor_data".
Jane finishes the task in a day or two, and lets you know she's done and that the new data can go into the "new_vendor_data" table.
Your job is then to integrate this information into the project, which in this case might mean you go to "Peter", who's working on the ETL from the vendor's API and let him know now where to put the data, then you go and update the database and API documentation, and think through any other places where this information is needed.
The lifecycle of the task is now complete.
This is a really trivial example, but the method for how it works translates into non-technical fields. You can build tasks with your marketing staff member and see them through their lifecycle as well -- defining success criteria, and such unique to each discipline.
At larger scales, defining these tasks, and coordinating their lifecycles becomes a pipelined and multi-threaded discipline, and being good at it is part of what makes one a good manager and an efficient and effective team. Very good managers view this as a service they provide their staff that keeps them running with full work pipelines and no downtime or uncertainty.