
Reddit and Facebook Veteran on How to Troubleshoot Troublemakers - ca98am79
http://firstround.com/review/reddit-and-facebook-veteran-on-how-to-troubleshoot-troublemakers/
======
cakeface
>That guy who decides to rewrite an entire system in his off-hours in a new
language without telling anyone else?

I have worked with this person on more than one occasion and I would love to
work with them again. Entire new products and verticals are often the result
of such projects.

Companies have such a hard time dealing with risk. They think that the only
appropriate thing is to always minimize risk. "Look, I have minimized risk at
every opportunity. I am doing a great job!" That's not true all the time
though. When exploring new business models or in some other situations high
risk activity should be preferred.

~~~
funkysquid
As one of these problem people myself, it's helpful to know that this is
considered bad behavior. I'm not sure it should be though...

The thought process is that many times the barrier to adopting a better
technology is just the time investment. So if you're sick of working with a
problematic system, but the team doesn't have the time to fix it, fixing it
away from work might remove that pain point from your life. And since often
these projects begin and even end as just an experiment, there's not much
reason to tell the team until you have something.

It doesn't really seem to have much of a downside - assuming you're just
presenting whatever you come up with to the team later as an option, and not
going crazy and replacing production systems without asking.

~~~
scubaguy
The "without telling anyone else" part is potentially the problem.

Imagine you committed time and energy to build a decent system - not perfect,
but most people are ok with. You feel a sense of ownership on this system.
Then one day, a coworker of your tells your manager that he has built a new
system in his off time. He also made a conscious decision not to discuss the
effort with you. How would that make you feel?

~~~
jdbernard
Yeah. As I've gotten older I've cared less and less for "my code." If the new
effort is demonstrably better than the existing system, then I'm happy. Who
cares who wrote the old stuff, this is better.

The problem, of course, is that often the new system is not better, it's just
newer. Sure, it may be simpler and easier to understand, but is that because
it is an inherently better solution, or is that because it doesn't deal with
all of the the real-world conditions that the productions system has grown to
support over time?

Even then re-writing is often a good thing. You can re-approach the problem
domain with all the insight you've gained building the old system.

~~~
jey
Ideally there would be good enough tests of the old system that if the new
system passes the same tests, then there's high confidence that it will
perform correctly in production too. That way we get the benefit of being able
to refactor or reimplement entire subsystems while still having almost the
same assurance as the old system.

------
wccrawford
She notes that she has a tendency to require that the solution work her way
when coding.

I wonder if she realizes she's doing the same when working with people's
problems? Almost all of those solutions end with, "do it my way or get out."

Not a collaborative coder? No room for you here. Not a people person? No room
for you here. Want to use the latest technologies? No room for you here.

For someone who wrote an entire blogpost about the benefits of troublemakers
and how to integrate them, she doesn't seem very willing to actually work
_with_ them, just to make them work for her.

~~~
autotune
>For someone who wrote an entire blogpost about the benefits of troublemakers
and how to integrate them, she doesn't seem very willing to actually work with
them, just to make them work for her.

That's kind of the point. You don't want to be working with someone who can't
work with other people. If you're a "troublemaker" and refuse to change and
adapt to the way the company you work for does things, go ahead and found your
own and do it your way, and see if others are willing to work for you in the
long term, or find another company with the culture you're after. When it
comes to tech there's plenty of companies out there who hire for different
personalities and abilities.

~~~
lawnchair_larry
Yeah, because nobody would want someone like Alan Turing at their company.

The whole "everyone must be a team player" thing is such crap. I will gladly
take a one man army with the resolve to deliver above all else over a team of
mediocre players who take 4 times as long and waste more time arguing in
meetings than it would take to just bust the thing out twice.

Effective teams are great too, but if you can't figure out how to use the
other type, it really is your loss.

~~~
pm24601
No. Most people _think_ that they are Alan Turing, Linus Torvald, Steve Jobs;
are not.

------
sqldba
Wow fuck everything about this, it sounds like extreme micro management.

The premise here is a) do exactly what you're told and b) in exactly the way
we tell you or c) you are mentally ill.

Now I'll agree that some of it is plain toxic. You can't deploy whatever you
want to production. But that's one line from an entire article of benign
behaviour.

You're REALLY going to crush Mr/Mrs Nostalgia? WHY WOULD YOU BOTHER. If
someone saying things were better two years ago is going to crush your
organisation then FFS you have bigger problems on your hands.

I'd also like to put forward that if you're a hermit you either may just take
pride in your work (a carpenter doesn't go parading around a half built table)
or are STILL working in a toxic company (not just came from one so its your
fault).

If they're doing the job then for fucks sake let people be rather than trying
to invent a job description for yourself which involves "fixing" normal
people.

There's a reason people are quitting when faced with this "mentoring" and it's
not because they're burnt out.

------
Deimorz
Pretty strange to describe Bethanye as a "Reddit veteran", especially leading
the title with that. She worked at Reddit for less than a month.

~~~
amackera
I wonder what happened there?

~~~
MarkArts
From some minor googling it seems she didn't want to mixed up in Reddit's
community problems at the time.
[http://thenextweb.com/insider/2015/07/14/reddits-troubles-
mo...](http://thenextweb.com/insider/2015/07/14/reddits-troubles-mount-as-
chief-engineer-bethanye-blount-quits/)

------
bsder
Sigh. Yet more unsubstantiated psychobabble pablum.

Managing people is hard. Mmmmmkay?

My ability to manage is a function of how creatively and effectively I can be
in aligning the company's goals with the worker's goals. It won't be 100%
(that's why it's called a "job" and we pay people), but most managers barely
even try. Funny how "troublemakers" seem to get in line when you actually
manage to understand what motivates them.

If a manager can't do that, either A) the manager needs to be replaced or B)
the employee needs to be replaced.

The problem is that we don't fire/demote managers nearly often enough, and we
fire employees far too often.

~~~
buerkle
Did you read the article? A good chunk of it was about understanding the
trouble makers to see what motivates them and aligning both the goals of the
employee and the company.

------
maxxxxx
Nice article. From my experience the biggest troublemakers are often in
management two layers or more above and have no discipline in making changes
or throwing new ideas into the pipeline.

~~~
gravity13
ha! Very same experience here, too. I was just working at a place where one of
the designer-founders redesigned a page to look one way. Then three months
later, he redesigned it again, to look back the old way. He actually put these
into the pipeline, assigned it to different engineers, and there was no
reasoning over choosing one way or the other. Both designs had the same
functionality and the same glaring flaws. He just kept wavering and wouldn't
even consider doing any user testing or A/B testing on it. Glad I don't work
there anymore.

~~~
morgante
> He just kept wavering and wouldn't even consider doing any user testing or
> A/B testing on it.

That's why it's essential to pre-commit to a culture of testing everything.
It's by far the best weapon you have against a founder with a terrible idea
that they won't drop.

~~~
gravity13
Funny thing was this place did espouse "test everything" except it came in the
form of our Product leads "test only the things I don't agree with." Which of
course meant we were using all of our _testing budget_ on dumb things.

------
kazinator
> _THE HERMIT_

> [...]

> _NOSTALGIA JUNKIE_

> [...]

> _TREND CHASER_

> [...]

If you enjoy this sort of "laundry list of named stereotypes" format, you
might like "Academic Programmers: A Spotter's Guide":

[http://www.ee.ryerson.ca/~elf/hack/academic.html](http://www.ee.ryerson.ca/~elf/hack/academic.html)
[1997]

It's got more of them and they are funnier.

------
WhatIsThisIm12
I would hate to work for this lady. The fact she labels these archetypes,
which are questionable in the first place, as "troublemakers" really makes it
clear what she thinks. She's better than her engineers, they're lucky to work
for her, and if they're not careful, she'll fire them.

That does not sound like a fun work environment. Not that I'm trying to be a
troublemaker... (Please don't put me in timeout!)

~~~
ball_of_lint
I didn't get the feeling that she thought she was better than her engineers.

Regardless of that, each of these archetypes presents real difficulties to a
team that has to deal with them. A hermit can cause massive troubles for a
company if they are doing critical work. In the case that someone is
prolematic to the team, it's better to solve the problem than to lose the
person, and that's what she tried to do.

~~~
studentrob
> I remember several instances when it took a few deep breaths to keep me from
> kicking him out. But today he leads a team and triages the troublemakers he
> once was. Sometimes when you save a troublemaker, you’re saving a team
> they’re not yet on.

 _She_ saved the troublemaker by taking a few deep breaths, not the team. She
blames the troublemaker for his bad behavior, and takes credit for his good
behavior.

She does not acknowledge efforts made by other team members, and barely
acknowledges the individual himself for the adjustments he made.

She could've written "Sometimes when you _are patient with_ a troublemaker,
you're _helping to save_ a team they're not yet on."

We each make our own choices and face the consequences, good or bad. There is
room for guides to help people understand consequences. Mentors and managers
do not make choices for individuals. Ultimately, each choice is our own.

~~~
pm24601
I think she meant it as written. It sounds like she helped refocus the
"troublemaker's" energy, language, mannerisms in a way that helped him be a
positive contributor rather than someone who was resented by the rest of the
team

~~~
studentrob
Communication skills and perceptions are everything in the world of
interpersonal relations.

You added the word " _helped_ " twice whereas she did not use it in the above
quoted comments.

Your perception is different from mine. That's fine. Her phrasing is ambiguous
at best, and possibly pretentious.

------
gravity13
I got to disagree with the whole continuity over ingenuity trope. It's how I
can continue to remain modern as an engineer, and if done correctly, leads to
vast gains in cognitive complexity by delegating concerns to newfangled tools
that handle it better. Sure, it's a bit less stable, but this is how we keep
the industry moving quickly, and I hope managers see it more in terms of
trading technical debts than a stubborn "oh great, you want to introduce
another new tool!?"

~~~
rosser
Right, because your growth as an engineer trumps the company's concerns over
having a stable code base.

I can't count the number of times I've had to give some variation on this
speech to junior engineers of one stripe or another: The company does not
exist to give you cool things to hack on. The company exists to provide a
product or service to its customers, from whom it collects revenue, in order
to repay its investors, pay its employees and suppliers, and hopefully also
make a profit. To the extent playing with cool, new, whiz-bang furthers those
goals, it will happen, but whiz-bang is neither necessary nor sufficient for
those goals. In fact, whiz-bang for its own sake can often be _inimical_ to
those goals.

Also, nice false dichotomy.

~~~
wyager
>Right, because your growth as an engineer trumps the company's concerns over
having a stable code base.

When a good engineer can easily move to dozens of other companies, yes, it
does. If I felt like my growth had stagnated and my employer wasn't willing to
work with me, I'd move on.

~~~
rosser
And I'd submit that a "good" engineer is, by definition, the kind that
understands when it's appropriate to use new technologies, and when it's not —
and "Look, shiny!" isn't, IMO, a good enough reason.

And pushing — let alone threatening to move on — to use new tools when they
aren't appropriate? Please, go be someone else's problem.

~~~
Karunamon
It looks like you two are in violent agreement.

Here's the problem: _Everything_ , no exceptions, starts out as "Look,
shiny!". Usually, you need to play with it to find out if you even have a use
case to justify spending the resources to do a formal evaluation. Reading the
docs is a poor substitute for deploying it.

Now what the article talks about is "shiny!" being pushed into production. No,
no no no _no_. Never do that. There's no excuse for just dropping new untested
shit into prod where customers can trip over errors - I think everyone can
agree?

But if hypothetical you is preventing your hypothetical engineers from
indulging their curiosity and trying out new things to see if there's even a
business case to be made for production use ("But there's no time" counts
here), you're hamstringing the engineers and hamstringing your business.

~~~
cookiecaper
Yeah, this is a good summary. There should be room for experimentation in
isolated, non-production environments if the engineer in question is trusted
and can propose a hypothesis better than "I think this will make my resume
better". That stuff _shouldn 't_ be rushed out to prod without thorough
vetting both internally and externally, which, much to the dismay of junior
engineers (and not-so-junior engineers with bad judgment), often means letting
a tool age a little bit before you bet the company on its stability. Unless
the tool truly revolutionizes your particular line of business, and let me
pre-emptively state that there's a 99.99% chance that it doesn't even if you
think it does, there is no harm in letting other people be the guinea pigs.

------
andy_ppp
TLDR; Oh hello there! I've come up with a faultless way to manage inventive
people out of organisations by pitching them as being troublemakers.

~~~
sqldba
Write a book, turn it into a TV show, take my money!!!

Wait a minute you didn't make all this up just to make money did you?

------
dimino
This is a gold mine, I'm so glad to have found this article, thank you for
sharing!

I definitely evolved from "The Hermit" into what I am currently, some form of
"Smartest in the Room"(I don't think I'm smarter, I just tend to think the way
I came up with is best).

Being a developer is a process! I'm incredibly interested when we stop
pretending that everyone's a "rockstar" or whatever, and start talking about
the problems that come up, and how to work through them. I'm only just now
coming to the realization within the last few weeks that I need to be more
open to alternative and intermediate solutions that aren't perfect, but solve
the problem for the time being.

Again, thanks for sharing!

------
studentrob
> I remember several instances when it took a few deep breaths to keep me from
> kicking him out. But today he leads a team and triages the troublemakers he
> once was. Sometimes when you save a troublemaker, you’re saving a team
> they’re not yet on.

What a saint. Seriously, it always felt funny to me when a team member was let
go at the behest of one or a few individuals.

Anyway, the way she says this leads me to believe she thinks she is more
important than other people.

~~~
eumoria
> Anyway, the way she says this leads me to believe she thinks she is more
> important than other people.

She's a manager of course she thinks that.

~~~
studentrob
Well that's silly. All managers do not feel that way, and the salary sure
isn't higher in many cases unless you're nearing the top of the organization.

Being a manager is simply a different job function.

~~~
gravity13
This is where I feel like the title "project manager" ought to be
reconsidered, perhaps to "project secretary." That way, it's a bit more clear
there's less of a hierarchy and more of a duty.

~~~
studentrob
People go on power trips regardless of title.

It's a mentality. You just need to hire people who are both smart and able to
do the job, and can also see that all people are equals.

------
6stringmerc
Having worked in several divergent fields as a Proposal Writer (aka Team
Leader with Zero Authority) - health care, finance, and insurance - nearly
none of these archetypes are exclusive to engineering or the tech sector. I
think they are reasonable break-downs of classification as presented (Hermit,
Nostalgia, Trend Chaser, and Smarty) which can be useful to consider in pretty
much any professional, team environment. This article could be helpful to get
a more relaxed, casual perspective of employees that can be frustrating.

I've often joked that working in a fast paced, multi-deadline Proposal gig,
it's like herding cats. Each team might have one or more of these
troublemakers - or, worse yet, be the 'name / lead person' running the
opportunity - and so learning techniques to work through the challenges became
second nature. Always was a fan of Kevin Mitnick, and his guides on social
engineering security can be resonably applied in manipulating team members for
great good. YMMV.

------
erikb
About the hermit: Why isn't the first assumption to look into the company's
own culture? I mean you can work on trust as much as you want. If there is no
reason to have trust in the team the tactic will fail.

------
wglb
This is a good article and reminds me of myself as a young trouble maker in my
first major job after graduating. I think I was really pretty hard to work
with. Now, not so much. My personal arc reminds me of growing up where my
parents, particularly my father, was quite strict. Once I had children of my
own, I often heard myself using my father's strict voice quite often.

Her career also reminds me of Gerald M. Weinberg who started out as a computer
programmer turned consultant. He eventually realized that many of the problems
he was brought in to solve weren't strictly technological, and ended up
debugging teams, using her terminology, and that became his career.

------
1_2__3
"For the last 20 years, Blount has led technical teams at a range of
companies."

LinkedIn says she was an IC until 2002, and then from 2002 through 2006 she
was a "software design/project management" which is also an IC role. So really
she's been leading technical teams for at most 10 years, which is not someone
I would suggest anyone turn to for sage and experienced advice.

~~~
sqldba
Sorry what's the IC acronym?

------
pekk
None of the examples of troublemakers are management or HR.

it's not that those people never cause trouble. It's that the trouble they
cause is something we are forced to accept.

------
acveilleux
The way in which this site keeps bringing up a layer to get me to sign up for
something everytime I go away from reading what is an interesting article is
infuriating.

------
pklausler
I'm glad that humans fall so neatly into a few distinct categories.

------
oneloop
Great PR.

