Reddit and Facebook Veteran on How to Troubleshoot Troublemakers
firstround.com
firstround.com
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.
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.
Just deploying it without consulting with anyone in place of the original production system would be a poor quality behavior.
If you think you have something, make an isolated test deployment of it for internal evaluation, and so on. No matter how the existing system sucks, at least it has some mileage in deployment and has been through some QA.
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?
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.
Like manning up.
This is snark, but I'm actually being pretty serious here. I would want to know if the new system is going to make everyone's lives easier.
If it's a large system designed by a person on their own in a corner, without interaction, without feedback on features and usability? ... it's unlikely to and I would be rightly wary.
I have however seen existing systems that have pain points that everyone complains about but no-body has the time for fixing, until someone finally takes a few days out to experiment with something different, and sometimes the results are excellent. But IMHO that's not exactly a "rewrite".
1) It is a known pain point, so the problem has been discussed. Probably a lot. The pain is the reason for the code, and if there's a new tool involved, that's additional not a main reason.
2) it's usually a technical task - for example something related to faster, more reliable deployments. This means that the requirements are already well-known by the engineer, and that it probably hasn't been addressed yet as it's hard to tie to a business benefit.
3) Experience of the engineer. Senior devs are more likely to chose a good target.
I'm sure the dev ops people will be happy I converted our automation from Chef to Puppet, you're welcome!
Assuming this is done during free time and you're presenting the solution in a respectful way, then that's their problem, not yours. If you perceive this is going to happen within your team then there is already something wrong. There isn't enough trust and cooperation in working towards a common goal. Every solution should be openly presentable and scrutinizable by every team member.
If you suggest an idea, completed or not, and someone is offended by that, it's not your fault. It is a consequence of your actions. And, I'd argue it's not your responsibility to care for others' feelings to such a degree.
Some people may disagree. I don't know how they can survive. They must feel they are constantly walking on eggshells, wondering how people will react to whatever they say.
How this would go down in your particular workplace all depends on the surrounding political and social context. It could either be interpreted as "Wow, that guy is such an amazing programmer that he was able to refactor our whole legacy system in his spare time! We should definitely keep him on board and learn from this kind of work, even if we can't do a full-scale replacement." or "Wow, that guy is so self-absorbed and unwilling to cooperate with his teammates that he went home in a fit of anger and thought he could replace 10 years of work in a few weekends! What an abrasive blowhard. Let's fire him next time he gives us an excuse."
The halo effect is going to be the primary determinant here. [1] If your colleagues and superiors are predisposed to interpret your actions favorably, they'll probably do so until you give them a reason not to, and vice-versa. It takes a lot of work to maintain a good halo, and it should be considered your primary job duty if you wish to have a fulfilling career as an employee.
Humans are social animals and will evaluate everything about you, including your technical competence, by the social signals you output. Successfully managing these can get complicated in the workplace due to the competing interests of the people you come into contact with during the course of your employment.
[0] https://en.wikisource.org/wiki/The_Prince_%28Hill_Thomson%29...
Are you disobeying your manager's direction? (And thereby undercutting their creditability/authority - and how does that make the manager appear to their supers/peers?)
Why can't you go to your manager and ask for permission? If not, why not?
How would you feel if your "great" rewrite is rejected - because someone else was already doing the rewrite; or because the system is going to be redesign entirely? (For example, the code will be ported from .NET to Java - and all the .NET code will be discarded)
If you haven't yet, try being a manager for a while and then see if you still think that this sort of troublemaker.
That's a big if. The fear is that such a person doesn't have the judgment to not be the type of person who goes into personal-overdrive into making unfeasible changes (or, worse, into bikeshedding). It doesn't mean that such a person is a horrible person, just that opening lines of communication should be a priority, rather than letting that person put themselves in a position of difficulty.
Management had a problem with our ActiceX based web apps not working with Macs or OS/2 machines. I offered to rewrite them to use Java instead and I was told no because Java wasn't made by Microsoft and if I wrote anything in Java I'd be fired.
Another job I aaw that VB 6.0 and Windows 98 was too slow and I offered to rewrite the app in C ir C++ and use GNU/Linux to make it faster. Same problem not Microsoft so management didn't want me to rewrite it.
Having seen it done I can understand very easily how someone could not just remove it.
It would have been better yet if the person hadn't created work for others with this homebrewed ORM.
..expectations are low, and there's value in keeping it that way! :)
(all my favoruite stuff has been stuff I've worked on for myself, that doesn't earn any money. I find almost all of it more worthwhile than any of the technical entrenched garbage I've written in the corporate world for the past decade of my life)
I had a boss who came back from vacation that was so threatened by the automated testing harness myself and another coworker created, that she rewrote the entire system herself.
It was very demoralizing.
Because the PM said, "If it can be in a script it should be in C#!"
Of course the C# programmers didn't like being taken off of productive work to build infrastructure tooling which was working perfectly well in PowerShell where it belonged. So they quit. So did the remaining DBA staff. All of them.
So the company told their customers this feature was broken and would not be updated in the foreseeable future. That was a year or two ago.
They could just run the script. But they refuse to on principle. So they suffer and the customers suffer. Companies are great!
Damn! I was thinking about doing that right today for a subsystem we use at work... trying to gauge its performance in the new language and eventually "sell" it to replace the existing one...
I think that attributing resistance to the off-hours rewrite just because of minimizing risk is oversimplifying the issue.
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.
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.
I actually have a post about this: http://blog.alexrohde.com/archives/473
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.
That describes me pretty well, and those with whom I work love me. They just keep me in my little box, leave me alone and let me do my work. But they are also a grown-up company that doesn't make people wear 27 hats. PMs do their job, Infrastructure does theirs, Client Support does theirs, etc. Not every job has the same requirements as every other job.
That's corporate life in America. No room for individualism. But I've heard it's even worse in Japan, so there's that...
And she lists several "harmful" practices like this.
In short, taking initiative? Nope, we don't like that here in corporate America. Doing what you're told and minimize risk. Don't actually try to make us money or anything.
Software is a little special, because you can still kinda get away with that.
Currently dealing with a fellow that exhibits all four of the documented traits plus a general unwillingness to document anything. Kind of unsalvageable at this point... =(
1. Bake rules into your workflow. For instance, enforce daily or semi-daily standups. Make git commits a portion of things in those - so everybody has to say what they've done in git commits (obviously, this isn't 100% of things). Other coders on the team will be annoyed by the person who isn't committing code daily, so this will mean that coder is admitting not to you, but to them, they're playing by different rules.
2. Force them to write design docs for implementing new technologies, before they're implemented. Then write a retrospective about how things went over, a week or two after the project is launched (things that were unexpected?). This can serve as documentation, but adds a bit more clarity to the overhead that comes with these changes, which is easy to miss when you're in the thick of things. Perhaps it's all they need to understand what kind of complexity they're adding (or what kind of simplicity you're not giving them credit for).
Agreed. My style is to contribute to creating the goals of the team in addition to the projects. She'd probably call me a trouble maker haha! And I'd be proud to be one. Aren't computer programmers supposed to be troublemakers? We're hacking the system ... ;-)
Working effectively with other people is definitely a skill. Some people have it from birth and some have to learn it. One blog post isn't going to solve everyone's problems but it is interesting to hear her experience.
No, we're not, and no, we're usually not.
I have been in the position where the VP of IT wants to have his cake and eat it too: VP salary while micromanaging variable names that the dev team uses so that he can relive his salad days as a tech lead.
While that may be the reason in that particular case, it seems to me the more common problem for micromanagement isn't a desire to relive one's days in a position lower on the org chart, its simply lacking the skills to operate at one's new level. Or, I guess, a corollary to the Peter Principle: people tend to work at their level of competence, despite being promoted to their level of incompetence.
So yeah, the technical problems should be open to solve for me as I and my team think. But there are a lot of things my manager should define for me and care about even if I don't. That's why he's part of my team.
My favorite managers are coordinators and facilitators. They listen to everyone's input, above and below them, and stear the ship towards success. They gauge input commensurate with the experience and knowledge of each person from whom it came. They make decisions with special sauce that can't really be boiled down to words. They're transparent, communicative, thoughtful, available and appreciative.
If the manager has heavy experience and success, it may sound like he's saying "do this my way or get out". For example, Steve Jobs felt he had great taste, and many people felt he was a jerk.
He obviously received input from a huge number of people and couldn't have made Apple successful alone. He discusses how Apple recovered in the late 90s at D5 in 2007 [0]. The NeXT brainstorms are also interesting to watch [1]
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.
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.
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.
> [...]
> 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 [1997]
It's got more of them and they are funnier.
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!)
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.
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.
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.
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.
We're blessed to work in an area where it's possible to grow your own skills while staying within the same company. If a company can provide this to its engineers, it's a win-win - employee skills improves, they want to stay longer, etc. And let's not forget humans, not AIs, are at the helm of those companies.
They aren't anything whatsoever to let you build things that they're somehow going to depend on using NewHotness-0.1.3.
EDIT: Look, I'm not saying growth and exploration are bad things. I'd never have learned the tools and technologies that have fed me for years now, or been able to expand those skills in ways that have made me tremendously valuable to the people who've decided to pay me nontrivial sums of money in exchange for my knowledge, skills, and time, if I hadn't been, as you say, "blessed" with opportunities to try new things.
But there's a difference between acting like you're blessed, which to my mind entails exploration with respect for the needs of the folks who are paying you to explore, and gratitude for the opportunity to do so — and acting like you're entitled, which ignores those things, and treats it as an exercise in résumé-padding.
When you're getting a salary you're standing in the way of the company making that money they're giving you. It's very counter-productive (and illegal, as you mentioned), but if you find this silly maybe you understand why I find your original reply silly.
You aren't "standing in the way" of them making the money they pay you; they're making a choice, with every paycheck, that your time is worth more to them than what they're spending to keep you there. You upset that balance by introducing instability into the stack because it's new and shiny at the ultimate risk of making that exchange no longer worthwhile.
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.
And pushing — let alone threatening to move on — to use new tools when they aren't appropriate? Please, go be someone else's problem.
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.
Violent agreements are lovely when they're sorted out by the market: at the moment, the best engineering talent I know would not be caught dead working on (just as an example) PHP.
There's simply no need to let your skills and salary stagnate when you can get paid more for working with the state of the art elsewhere.
Demand is simply too high, and like anything, there's tradeoffs: you can get anyone to do anything for enough money. But "great talent," "cheap," "low autonomy," "fossilized tools," will require some compromise.
Until you start losing employees to competitors who do offer cool technologies to work on. Your patronizing tone about how "junior" engineers just don't understand business is unwarranted. ALL engineers, not just "juniors", need to stay relevant in their field. Some of us actually enjoy what we do, too. Keep using antiquated technologies and watch your talent pool dwindle and your product gradually become obsolete.
The company doesn't exist for me to hack on cool new things. Of course not. But what you fail to understand is that I'm a very intelligent person who is not planning on spending the rest of my life doing shitty simple e-commerce UIs, or whatever it is that you do. It's easy to think nothing but the goals of the company matter, especially if you're an awful founder, but the world just doesn't work that way. We all need to move on when the company likely dies, and I don't want four years of "I had no choice but to work with crap" on my resume when this happens, just because I had an asshole boss who hated other people who did smart things around him.
But it's no fun to try to use something, and you can't because someone moved fast and broke things. It's even less fun when your customers are calling you because your site is down, and all you can say is "It's a problem with the platform." Before long, you get to choose between the platform you're paying for, and the customers who are paying you.
There are pros and cons to adding new tools. Each situation is different and would ideally be decided by all the effected team members. It depends on the team, existing tools, product, whether it is released yet or not, and a myriad of other things.
An engineer could install whatever he likes on his own machine or VM in his free time, if he has any. If other engineers have a problem with that, then like gay marriage and abortion, that is their problem. Similarly, if an engineer installs software willy-nilly on a production machine that has active users, I think we can all see how that is unreasonable. So the debate comes down to the in-between grey areas. Without being in the moment, none of us can comment on it towards any real conclusion.
From the perspective of an employee, the company is forcing you to stagnate and become someone that is easily replaced. I don't blame anyone for being insulted by this. The company is advancing their own interests at the cost of their own.
Nobody enjoys being forced to do something. So while an employee forced to work in a certain way can be expected to be bent out of shape, so can an employer whose hand has been forced by an employee. The adage 'shit flows downhill' is true, and the intractable employee will soon find themselves swimming in it.
A company may decide to cut their losses early if you are actively making your position harder to fill. From their perspective, the longer they wait, the more deeply entrenched you become. Companies value reliability. They want someone they can count on. The same goes for people. If your manager doesn't feel they can trust you, if they are consistently afraid that you will embarrass them, then you are a liability to them. If you aren't outright fired, you will be kept on a very short leash.
There are a lot of benefits to toeing the company line, insulting as it may seem. Should you find yourself in the good graces of your manager (and by extension, the good graces of the company), you will enjoy a remarkable amount of autonomy. By being dependable (if not predictable), you gain job security and autonomy. You will find your suggestions are taken more seriously, as nobody is left to wonder what trick you have up your sleeve.
I totally understand where you are coming from. I am always looking for better tools for the job at hand. Companies move slow, and technology moves fast, and it's easy to be left behind if you move at the speed of the company. Ingratiating yourself to your company takes time too. It could be years before you get to use a new technology, at which point an even better tool shows up.
The company has the upper hand in this situation. Changes probably won't come quickly. If you find yourself in a position where you aren't happy with the way you are allowed to do your job, oftentimes the easiest way to solve the problem is to find a new job.
A truck number of 1 is a bad deal all the way around unless the employee in question enjoys going without a vacation.
Also I've found that most managers know they should keep their team replacable, but also efficient. And they often end up treating long term replacability for short term efficiency gains, again and again and again. So while it should be a real issue it is less often than we coders worry.
Wait a minute you didn't make all this up just to make money did you?
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!
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.
She's a manager of course she thinks that.
Being a manager is simply a different job function.
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.
I'd say everyone's happiness is equally important. I agree that managers are often in a more secure position and can afford sacrificing some of their desires. Generally speaking, they should not need to become unhappy in order to make their own employees happy. Excepting, of course, a CEO who's earned his due and is now taking a $1 salary, and the cash-strapped entrepeneur who's trying to hold his fledgling business afloat and expects future returns.
It's not a bad thing to assume nuance when you read intent.
Both scenarios are possible. A manager could say that all other team members are equally important while also implying that she or he is more important.
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:
> 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.
I understand the need for consultants and managers to brand themselves. She goes a little overboard. She does not acknowledge efforts made by other team members, and barely acknowledges the individual himself for the adjustments he made.
You write, "reforming them to remove that problem is a win-win for everybody". It sounds like you also feel it's possible for one individual to wholly change another.
If that is your meaning, I respectfully disagree. 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.
There's a big difference IMO between what she wrote and a more realistic rewrite: "Sometimes when you are patient with a troublemaker, you're helping to save a team they're not yet on."
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.
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.
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.
it's not that those people never cause trouble. It's that the trouble they cause is something we are forced to accept.