‘Positive deviants’: Why rebellious workers spark great ideas
bbc.com
bbc.com
Next they'll be talking about rebellious accountants who have recorded more numbers by the end of the day than were in the spreadsheet at the beginning, or subversive lawyers who review contracts that had not already been reviewed. Before long it will take a fifth-column delivery driver to move a pizza to a location it's never been before.
the “rebellious” attitude also comes with you sinking in more time (you need to do your “dayjob” on top of this, right?) and with the real consequences if what you’re doing rubs people the wrong way/is seen as wasting time.
That is exactly what happens, but not because your management isn't listening. The sacrifice of good ideas is done in the name of predictability or viability.
I've been witness to and driven a few of these sorts of moves and what has struck me is that successful "by-pass of management" rebellion costs time, effort and most importantly is a test of active leadership skills.
There was a system which I was working on which absolutely sucked (for me personally, because I worked on performance and it couldn't be improved without changing the architecture). There was a way to rewrite about 25% of the system under different assumptions which would fix the performance issues, but the system that was in production already had several other issues which needed to be prioritized over performance.
For a manager in front of a customer, of course, we're absolutely committed to fixing whatever is broken. That goes back into engineering, where the rewrite wouldn't have half the bugs we have, but it looks like Dunkirk when it fails. The manager has no way to actually approve the rewrite, when they're trying to hire immediately to just do the work that's already on the plan.
Anyway, long story short, there was an intern for the summer who did the rewrite and get it working to the point where the next generation system was almost entirely built out by a single uninterrupted intern over two months (& his code is still in prod today).
The methods needed to break rules and succeed are often just the same qualities needed to "just succeed", except the breaking of rules is necessary to prevent the regression to mean.
And if you don't succeed, being disavowed like this means worse results than following orders. There's something to be said about the motivation of a team after burning their boats.
I'm gearing up to do one of those off-the-books project right now. And the tolerance for risk is clearly something I'm having less of each year. That said, surviving failure does more for your confidence than clutch, but definitely would like less red in the ledger.
Take out any of those and you get either nothing or a disaster. But if all come together, you will have someone on your team who doesn't just recognize that missed opportunity the other excellent other engineers already realized, but actively go against the plans of at least one level of management in order to do what's right for the company.
They tend to create a lot of friction, but can often save a project. I personally love working with these kinds of people as I was formerly one of them — and they can and often do make the best managers later on (funnily enough, I've heard similar stories in the bio of almost any technology leader I respect).
Having made the mistake more than one time of accidentally enabling people who didn't have the loyalty / optimism or technical excellence parts though, I get why these kinds of people are usually held in place in large organizations. The resulting friction, bickering and havoc can as well break teams and companies.
You are absolutely right. I'd like to point out, that as one person, I've been both depending on the role.
If I'm in a new space with new tech, I need to learn before I have the technical excellence. If I don't feel safe, I won't have courage to challenge leadership. If don't have hope, I won't have optimism in the future.
I say confrontational systems, because the only way to actually spark change in a system that has been systematically extinguishing sparks of change is actually confrontation. And the very fact that confrontation as such is now associated with negative emotion (same with conflict actually) goes hand in hand with the top level comment on this issue. Confrontation/conflict is bad, optimism is good.
Confrontration is how you bring attention to a problem. Conflict is what happens when that dominant idea is challenged by another idea.
Confrontration is how you bring attention to a problem. Conflict is what happens when that dominant idea is challenged by another idea.
what i mean to say is, confrontation/conflict is a normal part of debugging reality, and is healthy as long as there is an open/healthy system to enable it
That is great for the one individual with that reach, but does not solve the problem from an organisation perspective.
If we took that advice to heart, then the CEO would have a line outside his door of all the engineers in the company, doing what they feel is best for the company. He would then say, Jeez, I think I need to have some managers to group these people together like in a hierarchy.
Plus the guy(s) you know, everyone else, including their managers, knew they had the boss' ear. And in my experience that person just becomes another manager, 'cos everyone reaches out to them to get their project unstuck.
There is absolutely no reason an engineer could not influence the decision making process of a manager. The manager is the one taking the responsibility for a decision, but it is a poor manager that fails to listen to their top experts and leverage their knowhow.
That's what it means to be a great engineer that gets the manager ear. It's not the engineer's job to manage, but is his job to be part of the team, and do what feels right for the team, including to tell their opinion on the matters they are a subject expert.
Processes are just scaffolding and general guidelines on top of a functional engineering organization.
An engineering organization is not a car factory.
No matter how brilliant, or well intentioned, no CEO can listen to all views from all experts - at a certain scale this goes from 'has other work to do' and flips into 'physically impossible'.
So, yes there is a reason "an engineer could not influence the decision making process of a manager. "
At some scales it is impossible. And if you mean why cant he influence the manager above him - yes thats fine. But that manager has f all chance of reaching the CEO as well. At certain points companies stop acting like autonomus agents and become, some kind of lava like process - predictable and impossible to stop.
maybe large firms are the problem overall
Read Never Split the Difference by Chris Voss, or watch his Masterclass, which isn't really so much a masterclass in negotiation, although that was its intent on the surface. It's more a masterclass on empathy and understanding other peoples needs and how to leverage helping them succeed for your own benefit.
[Statement of my understanding of the situation]
"Well, from my perspective of understanding our mission statement and raison d'etre, our company's strategy for success is [describe the strategy from your perspective]. Is that accurate?"
[Await validation]
"Yes, that's pretty accurate."
[Empathize with their needs = instant connection]
"It's gotta be pretty frustrating for you to see these things that are happening down the food chain every day that are not only hindering that strategy, but actively competing against it. How do you deal with that?"
[Now just listen to them talk and ask questions and clarify to make sure they feel like you're not only understanding their pain, but understand their core basic needs.]
[Statement of your ability to help solve their problems. Why am I different than the other 200 people outside your door?]
"Well, I've been in the software game since I was 8, 37 years; and I've learned a lot of stuff over my years when it comes to high performance R&D. I've been on a bunch of successful high performance teams, including working with X, Y and Z, the team that did Y that was all over the news last year. Having been with this team a few months now, I've been observing what is going on and thinking about how the current tactics of the department are actively hindering us from completing our corporate strategy.
I would like to help align R&D with corporate objectives and not only reduce the friction that's preventing us from achieving them, but actively increase our productivity, output and responsiveness to our customer base to move us forward faster, making the product more desirable and more saleable, increasing profitability over current projections, reducing payroll by and significantly shortening our delivery cadence."
[Now you've piqued their interest, you've hit every pain point in a CEOs target list except for fund raising. Let the conversation go from here.]
The minute you start talking about increasing profits over projections, reducing friction, increasing productivity, reducing payroll costs, decreasing team churn and increasing employee satisfaction, you've basically just become a CEO's wet dream. That's everything a successful engineering team is made of... double if you've already done it before and can prove you can do it again.
So it doesn't matter how long the line up is at the CEO's door. It's no more difficult to bypass it and step up to the front of the line than it is to bypass the chain of management between you and their office.
Everyone's gotta eat. Everyone has a social life. Outside of the office, everyone is equal. How do you get the ear of a new friend or a potential girl or boyfriend. How do you catch their attention? Figure out who they are, what they do, what's important to them and what you can do to help them achieve their dreams. Make a plan. Execute. That's the secret sauce.
Bad sales reps push for every sale no matter what without listening. The GREAT ones focus heavily on discovery and understanding up front and then map what they're selling to (some of) your needs and tell you what they can't help with.
The tricky part is figuring out how much guidance you must give to achieve an overall goal, and then step the hell away from micromanaging.
This is indicative of political savvy and the ability to influence.
Rewarding influence indicates a lack of leadership. Humans being social animals, we're already prone to being influenced by those who are good at influencing.
If management magnifies this tendency, they'll end up turning the workplace into something like social media with paychecks.
Building trust and understanding among colleagues is ALWAYS good.
When I was a manager in a mid-sized companies I was a strong proponent of what I called “The dictatorship of ideas”. Let’s not care where the idea is coming from but try to create better and better ideas all the time. Not everyone liked it.
Not everyone liked it because it was improving the company without changing the political status quo. It's a bit like Washington and Franklin saying 'Hey we want Representation and Taxation" and King George saying "Ok, but you stay as subjects"
Lots of small ideas can improve an organisation, but sometime big ideas imply 'regime change'
On the one hands, if people just do what they want, it's total chaos. Everyone thinks they know best. Everyone wants to be a creative genius (ok, maybe not everybody, but a lot of people). Management needs to make things actually productive (exploit rather than explore).
On the other hand, sometimes someone really is onto a good thing. Ideally, they'd instantly be recognised for this, and given a team and support staff, but managers aren't gods, they're just human beings.
Here's an adaptive solution internal "risk taking" innovation is discouraged, but not usually a firing offense (depending on the time / resources spent, and whether you're keeping up with the rest of your work), because occasionally there is a big win that comes out of this.
Sometimes even that doesn't make it a problem, because the company may decided top-to-bottom that New Project X is a good idea, even when it's extremely risky.
This can create spectacular success when it works and catastrophic failure when it doesn't. Either way, this kind of strategic risk should go through the C-suite.
Smaller tactical projects are what Fridays are for. Throw some nominal resources at engineers, give them some free time, and see what happens. If they can produce a working proof of concept - not just a cloud of PowerPoint and meetings - you may have something to run with.
Unfortunately when failure is not an option, taking risks is even more risky..
Most of the work is now done elsewhere in places that don't have a space legacy, because of this exact risk aversion.
A good company will be a place where the engineers who are capable of following through with great ideas are being listened to while the remainder are kept at their place so to speak.
1: http://ecolo.org/documents/documents_in_english/Rickover.pdf
That sounds reasonable on the surface, but it describes a situation that can't be reached unless the organization is willing to take risks and losses.
The way someone becomes an engineer that is capable of great ideas and the subsequent "follow through", is by failing. A lot. And then learning from the mistakes and doing better next time while developing the grit and confidence that's required for success. This requires an environment that tolerates trying new things and has enough slack so that it's OK to fail sometimes. This stuff CANNOT happen in places where everything is project-managed to the point where everyone has their nose held to a grindstone at all times and the word "accountability" is used as a threat.
I’ve heard this person referred to a “good idea fairy”…they come in, sprinkle their good idea dust and then expect the execution (aka the hard part) to be somebody else’s job.
> Often these ‘rebels with a cause’ – also known as positive or constructive “deviants” – may be motivated because they care for the organisation and its mission, and feel psychological discomfort when they see that important capabilities clearly need improvement.
If you don't feel that way about your work, then what the hell are you even doing there?
Drink the Silicon Valley kool aid with moderation.
I think it’s possible to care about doing a good job without caring about the company.
It's fine, company work as symbiotic systems, we create a certain tension, others focused on other dimensions will counter balance, and a good company will find ways to reach optimums rather than maximums.
Proven idea is a better idea. That's what the article touches on but doesn't explore as their examples are all proven ideas. We don't hear much about non-proven or bad ideas by their own circumstances.
Such stories of course have a selection bias since everyone like a rebel pirate hero story but businesses and organization don't brag about failed projects. After all, the space shuttle blew up due to high risk engineering. In those case we blame the management.
“we are always chasing after things other companies won’t touch”. - sounds great, unless you realize this also what CueCat did.
On the other hand reality doesn't operate optimally.
People value cohesiveness, those who play ball. People will talk about the "constructive ways" to contribute but the reality is there becomes a lot of social and professional peer pressure to stay in line and often doing things hte "nice way" but continues the status quo and gets you ignored, overlooked, or worse - walked all over and ostracized. It takes someone not giving two shits, to change paradigms within a corporate culture.
That means people hard to get a long with. It means someone who more rigid and conservative management types don't want to tolerate. It means the "everyone holds hands and get along" leftist hipsters don't want to tolerate them.
Corporate culture enforces extreme compliancy to the group, in almost evey company.
People who play nice and are competent are necessary for smooth operations, but disruptive types who may even be accused of being "toxic" (as long as they have skillsets, judgement and insight) are also necessary. A company can't be filled wikth these types.
But filled with the polite hivemind? They're prone to stagnation.
I think being the my-ideas-are-better-than-yours guy, is having a better perspective that leads to conceptualising the whole problem differently. It can make everyone else feel inferior in a deep way. Being that guy is also hella frustrating, because doing things worse than they need to be done is frustrating. So you end up pissed at your colleagues or just thinking less of them. They pick up on it. Distance starts to grow. You end up in some little cliche in the office. Distance grows more. You end up being even more challenging. Distance grows more. And so on.
It just has a whole human process around it. Its rarely about a trick or two here or there.
They are so disingenuous, pretending a faux-surprise that innovation has to work against immense resistance in the workplace (and life in general). You have to be hopelessly naive and indoctrinated by ivory tower institutionalism to be surprised at the way real life works.
The next time you are on a management course which asks 'How do you foster innovation in the workplace?' or 'Do you see yourself as a rebel?' just write the obligatory guff and think of how you, the boss and your mates can have a few beers and work out how to shut down Bob, Sue or Jo because 'He / she's bright, sure, but his / her people skills could use a bit of work.'
I usually have 1-2 projects my manager knows about and is regularly tracking, then 2-3 "skunkworks" projects in various stages of development that get prioritized based on the word around the org. For example, I might hear from our data center team at a regular meeting that they need to buy 5% more racks based on current usage projections. I might have been working on optimizing a key data saving routine that reduces usage by 10% (fictitious numbers), so this gets bumped up in priority. So when my manager asks the team the following week if they have any ideas on how to improve our code, I've already got something halfway working. My manager (and I) get to look good, and I got to amortize the work across a few months instead of suffering through crunch time.
(Just a disclaimer, I do it too)
I don't think it's ever been secret in companies that I work for that devs don't spend 100% of their time on assigned tasks. There are always extra things like customer support, ops, urgent requests, unexpected refactoring that come up and have to be dealt with. Project managers I've worked with have mostly cared about the estimate being as accurate as possible taking into account these overheads.
At some point I stopped bothering. I can't worry about the company more than the company worries about itself. I think that's fair.
Should it be that way? No, but it sometimes is.
- George Bernard Shaw
- taking a fence down without knowing why it was put up
- CV driven development
- is/ought problem
- the French revolution :)
Opposition to change is not a bad thing, if isn't extreme (we're not changing anything for any reason no matter what). It forces change to justify itself and its costs, because there are always costs.
Personally I hate these kind of articles. They take a few survivor examples and extrapolate that X is good, -X is bad. In reality you can only move the cursor a little on the (-X, X) axis and observe the outcomes after a relatively long term.
Work on the critical path is visible and that, with the fear of the personal impact of failure can drive risk aversion behaviours in those engineers involved.
There are high performing rebels and low performing do-rights and vice versa.
As someone with past experience in a highly regulated field (biopharma, food safety, etc.), the rule-followers are running the show and a rebel (as the article defines it) will be burned out if they aren't careful.
However, that industry is ripe for disruption. The rules and best practices that have emerged over the decades have weak link to regulatory or legal sources. I would frequently ask for justification how a particular policy connected to an audit finding or a law and these connections are usually weak or non-existent. Even moreover, if the link could be established, it wasn't clear or documented why this decision taken was considered optimal for the organization, many times it was the fastest solution that made QA/QC happy.
As you can guess, the emergent systems are horribly inefficient yet difficult to change.
Highly-regulated industries are ripe with 'thats how we do it' inefficiencies that insiders have accepted as necessary for legal compliance but that could be disrupted by rebels that return to source material (legal statute, auditor interpretations) and reinvision the whole business model from the ground up.
BUT, most of them are absolute crap.
However the needle in the haystack? Is absolutely great. So the challenge is to not let yourself be led down the path of the crap ideas -- which happens more than what we would like to admit.
The fearful leader types, on the other hand, will leap at the first idea they have and then "pile on", in a grim white-fisted way, until death do they part from their idea. This leads to fucking chaos, and is generally why these types do not like new ideas but prefer incremental approaches. IMO.
A big revelation happened for me in 2006, when I was privileged to participate in a Pypy sprint. The Pypy codebase is by far the most creative and awe-inspiring codebase I've ever seen. At the time, Armin Rigo and his close collaborator (Samuel?) were spit-balling ideas for implementing a particular idea. These guys stood at the whiteboard and went through one spectacular genius idea, one after another, until they found something they really liked. I would have stopped at the first genius idea, but not these guys. That was a big lesson for me in programming and definitely lifted my game.
Start small.
You can write it down.
You don't have to finish it (now).
You should probably throw it away after a week.
Over time, you're more likely to find a different permutation of ideas that you had not considered before.
Other analagous platitudes.
Usually, in order to succeed, the “rebel” needs to have a lot of experience and good judgment. This generally comes from being older, and from surviving for a long time in the company; traits that do not necessarily suggest the rebellious attitude and courage needed.
- "Rebel Talent : Why It Pays to Break the Rules" by Francesca Gino
https://www.thriftbooks.com/w/rebel-talent-why-it-pays-to-br...
- "Originals : How Non-Conformists Move the..." by Adam M. Grant
https://www.thriftbooks.com/w/originals-how-non-conformists-...
- "Outliers: The Story of Success" by Malcolm Gladwell
https://www.thriftbooks.com/w/outliers-the-story-of-success-...
As a more experienced engineer, I am more accustomed to what is reasonable to "just go and fix" and what needs dicussion.
I have devs who sometimes spend 2 or 3 days+ doing something that could have been done much quicker if they had discussed what they planned first instead of trying to be helpful!
"Let's have a meeting about this in 10 days."
My experience is that you might get suggestions that are nowhere near how you planned to do it and it wrecks your mental picture of how it should be done. Discussions ofent lead to backseat development.
“Nobody Ever Gets Credit for Fixing Problems That Never Happened”
While I agree...
The first few years at my current company, they kept telling me I did really good work, but I was too slow.
Then we had a security breach, and then an audit. My code was the only code that they found no vulnerabilities in, and most of the rest of the code was riddled with them. (TBF, there have been security vulnerabilities in my code, they just didn't find them in that audit. I'm not perfect.)
Since then, they have never complained about me being slow.
While that's not credit for fixing problems that didn't happen, I think it's the closest thing out there.
As a small scrappy startup shipping is the absolute priority - get something out in front of customers, because the existential risk to the company is that you run out of money before you've got either a sustainable income or investment. Security might get some lip service paid, but ultimately who cares if your code is insecure when there's no customers who's data is at risk yet.
Over time the company will (hopefully) grow its customer base. Maybe you get some big B2B contract to fulfil. That's the point at which things like security audits land, and people start having to really care about security, because now there's half a million people in your databases, and if they get compromised you're going to be front page news.
You need different kinds of people as a company grows. The scrappy "get it shipped" engineers of the early days are going to find it increasingly difficult to function in a larger process focused organisation because its no longer just a case of sitting down over lunch to hash out a new feature before hacking something together in the afternoon. Process means that's now a multi-week process involving three different departments, followed by a month of waiting until the necessary people are available to actually build it.
I don't really have any good answers to that. I suspect small skunkworks like teams are probably a good first step to being able to retain those early engineers into the later stages of a company, but I've never had the chance to try it.
What people have a hard time understanding is that ideas themselves are not worth that much, they're at the top of a wide funnel which is narrow at the bottom.
Ideas are cheap, they evolve into more fleshed out concepts, which evolve into products which evolve into 'good' products. It's a very narrowing process.
For every successful rebel, there are many for whom it didn't work.
Operational competence, scale, market power ... those things are what really facilitate good ideas and make them worthwhile.
Example of a good idea without good execution: Minecraft. Billion dollar product that could have been made by any half competent game engine programmer with some game designer friend. If anyone have an idea like that I'd love to build it, but they almost surely don't.
Ideas down stay consistent through the funnel - they are mixed with other ideas and formed into something else unrecognizable by the time they hit the bottom.
You just described Minecraft as being a brilliant idea, not a bad one.
They will compete with you if you cannot let them serve you.
You propose some new solution that may be somewhat better, but the existing system was designed by someone who seeks a promotion and is owed a favor by a superior for some reason. They may have insecurities around their existing system and feel the need to justify their high position and salary, even if they are now not as productive as the youngsters, because they may now have a family etc and don't have as much time and energy or whatever.
In other cases the problem can be that the career risk-benefit balance is negative for the manager.
Or they are planning on dragging out the improvements in smaller jumps, to demonstrate constant improvement over many years to optimize career advancement. If the improvement happens all at once and suddenly, it will look too simple and less credit that can be squeezed out of it.
TLDR improving things can make some people look bad and they will fight you.
People are not dumb. They know politics of situation they work in. These people were not random renegades ignoring any authority on principle or some such.
I think this is a crucial distinction - the “rebels” are biased towards improvement.
However, I’ve also seen rule breaking tolerated in organizations as a means of maintaining the status quo which leads to complacency rather than progress.
https://www.ted.com/talks/shoel_perelman_how_a_company_can_n...
If you are successful in your argument and convert sufficient numbers to aim at heresy, then "be a heretic" becomes the new orthodoxy. When that happens, "be orthodox" will be the new heresy, and it will be impossible not to be a heretic: the orthodox will aim at heresy, and those aiming at orthodoxy will be heretical.
The price of success in philosophy is triviality. -- Clark Glymour
It is in your career's best interest not to be too rebellious.