Share the Interesting Work

  • Comments posted to this topic are about the item Share the Interesting Work

  • I give new starters the small support items at first, which gives them time to touch a lot of areas while coming up to speed. They'll get a chunky project after they pass probation, they are told this on day 1 (so they have something to look forward to 😉 ). Even for a seasoned developer it can be overwhelming to be given something big and "fun" to do right off the bat - most people I know would not feel confident with this anyway until they have learned the company domain and architecture.

    I would certainly not give someone daily repetitive work at first, although that being said with the automation capabilities these days it has been a long time since I've encountered work of this nature myself either.

  • Completely agree. Had never thought of it in the sense you present of "job A" v. "job B".... that's a nice way to think about it.

    Another thing I've found is that this data space is so large, there is a need for a lot of different and broad skill sets. The person hired for a given skill set doesn't always end up enjoying (or being particularly good at) what they were hired for, thus meaty tasks in that space never materialize. Most of the time however, they have a skill set that piques their interest and provides value to the organization. Giving them low impact tasks until you figure out what that is can then allow you to pass on the interesting stuff. The benefit is the employee appreciates you took the time, they're super productive because they're interested, and things get done that we may not have realized were needed before they came on board.

  • I actually just hired a new team member a week ago. This article really talks to me in my current seat for sure.

    The purpose for the new hire is exactly what you explained. I'm getting bogged down with a lot of those tasks that keep the business going and it's taking away from the real big stuff that is going to drive a lot of value. So, the idea is to help share the workload so I can focus on those bigger things.

    But, the approach I've taken in communication thus far is that of sharing the workload equally as a team. Realistically, I can't stop what I'm doing until the new guy learns the business and the data. Even then, we are a team, we need to support each other as much as possible. So, I really want us both to focus on doing what I was doing as well equally play a big role in the big stuff that will drive major value for the business.

    No one wants to get stuck at the back of the bus. I think it's good for everyone to feel apart of the good stuff.

  • I would call the tasks production support and new development. New development is fun, production support, not so much. Assignments for new development can be considered a reward for previous good work. I would be careful about giving it to new team members. Production support is also a great way to learn an operation, a natural place to start.

  • "hiring to support growth" - what is that?

  • Hopefully in the next year I'll get a backup DBA, if / when that happens, I'd like to think I won't stick them with the boring parts.

    But, considering the position (including mine) is primarily a production support role, with some developer assistance thrown in from time-to-time, it does tend to be mostly boring bits.

    I'd think starting the person out with getting them familiar with the environment, the procedures for doing things, etc. We'd probably split the servers down the middle as said hypothetical person gets more comfortable so that we each have "our" servers to manage, monitor, and maintain.

    The boring bits, like applying OS updates and such, would probably be traded off from month-to-month so we each have 6 months out of the year (we patch on Saturday mornings, so it's working on the weekend.)

    "Fun" stuff (like at some point I want to roll out SQL Monitor) I'd find a way for both of us to work on it together, so that we both get something "interesting" to work on.

  • Currently I work in a very small company so being the DBA is only part of my job remit.

    In a previous company I had issues with two people who had 'knowledge is power' syndrome so shared very little. Ultimately both just walked out without giving/working full notice. This caused some short term issues but the work environment improved dramatically. It also proved they were not as indispensable as they though!

  • It's an interesting debate and, as you say everybody is different

    Personally, I like to share the work such that any member of the team is interchangeable (assume smaller team)

    I've seen people hog work (poor delegation and an element of job paranoia) and I've seen people try to delegate everything (mainly down to laziness!)

    Interesting work is also subjective

    For example, some people love producing documentation; personally, I don't really enjoy this

    In that instance I would probably give the individually more documentation but ensure that other team members (including me) do some as well

    In reviews, I used to have an assessment with categories such as documentation, testing, coding, presenting, project management etc. The ask them to rate their highest to lowest preference along with why

    Then pool them all together and work out how to allocate work from there

    No matter what people say, for most people having a job they enjoy is the most important thing, so sharing interesting work is crucial

    - Damian

  • All team members should do both types over time. Don't split up tasks too small but do break down what you can. Also, automate as much as possible.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Having been on both sides of this coin, I don't like to assign based on interesting vs. boring / easy vs. hard.

    When someone starts, they may be the best DBA, developer, whatever. They may have talent and brains up the wazzoo. What they will never have, however, is an understanding of the organizational schema, the business rules or the environmental politics. I like to see new hires given assignments that ramp up the understanding or the big picture as quickly and thoroughly as possible.

    When I started my latest position, I was in no hurry for interesting. I wanted everything that would give me a sense of what I was dealing with. To make a music analogy, it's not that I couldn't "play scales", I simply did not know which "scales" were being used for the selections. Learn scales first, rock-star improvisation later.

  • Very eloquently said. Agree 100%.

  • There is a definite skill in assigning appropriate work and keeping staff interested.

    There's also a skill in working out their strengths and weaknesses, how best to capitalise on the strengths and whether and how the weaknesses can be addressed

  • Sadly, in most IT shops it's the application developers to do most of the "interesting" database development work, and even the most senior members of the DBA team perform post-deployment damage control or at best play the role of traffic cop.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Chris Wooding (11/18/2016)


    "hiring to support growth" - what is that?

    Here's my take on the meaning of "hiring to support growth": It's having a project already funded (not just an idea, but work that executive management has bought into and is ready to implement) that the current team can't absorb either due to their existing workload or due to skillset.

Viewing 15 posts - 1 through 15 (of 20 total)

You must be logged in to reply to this topic. Login to reply