Bored people quit (2011)

http://randsinrepose.com/archives/bored-people-quit/

by _qc3o • 12 years ago

159 37 12 years ago

Seems pretty on target, though it may be too late by the time you notice a change in their daily routine (the first bullet point), as this may indicate that they've already begun going on interviews. Perhaps it's better instead to ask the employees periodically for their feedback, rather than wait until you notice a bad sign.

ogreyonder• 12 years ago

And when they give you their feedback, listen. They may only tell you once.

Spearchucker• 12 years ago

Or, if they worry about getting laid off, they may not tell you at all.

namenotrequired• 12 years ago

I think he means a change in routine caused by them simply not enjoying the work anymore, so they come late or leave early or take long breaks etc.

And yes of course digging for signs doesn't beat asking by far. Ideally performance reviews can fill this role (sadly, at least here, too often those are treated as just a legal obligation where the only practical goal is to discuss and most importantly document some complaint, no matter how small, so that just in case the company later decides to fire the employee, they already have a file with "evidence" that you were underperforming for a long time).

nairteashop• 12 years ago

I've gone back and forth on whether managers should code and my opinion is: don't stop coding... Over time it means you'll have a harder time talking to engineers because you'll forget how they think and how they become bored.

For me, this is the money quote. Like rands, I've gone back and forth on this over the years as well, but I do strongly believe that you cannot effectively manage a team if you do not understand what it is that they do, at least at a high level.

You don't need to be as good at coding as the engineers who work for you, but you must know enough to empathize with them, and to help mediate dead-locked discussions.

I'll admit that there are exceptions, and effective s/w managers who can't code do exist, and I'll also admit that finding such managers is probably not a scalable task, but I feel it's something that every company should strive for.

BSousa4• 12 years ago

I'm borderline if managers should code or not, but as soon as you get to manage a team, and the job doesn't require it, do stop coding!

It is not your job anymore, and if over the next 5-10 years you start having a hard time talking to engineers, than maybe you weren't that good of a programmer to matter. Frameworks change, but general programming knowledge doesn't. Even if an engineer says something like "In rails 7, you can't splice the header from the body of the message stream sent over airsockets" as an excuse to not deliver and if you think it is important for the rest of the project, you should easily check google to understand what is going on, but you don't need to know rails 7!

seanmcdirmid6• 12 years ago

Once you stop programming, your skills will degrade like a musician who stops practicing, you'll eventually forget what its like to be a programmer like a parent forgets what its like to be a teenager. You'll lose your ability to connect with programmers, but hopefully by that time you are managing managers who manage programmers, or something like that.

Google can't fill these information gaps, and any manager who trusts Google over their engineers is probably a toxic one at that.

wheaties• 12 years ago

Managers need to code. However, managers need to manage first.

"Management" doesn't always mean tell people what to do (it rarely does if you're doing it right,) Managing could mean protecting your team from all the boring shit work, it could mean making sure that your team's goals are in sync with other teams, it could mean making sure that people are prioritizing their work around what needs to be done rather than what would be fun to do, etc.

sirmarksalot• 12 years ago

I would disagree that general programming knowledge doesn't change. While most of the ideas currently on the forefront of software engineering were invented decades ago, many of them have only hit mainstream very recently. While pure functional programming isn't used very often on large projects, current best practices prefer a declarative functional style whenever possible.

While a "for" loop may not have changed, someone who has only coded C++ may not understand why it's often the wrong way to iterate over a collection in modern environments. They might not understand why you'd use function parameters instead of inheritance, or lots of tiny single-method classes instead of one class that handles every aspect of a data type.

While these may seem like simple implementation details, they can lead to different approaches to problem solving, and conflicts over programming style that you might need to mediate. For example, if one of your group's goals is test coverage, then it would be helpful to have done some TDD, and know what characteristics are more or less conducive to testing.

While none of these ideas is brand new, there are a lot of teams that have only recently started embracing them, and a manager who hasn't kept up is probably not going to be a very good fit on a team that has.

watwut• 12 years ago

More the just frameworks change. More importantly, if you did not coded for 10 years, it is only that what you remember is outdated. It is also that what you remember is an idealized high level version of what it really was.

That kind of manager that bases his decisions on quick google searches without understanding whole system is the worst kind of manager. If there are trade offs involved and possible bad consequences in the context of your database, your search will ignore that.

Ultimately, "In rails 7, you can't splice the header from the body of the message stream sent over airsockets" is not level of detail non-coding manager should deal with. That is for the rest of the team to either propose other solutions or make it work with the rejected one.

The managers role is not to make technical decisions, his job is to ensure that other team members will help that "excusing" engineer to find solution. Managers role is to detect engineers seem to need help too often, but he is looking for pattern there - not one quick search over what might be controversial issue.

lmm• 12 years ago

I don't think a manager should be the one deciding deadlocked decisions. Managing a team is a full-time job, you don't have time to keep up with the codebase without compromising one or both. Promote someone you trust to tech lead and give them final say on technical decisions while they remain a coder, and concentrate on being the interface between your team and the company.

legacy2013• 12 years ago

This article really hits the nail on the head. my first job out of college I was working for a big firm where I was bored. I kept getting told I was an exceptional engineer and was on a fast track for becoming a senior engineer. I was barely twenty two. I moved to a new job six months later where I was constantly challenged and learning new things and I couldn't have been happier.

dlhavema• 12 years ago

i have a similar story, my first real company after college was a great place when i started, and then it seriously stagnated... i stayed 5 years in all, but in the last year i had no active project, just minor maintenance tasks... people were also getting laid off left and right as well..

karlmdavis• 12 years ago

His post from today, "The Diving Save" [1], is also quite relevant to this: how do you keep someone, once they've started to check out?

[1] http://randsinrepose.com/archives/the-diving-save/

Bahamut• 12 years ago

One way is to give more interesting work and/or work that is a natural possible progression in the employee's career. That technique helped my company woo me over into staying, along with a modest salary bump (although I was seeking much more - career progression mattered a lot to me).

From a personal perspective - I've turned to the quit mentality due to boredom after my first job after not having enough to do, and at my second job I converted over after immense deadline pressure for half a year when combined with significant underpayment (extreme frustration).

The best pre-emptor would be to be proactive in addressing these problems. If your company is exerting too much pressure on developers, then you probably did a poor job hiring enough employees or incentivizing them enough - I'm looking your way startups.

jecxjo2• 12 years ago

If your company is exerting too much pressure on developers, then you probably did a poor job hiring enough employees or incentivizing them enough

I've noticed this to be a huge issue when it comes to large companies who try to defend the situation saying we are "lean" and reduce forces by "cutting the fat." I'm currently in a situation where I've become "The Guy" for two entire product lines and its gotten to the point where they keep tempting me with "You'll be on Next Generation SOON". But soon, in my eyes, will never come because I'm a single Engineer maintaining hundreds of thousands of lines of code, code that deals with an OS no one else uses, in build environments no one else uses.

What I use to think of as job security has become a pill that induced boredom.

xtrumanx• 12 years ago

I would be less inclined to be saved with a dive since all I'll be thinking at the back of my mind is that I'm (to quote the article) "working at a company where folks apparently need to resign in order to have a real conversation about their roles.".

austinz• 12 years ago

I left my very first job because I, too, ended up bored and learning almost nothing. But I do remember that I was too scared to bring it up, because I thought there existed a possibility that the (very small) company might preemptively let me go, which would have screwed me up quite a bit. The most logical thing to do, in my mind, was to not let anyone know what I was thinking until I had signed a new offer letter and was handing in my two weeks' notice. Sort of like the prisoner's dilemma.

Was I wrong? (I hope I was wrong.) My manager was a great guy, and definitely not unreasonable. But at least from my perspective at the time, the stakes were so high. Was this just some stupid fear that doesn't actually reflect what happens in real life?

JackMorgan• 12 years ago

I've seen it happen: someone getting fired for pointing out how they'd like more work and are bored.

I think you just have to leave with an offer in hand, saying politely no to any counteroffers. But, always remember, move jobs like Tarzan, with one hand in the next vine before letting go of the current one. (Have an offer before letting _anyone_ know at your current job).

That being said, I encourage my employees to let me know if there is anything I can do _before_ it gets to that point. I believe in letting people move around between roles, jobs, and teams if it helps them engage better. But I'm a pretty private guy about not being happy at work, so I'm not even sure I'd take me up on it unless I framed it in such a way like "boy this other team is doing some cool stuff, can I help out?"

Something about the asymmetrical power relationship makes me very careful to not harm myself with my own actions: and having been fired once in a humiliating way really opened my eyes to how bad things can go if the person on the other end wants to be cruel.

toyg• 12 years ago

As far as I can remember, that's always been SOP in the workplace. Despite all these "new wave" models of employer/employee relationship, at the end of the day there is always a basic power imbalance between owners/managers and employees.

afhdshufdufdo• 12 years ago

Agree with this post, but would go further: if someone feels that they are not contributing in a way commensurate with what they think they should be able to contribute, then the reason- whether they are bored or not, and it is their fault, or someone else's, or no one's fault- they will be unhappy. Challenging is not as important as fulfilling.

jokoon• 12 years ago

I'm so bored I've been unemployed all my life

NAFV_P• 12 years ago

The reality is that someone is going to tell you they’re bored quietly and when you least expect it. They’ll tell you halfway through your 1:1 and they won’t use the word bored. They’ll say something innocuous like, “…and I really don’t know what to do next,” and you’re going to blow right by the most important thing they’ve said in a while because you’re worried about your next meeting.

I see a parallel between this quote and a supervisor or co-worker stating some other co-worker "doesn't understand", which when translated to cold, honest English becomes:

"[co-worker] is antagonistic, aggressive, rude and stubborn. I do not want to confront [co-worker] regarding this issue because I want to avoid the hostility that will be thrown back at me, you will have to deal with [co-worker]'s hostile behaviour all by yourself because I am a stinking coward and want to brush this problem under the carpet."

digita88• 12 years ago

My problem in my old job was due to boredom. But it was more than that - I was bored and management didn't really take heed of what was wrong despite the feedback that I have been giving at my annual performance review (where I did extremely well) and monthly meetings with the line manager. Even if I had the education and work experience with certain projects, politics ("X's department is doing that") and That's-not-your-day job-isms" got in the way. So in the end, I got bored and quit.

jecxjo2• 12 years ago

As with everyone else, after reading I've realized I'm extremely bored at my current situation. The one thing I'm having difficulty taking away from it all is what to do about it. I work for a big company, been here for a decade, have become "The Guy" for two major product lines and have never really had a Team. In a decade I've done two...yes two projects. Each one all written by me, application code, kernel drivers, building a root file system. Hundreds upon hundreds of hours generating thousands and thousands of lines of code. I'm bored because I'm given a project and because they will not fund additional heads (I'd love just one but really should have 3 or 4) these projects take 3-5 years to complete. The beginning is interesting but after a few months it comes down to "Implement these 200 API calls" which gets old really really fast.

At a startup there are tons of tasks to get done and not enough people so you can easily jump from one area of the company to another. Your manager can say "Joe is getting board doing X, but Y needs to be done and its completely different." But what do you do when your job doesn't have other areas for you to jump to? We have different areas of the business but at this point I'd have to take a demotion to move...or become a manager and not code anymore.

I guess I've got more of a gripe than an actual comment. And I know a lot of people post about startups and small companies where change can actually occur. Sucks that I have to give up stability to get interesting work.

Bored people quit (2011)

Related Stories