Join 3,380 readers in helping fund MetaFilter (Hide)


How do you get difficult yet uninteresting tasks done?
January 28, 2014 3:10 PM   Subscribe

I've noticed there are a lot of tasks at my company that are important and challenging, but not interesting or glamorous. Hiring and retaining personnel to complete such tasks seems to be a very hard problem. I wonder if there's any research or wisdom about how to approach such problems. Help me, hivemind.

What I'm talking about are talks that require enough talent or experience that you can't give them to just anyone, but that are not really interesting or rewarding enough to capture the imagination of the people with the talent and/or experience enough to complete them. So, you either get people who aren't sufficiently skilled doing poor work or brief stints of work by competent people. Either way, the results are poor.

Some examples should make the kind of situations I'm referring to clearer. I work in software development and here are three examples of these kinds of problems:

1. The build system

Our product is very complex and over time the build system has become very convoluted and brittle. As a result, this negatively impacts everyone's productivity, but it's not totally broken, so it never becomes a #1 priority to finally fix. It's hard to work on because it requires broad understanding of the unique ways in which all different parts of the product need to be built, but a lot of the work is tedious and ultimately unrewarding because people only notice the build system when it's working poorly.

2. User interface

Our product has various compelling technologies that allow us to succeed in the market place, but our user interface is fairly minimal and uninteresting. That said, there are enough things to configure that a well designed and implemented UI is important to making the product work well. Because our UI itself isn't very interesting, it's hard to attract and retain good UI designers and developers.

3. Recruiting

Hiring in software development is currently very competitive and we have many slots to fill. Ideally a good recruiter will help you find good candidates, but how do you find a good recruiter? It's actually a very hard job and theoretically you could pay a good recruiter more to keep them, but who recruits the recruiters?

The obvious answer to all these kinds of questions is to increase compensation. But in a job market where people generally make a pretty decent salary, people tend to place importance on enjoying the work they're doing and so will simply go elsewhere if forced to do such unrewarding tasks. Are there other strategies for approaching such problems? Is there even a common name for this kind of situation?
posted by Cogito to Work & Money (12 answers total) 12 users marked this as a favorite
 
I have to disagree with your assertion right up front. There are tasks that may not be interesting or glamorous to YOU, but they are nonetheless interesting problems to people in the field. For examples 1 and 2, you hire 1) automation engineers and 2) UI designers/engineers, both groups which relish the idea of starting from scratch and who want to fix things the right way.

It sounds like more that these things haven't been made priorities by management/stakeholders- and this really does show. Who wants to work on a thankless task or who is going to be roadblocked at every turn? Oh, we can't fix the build process because it would set us back a week. We can't redo this UI because our current users are used to the look and feel. If you can't hire somebody because you can't sit down with a candidate and say "we've made this a priority and need someone with your expertise to fix this problem, and we're giving you the resources to do it", then of course no one "good" is going to want to do it.
posted by thewumpusisdead at 3:24 PM on January 28 [9 favorites]


You need to hire specifically for a build engineer. There are a lot of guys who specialize in build systems. They will know what they are getting into. A poor strategy is just throwing a developer from product onto the build system - they will get bored and quit.

I don't have a suggestion for the UI problem. If it's a boring UI and you intend to keep it that way, it will be a problem hiring good UI people.

The best recruiters are burnt out engineers who work in house and are paid bonuses for finding people.
posted by BabeTheBlueOX at 3:24 PM on January 28 [1 favorite]


Increasing compensation is one option, but people with in-demand skills tend to want to do work that they find interesting fulfilling in some way, and if you're talking about "good professional salary" vs "better professional salary" there's only so far you can go in that direction.

Depending on the skills needed, here are some of the ways my institution has addressed this:

1) have part of the job be the boring task, but have some time carved out for something more interesting--either the company's priority or let the worker find a focus of interest.

2) make the work-life balance really appealing (very predictable hours, allow less than full-time work, or telecommuting). Many people with young families will trade less interesting work for flexibility and stability.

3) accept that this job will have relatively high turnover and try to find a way to make it part of a career development pathway so that you don't lose the talent.

We have one position where I work that is necessary but is a second shift job, and most of the people that are qualified for it have lots of other options with a more standard schedule. We're able to fill it by being pretty flexible with rhe schedule otherwise (the person doing it now is 80% FTE) and helping the people who do it to find other career-enhancing things to do, but we know this is a job that people usually take as a 2 year job while they prepare to do other things later.
posted by The Elusive Architeuthis at 3:32 PM on January 28 [2 favorites]


The other problem with getting to do these tasks is that there are people who would find them rewarding, but because the tasks aren't attention-getting, these people are aware that they're not going to get any respect for doing them. E.g., the dev who creates a cool shiny new feature gets a raise and a big bonus, but everyone forgets the person in the build lab exists until there's a build break.
posted by Blue Jello Elf at 3:36 PM on January 28 [3 favorites]


What would highly motivate me, someone who is doing extremely difficult, specialized work that I strongly dislike:

Excellent project management which creates clear work/life boundaries, protection from firedrills, and non-fast-changing requirements. Rhythms of time off and no worrying I'm going to have to come in the weekend.
posted by zeek321 at 3:46 PM on January 28 [2 favorites]


I think thewumpisdead nailed it. I don't really believe in boring, frustrating jobs so much as I believe in jobs that are being done by the wrong people, or being sabotaged by the company's management structure. There are people who enjoy welding and shipping boxes, so I believe there are people who would enjoy all three of the jobs you describe. I myself would probably be interested in 2 out of 3 of them (build system and recruiting). But I would hate doing them if no one would come to a weekly, hour-long meeting to fix the build system so it would quit biting everyone in the ass, or recruiting if recruiters weren't recognized as valuable team members.

Good leaders make a big deal out of tasks that aren't naturally appreciated or sexy and draw everyone's attention to how screwed they'd be if it weren't getting done. Money's always nice, too. But best of all is the resources and support you need to get those jobs done.
posted by randomkeystrike at 4:01 PM on January 28 [2 favorites]


Yep, I'm going to chime in and agree that you're looking at this problem backwards.

I come from a build engineering background and I can't disagree more with your assertion that build is "not really interesting or rewarding enough to capture the imagination of the people with the talent". I'm lucky enough to work within an excellent team of automation/build experts who come from different backgrounds - development, quality assurance, academia. You hire people like this by recognising that build attracts a very specific set of skills and interests - the one person you're *not* looking for (and a good interviewer will recognise straight away) is a substandard developer.

A good build engineer is a problem solver, an investigator, obsessed with perfecting the delivery pipeline and automating everything. They should also be able to interact with busy developers and extract just enough information from them about what the code is doing to design and implement an automated system that will fit these requirements, while also taking a step back and examining the system as a whole. Give me or my team a broken and bloated build system and we'll take great pleasure in making it leaner, more understandable and above all, faster.

TL;DR I could talk about this forever, this is my *thing* and I am willing to bet that I find it just as rewarding as any developer does theirs.

I don't know if you're doing the hiring or if this is just a general question, but one thing I can guarantee is you'll never hire people who are good at what they do if you don't make an effort to actually respect what it is they do.
posted by unbearablylight at 5:06 PM on January 28 [4 favorites]


Because our UI itself isn't very interesting, it's hard to attract and retain good UI designers and developers.

This is such a bizarre, misguided statement that I hardly know where to begin.

The type of designer who specializes in glossy, heavily illustrated brochure-ware stuff probably isn't going to be interested in this job, but that's fine; that's not the type of designer you need. The type of designer who specializes in usability, structure, and workflow is what you need, and you should have no trouble at all finding and retaining that sort of person provided you can give them the support and the power they need to do the job properly -- which often involves much more substantial changes than just colors and icons and superficial rearranging of widgets. The best way to drive away a good UX/UI person (and this happens a lot, especially in shops where the existing UI was "designed" by the developers) is to let the coders naysay everything they suggest because "that would take too much development time", or to otherwise limit them to pixel-pushing and picking around the edges of the real UI issues.

Basically I'm saying the same thing unbearablylight said about build engineers, but about UI. If you don't understand and respect what these people bring to the table, they'll leave and go work for someone who does. Your question gives the strong impression that you and/or your company think of these tasks as mostly-optional afterthoughts. I'm pretty sure that's the main source of the problem.
posted by ook at 5:47 PM on January 28 [3 favorites]


Let's say that you, Cogito, are correct in saying that your job has boring but important things that makes retaining smart people difficult.

Can you change the ratio? If I only have to do boring things 20% of the time and can work on interesting things 80% of the time, then I wouldn't mind so much. Even if those interesting things had nothing to do with my job. I would stick around longer for the perks of a job where I feel that I am growing.

If I am a UI designer working with a boring UI, are there opportunities for me to build my own thing? Will my ideas about marketing be accepted? Can I plan company events? Can I learn how to code in Python like I always dreamed? Will you send me to interesting conferences?
posted by jander03 at 7:11 PM on January 28


Ah, technical debt. Break the drudgery into small tasks and put the talented, experienced people on a rotation so they spend a few days/month at it. While most of your engineers dislike this maintenance work, they will all acknowledge the need, and it's not so bad if they're not doing it full time.
posted by qxntpqbbbqxl at 12:59 AM on January 29 [1 favorite]


At the company I work at, we have one week set aside every six months to optimize parts of our system. Optimization can mean making some database operation run 10% faster or it can mean cleaning up the build process so that it becomes less cumbersome on the support team. Usually optimizations aren't "glamorous" from an outside perspective, but you better believe that when somebody makes your build go from over an hour to ten minutes you're going to stand up and cheer for that person! This is, IMHO, a culture thing. You need to change the company from the top down to value doing important but unsexy optimizations every now and then to keep things running smoothly, and to value your engineers' opinions on these matters, because they're the ones who will appreciate them.

I also think build engineers/devops and UI developers are traditionally undervalued in many organizations. Probably because most CTOs don't come from the devops or UI world, so they don't appreciate why those people's jobs are so important. I think this is a learning experience for your organization, not a quick-fix. Your company needs to learn to think of this "boring" work as important work and then hire people who are passionate about it instead of accepting that it's dull and uninteresting and that's why people are quitting.
posted by deathpanels at 5:39 AM on January 29


Thanks for all the responses, people. I agree with most of what you're saying. Unfortunately I am not in charge of hiring or staffing, but these are good approaches that I will try to message up the chain.

One thing that I'm still a little stuck on is the UI part. I'm actually fairly passionate about user interfaces myself, so it's really not that I don't appreciate the craft or expertise involved. I just think it is legitimately a pretty uninteresting part of our product because the UI solely exists to do configuration. The way customers actually use the product is as middleware supporting other applications. I've done UI and enjoyed it before. When I am occasionally called upon to do a bit of UI work these days, it is intensely tedious because it's not an interesting part of the system.

As opposed to the build system which would excite the right build engineer, I really do think our UI is just not that interesting a thing to work on for people who are actually excited about UI. Maybe the thing is that what we need is someone who deeply understands the product and how users would interact with it, but happens to be willing to do the UI work. The difficulty here is that anyone with deep enough product knowledge tends to want to work on the core of the product rather than its configuration UI. That, I guess, is the tricky part with that problem.
If I am a UI designer working with a boring UI, are there opportunities for me to build my own thing? Will my ideas about marketing be accepted? Can I plan company events? Can I learn how to code in Python like I always dreamed? Will you send me to interesting conferences?
Maybe. Doubtful. Yes. Yes. Maybe.

Good ideas, all. Thanks for giving me more to think about.
posted by Cogito at 10:59 AM on January 29


« Older When trying to restore a FreeA...   |  This is my first question here... Newer »

You are not logged in, either login or create an account to post comments