[HN Gopher] 'Positive deviants': Why rebellious workers spark gr...
___________________________________________________________________
'Positive deviants': Why rebellious workers spark great ideas
Author : sonabinu
Score : 276 points
Date : 2021-06-14 03:06 UTC (19 hours ago)
(HTM) web link (www.bbc.com)
(TXT) w3m dump (www.bbc.com)
| bernardlunn wrote:
| Machines ie robots are always obedient. Humans are not - phew!
| eric4smith wrote:
| In my experience "rebellious" workers provide many, many, many
| ideas.
|
| 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.
| mathgenius wrote:
| I consider myself one of the rebellious workers, and fully
| admit most of my ideas should be thrown out the window. I spend
| a lot of my time ruthlessly invalidating those ideas. The most
| difficult are the ones that cannot be immediately disposed of,
| they can sometimes linger on for years.
|
| 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.
| yawaworht1978 wrote:
| Sometimes the one with the idea cannot know other, interwinded
| procedures which would break if his idea was implemented. If this
| happens all the time and/or a product manager tells you to submit
| a ticket and the review does not happen within 6 months, if it is
| forcing you to do repetitive tasks and you can find better
| compensation elsewhere......run as fast as you can.
| okareaman wrote:
| You might have a great idea if an unusually high number reject
| your idea for no good reason. On the other hand, you know you had
| a great idea if your boss takes credit for it.
| chiefalchemist wrote:
| Three books come to mind:
|
| - "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-...
| trabant00 wrote:
| The devil is always in the details and the road to hell is paved
| with good intentions. Only in retrospect can you verify the
| "great" part in great idea. Until then you only really have an
| deviant idea which could be:
|
| - 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.
| arcanon wrote:
| Who exactly is characterizing the workers with great ideas as
| rebellious, here? The real story is always parasitic toxic
| management. An idea's existence is enough to threaten power
| structures.
| renewiltord wrote:
| The revelation that sparked Silicon Valley is that you can either
| permit your rebellious workers to power you to great heights or
| you can let them leave to eat your lunch.
|
| They will compete with you if you cannot let them serve you.
| _trampeltier wrote:
| It's not just about rebellious. It's also about just about "just
| do something about it" without asking the boss/teamleader. The
| problem is often just how much free time you have on work to do
| such things. Another problem is, if you fix small things allways
| by yourself in the background, the real problem might stay
| forever.
| lbriner wrote:
| This is true but also where wisdom comes in. It should be OK to
| spend 5 seconds saying, "I saw X, is it OK for me to fix it?",
| which allows people to know of a problem they might not know
| and also for management to say, "Don't bother, we are going to
| replace that next month".
|
| 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!
| rightbyte wrote:
| > 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!
|
| 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.
| varjag wrote:
| > It should be OK to spend 5 seconds saying, "I saw X, is it
| OK for me to fix it?"
|
| "Let's have a meeting about this in 10 days."
| dukodk wrote:
| Seems like a low risk test, it's kinda a no-brainer. They used
| their free time and they had it running alongside the main
| program. Have to remember if they didn't have the comparison, I
| don't think it would be as good a story.
|
| "Nobody Ever Gets Credit for Fixing Problems That Never Happened"
| wccrawford wrote:
| "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.
| jon-wood wrote:
| I have a slightly different interpretation of this, and it
| comes down to the horrible manager-ese phrase "risk
| appetite".
|
| 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.
| wccrawford wrote:
| I don't disagree about the company's needs changing, but
| they'd already recognized that need when they hired me. But
| they didn't actually recognize how well I was fulfilling
| those needs until the audit.
| elevenoh wrote:
| Getting through engineering education alone can be enough to kill
| the rebel in many.
| jarl-ragnar wrote:
| As an engineering manager I've found that the most innovative and
| impactful work is usually done when the pressure of being on the
| critical path for delivery is absent. One way to achieve this is
| to do the work under the radar and only expose it more widely
| once it's at a point where the benefit is easier for general
| management to see.
|
| 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.
| wsgeorge wrote:
| It's pretty cool that a comment in this same thread said they
| do this exact same thing:
| https://news.ycombinator.com/item?id=27499731
| bonoboTP wrote:
| The main point is missing from the article: such rebels threaten
| the authority and career of seniors or other power dynamics at
| the organization.
|
| 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.
| lnsru wrote:
| It's very romantic about these pirates. But what if the flight
| director was not leader from ancient times? I really like HP way
| and other antique management theories. But now I meet very often
| people that are really really comfortable in their management
| positions and only care about their compensation. Every
| rebellious idea is a risk project for them and must be killed
| ASAP. From I own experience I can say one thing: don't rock the
| boat. In different organizations the risk level varies. Wanna
| risk and rebellion - start your own company!
| watwut wrote:
| I think that they knew there is reasonable chance the director
| might support them and trusts them. They worked on this system
| for months, it is unlikely that "legendary leader" found about
| whole thing when they walked into mission control. They did not
| knew whether whole thing will succeed overall, but at minimum
| they did had pre-existing trust.
|
| 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.
| dotancohen wrote:
| The TED Talk on "internal rebels" within a company was
| extraordinarily insightful.
|
| https://www.ted.com/talks/shoel_perelman_how_a_company_can_n...
| ChrisMarshallNY wrote:
| I love to hear about successful rebels, but for every success,
| there are _many_ failures. Some, quite spectacular (google "Nick
| Leeson").
|
| 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.
| bumby wrote:
| > _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._
|
| 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.
| throw737858 wrote:
| Coworkers get together, and in their spare time reimplement
| entire system, but 10x better. They love their work and are
| "true" hackers... all very romantic. That is not how it works.
| Today it is about politics and preventing other people from
| ruining your work.
|
| In ideal world incompetent managers would get fired, and workers
| would get their salaries. But that is not how it works. Just the
| fact they are called "deviants" or "rebels" tells it.
|
| So if you are 10x at something, start your own consulting
| business. Do not work for morons.
| whereistimbo wrote:
| But that thing could also backfire. That reminded me of
| organizational chart that show divisions in Microsoft pointing
| gun at each other[0].
|
| [0]: https://bonkersworld.net/organizational-charts
| fooker wrote:
| There is just deviance, no positive deviance or negative
| deviance. You can't put a filter for this.
| bitwize wrote:
| For most companies, "rebellious workers" are a problem easily
| solved with issuance of pink slips.
|
| It is in your career's best interest not to be too rebellious.
| whatshisface wrote:
| The fact that offering an idea that's better than what's already
| being done is seen as rebellious at all, as opposed to being the
| entire job of an engineer, or the definition of what engineers
| do, is not a good sign for any organization.
|
| 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.
| ramraj07 wrote:
| There are two types of ideas, one is the practical improvement
| that can and should be heard and considered seriously, and then
| there are the "great ideas" which a lot of engineers are happy
| to spew out, but are often unable to follow through because
| they think more highly of themselves than they ought to. The
| reality is that software fields are brimming with people who've
| been paid exorbitant sums for mediocre work from people who
| wouldn't otherwise even qualify as above average in general
| intelligence. If the teams don't listen to engineers often it's
| at least partly because of such past experiences.
|
| 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.
| afarrell wrote:
| Or they are unable to follow through because engineering is a
| team activity and so they _cannot_ follow through if people
| don't listen enough to consider the idea.
| [deleted]
| _0ffh wrote:
| One of the drawbacks of managers who are not good engineers
| themselves is that they lack the ability and knowledge to
| distinguish between truly excellent talent and pretenders.
| That's an organisational deficiency.
| alex-mohr wrote:
| For a decent take on that organizational deficiency,
| Rickover wrote a 1.5 page memo in 1953 addressing similar
| issues for the nuclear US Navy. At some point, it's a
| failing of process and structure rather than people. [1]
|
| 1: http://ecolo.org/documents/documents_in_english/Rickover
| .pdf
| bumby wrote:
| > _then there are the "great ideas" which a lot of engineers
| are happy to spew out, but are often unable to follow
| through_
|
| 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.
| crispyambulance wrote:
| > 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.
|
| 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.
| gopalv wrote:
| > The fact that offering an idea that's better than what's
| already being done is seen as rebellious at all, as opposed to
| being the entire job of an engineer, or the definition of what
| engineers do, is not a good sign for any organization.
|
| 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.
| spullara wrote:
| I have found that the best engineers gain the ear of senior
| management (generally far above their manager) and can push
| through their radical ideas from above. You really have to
| also be able to do the work and show that it is going to
| work. Thinking and acting strategically or as I like to put
| it "act as founder".
| slumdev wrote:
| This is not indicative of engineering skill.
|
| 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.
| caseysoftware wrote:
| Manipulating - aka taking advantage of someone - is bad
| and leads to what you describe.
|
| Building trust and understanding among colleagues is
| ALWAYS good.
| lifeisstillgood wrote:
| But that's not being an engineer. That's being a senior
| manager.
|
| 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.
| fsloth wrote:
| I think you are complecting peoples with processes.
|
| 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.
| mtberatwork wrote:
| It sounds like you are describing a tech/project lead,
| which, depending on the context, can be a thankless task.
| The organization gets free project management/strategy
| out of you without any increase in compensation, title
| change or added authority and with the expectation to
| still perform all programming work of a senior engineer.
| It's a line that engineers need to walk carefully,
| otherwise you will find yourself doing two full time jobs
| and burnout will hit you rather quickly.
| rjsw wrote:
| Another danger is that the senior management can change
| without passing on the knowledge of the informal networks
| that were in place.
| lifeisstillgood wrote:
| The whole reason for hierarchies (and democracies) is to
| avoid this "listening" crap anyhow.
|
| 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
| dv_dt wrote:
| Well that's a ceo culture responsibility to not make
| themselves a bottleneck. Generally this is done by
| delegating more decision making expectations downward.
| nicoburns wrote:
| That's why they're not listening to everyone. They're
| listening to those who have managed to get their ear.
| rjsw wrote:
| It doesn't have to be driven by the engineer. I have been
| in this position, The CEO would join me for lunch every
| couple of weeks for a chat about future directions and
| current sales leads.
| spullara wrote:
| I fundamentally disagree that you become a manager
| because you can influence the company. Manager's manage
| the projects and the people but should have very little
| control over what the company actually does and what
| projects are chosen. That should be the domain of the
| product and engineering team themselves.
| groby_b wrote:
| There are many different types of managers, and "General
| Managers" are a thing. I.e. they drive product, eng, and
| UX. Ultimately, every CEO is that kind of manager, and
| they have to be. You can't just lean back and say "eh,
| people will figure it out, I hired accordingly".
|
| 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.
| balabaster wrote:
| A savvy engineer, like a spy, knows how to gain the
| confidence of the CEO long before they put a plan of
| "Gee, I think you should do this" in the CEOs ear. I've
| spent months ingratiating myself with the political
| circle before someone says "Hey Ben, what do you think?"
| and from there, it's game on.
|
| 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.
| caseysoftware wrote:
| ^ This is the secret sauce of Sales in all forms.
|
| 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.
| endymi0n wrote:
| Pretty much spot on. The very best engineers often have a mix
| of technical excellence, courage / nonconformism and loyalty
| / optimism.
|
| 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.
| birdyrooster wrote:
| Very best engineers, nothing, and disasters. Which are you?
| geoduck14 wrote:
| > The very best engineers often have a mix of technical
| excellence, courage / nonconformism and loyalty / optimism.
|
| 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.
| NoOneNew wrote:
| This isnt about proper management methodology. This is about
| better ways at redirecting blame away from leadership. "No, the
| project didnt fail because I micromanage, overwork my crew,
| create artificial roadblocks, drown in arbitrary meetings and
| in general am a cunt. No, no, no, my team just wasn't properly
| in the rebellion spectrum to accomplish the task. I need a pay
| raise and a bigger budget."
|
| Seriously, 80% of good leadership is someone doing honest self
| reflection after a decision, "if I was them, would I think I
| was a piece of shit?" Yes, in that language, because being
| crass is being honest. If so, alter the decision. If not, its
| probably an acceptable decision by the crew. A one page primer
| in terms of how not be an asshole as a leader is far more
| honest and effective than all these over intellectualize mental
| masturbation studies combined.
|
| Mutual respect and trust between leadership and the crew is
| what makes effective teams. But hey, that takes work,
| knowledge, compassion and fraternization. You know what doesn't
| take work and all that other hard stuff? Bullshit checklists.
| Then you can show how it's the plebs' fault, not yours.
| goto11 wrote:
| Ideas are cheap. Investing in following a particular idea is
| costly and risky, especially since this also have to
| opportunity cost of not following a range of other ideas, given
| any business have limited resources.
|
| 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.
| jonplackett wrote:
| The other inertia is that companies are usually already doing
| something that is quite profitable. And all the people
| they've hired are good at doing the things that make the
| company profitable. It takes long-term thinking to see that
| it won't last forever.
| shoto_io wrote:
| I absolutely agree, and at the same time it's how large and (!)
| mid-sized companies often work. And it's not only management
| that behaves like that but many employees as well.
|
| 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.
| lifeisstillgood wrote:
| >>> 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'
| shoto_io wrote:
| Yeah, thanks for the reminder. I realized that a bit too
| late. But: In a company it's also way more difficult to
| identify who is American and who is British ;)
| lifeisstillgood wrote:
| Its easy: We Brits swear waaay more!
| peterkelly wrote:
| My thoughts exactly. This sentence really struck me as a
| strange thing to write:
|
| > _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?
| mtberatwork wrote:
| I can guarantee you the company does not feel the same way
| about the `rebel with a cause` as the rebel feels about the
| company, especially when times get critical. Unless you are
| the founder, it's best not to get too caught up in mission
| statements.
| DocTomoe wrote:
| And even founders are not completely immune. See Steve
| Jobs, ca 1985
| Aeolun wrote:
| > If you don't feel that way about your work, then what the
| hell are you even doing there?
|
| I think it's possible to care about doing a good job without
| caring about the company.
| astura wrote:
| Um... Working? Presumably.
| throwaway87163 wrote:
| Not every job can be a passion. Sometimes people just need
| the money and are only there because of it.
| Dudeman112 wrote:
| Working in a pleasant job for enough money to live
| comfortably, of course.
|
| Drink the Silicon Valley kool aid with moderation.
| coldtea wrote:
| > _is not a good sign for any organization_
|
| On the other hand reality doesn't operate optimally.
| wisty wrote:
| I think this part of the answer to the Theory of the firm (this
| weird thing where companies seem to do better than work from
| home gig economies).
|
| 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.
| TheOtherHobbes wrote:
| Risk taking is only a problem if it demands resources that
| would starve other known-good projects.
|
| 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.
| heywherelogingo wrote:
| This just sounds like the UK to me - anal retentive and
| compliant, so no surprise coming from the BBC. Short back and
| sides, suit, pointy shoes, don't stick your neck out.
| samjewell wrote:
| I've worked my whole career in the UK (7 years software eng,
| plus a bit in other jobs). Sounds from your comment like
| you've had better experiences in other countries. Is that
| right? Which ones, and how?
| loudtieblahblah wrote:
| it's this very fact, that bucking the normative or bucking the
| convention within an organization is why I've always argued for
| "assholes" or disruptive types who can back up their attitude
| with what they can bring to the office.
|
| 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.
| rukuu001 wrote:
| The status-quo is 'the work'. It's what's measured to determine
| how effective employees are. New ideas are a threat to that.
| rantwasp wrote:
| it's one thing to offer an idea or point out something could be
| done in a different, better way. completely different when
| you're told it's not gonna be done that way but you go ahead
| and do it anyway.
|
| 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.
| xwolfi wrote:
| Depends what you call a better idea. You know surely as much as
| me that we engineer will propose maybe better concept but would
| lack possibly in sales acument, value production vs cost,
| market timing, optimal quality (sometimes a client really
| doesnt care about a quality increment at all, while you could
| have spent your time on something else more rewarding), etc.
|
| 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.
| jakupovic wrote:
| >Depends what you call a better idea.
|
| 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.
| 4gotunameagain wrote:
| We are also talking about space, a notoriously risk averse
| sector, where innovation is allowed to exist only where
| absolutely necessary, or in technology demonstration missions.
|
| Unfortunately when failure is not an option, taking risks is
| even more risky..
| Fordec wrote:
| Interesting fact, 80% of satellites are now built outside the
| US. A surprising number of cubesats are built in the UK for
| example. The US regulatory framework, which has decades of
| legacy and history working with the likes of Lockheed has
| frozen the industry in the risk aversion. Only in the last
| five years have satellites been removed from the munitions
| list. Have fun with all the legal paperwork to hire an
| immigrant to work on a space project.
|
| Most of the work is now done elsewhere in places that don't
| have a space legacy, because of this exact risk aversion.
| geocrasher wrote:
| I thought we called those "hackers".
| whereistimbo wrote:
| That reminded me of my own thought/opinion why China would be
| forever copycats compared to the US. At least the difference can
| be seen in China vs Taiwan. One is a suppressive government, and
| another one is a democratic country.
| mylons wrote:
| Siri, play Vindicated by Dashboard Confessional
| georgeburdell wrote:
| I'm by no means a prominent employee within the company, but I am
| unusually well-remunerated for my role. I attribute this to
| hiding about 1/3 of what I do from my manager until it's ready to
| demonstrate.
|
| 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.
| fleischhauf wrote:
| So you work in some scrum framework with tasks and sprints? I
| wonder how feasible that is in frameworks like that
| Aeolun wrote:
| I'm sorry, my task just isn't done yet, it is much more work
| than was estimated.
| sumtechguy wrote:
| Scrum does not mean 100% of your time is tracked. You usually
| have some % of time dedicated to your tasks. I usually pick
| 70% as that works pretty good for me. It allows for '30%
| other' to get in there and not having to track every detail.
| If something becomes big enough I bring it to the team and
| say 'hey I would like some dedicated time to work on this
| lets add a story to the board'.
| aqme28 wrote:
| In my professional experience, scrum often means that 100%
| of your time is tracked.
|
| Should it be that way? No, but it sometimes is.
| nicoburns wrote:
| Easy enough in my experience. You just build in time for
| these projects into your estimates.
| newswasboring wrote:
| Isn't that cheating the system though? Giving an inflated
| time estimate is lying to your team. While this gets the
| job done, I don't think it should be encouraged.
|
| (Just a disclaimer, I do it too)
| nicoburns wrote:
| I guess I just see it as part of doing my job. I wouldn't
| be able to do it effectively if I didn't do this.
|
| 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.
| lostcolony wrote:
| The places I've worked that required time estimates (the
| wrong way to do it) still built in an overhead factor of
| ~30-40%. I.e., recognized that a dev would only put in
| 4-5 hours of 'coding' a day, with the rest taken up by
| meetings and random miscellany.
| lostcolony wrote:
| 'An inflated time estimate' - well there's your problem.
| If it's a point estimate, as it should be, it's quite
| easy to do. Your 'real' velocity may be 10 points, but
| your planned velocity is 7. That not only gives you a
| little buffer in the event of something unexpected (so
| you're less likely to miss a sprint commitment due to
| things your team controls), but in the event nothing
| takes that time, it's free time to work on what feels
| important.
| newswasboring wrote:
| The only way I've found innovation happening in scrum is by
| cheating the system. Either by inflating time estimates or
| attaching your idea to something which is just a by product.
| papito wrote:
| Right, but the ultimate goal is to _help_ the company
| succeed and save it from itself and its management, which
| is just ass-backwards.
|
| 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.
| [deleted]
| [deleted]
| andyjohnson0 wrote:
| The way you describe your role sounds like the way a Technical
| Fellow is supposed to operate within an organisation.
| nobrains wrote:
| There is a fine line between those rebellious workers who give
| good ideas and then take ownership of their idea till the end,
| and those who throw ideas out, but don't want to have to do
| anything with implementing those ideas. No one likes the latter.
| drewcoo wrote:
| The reasonable man adapts himself to the world: the unreasonable
| one persists in trying to adapt the world to himself. Therefore
| all progress depends on the unreasonable man.
|
| - George Bernard Shaw
| jollybean wrote:
| Ideas are not that hard really.
|
| 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.
| username90 wrote:
| Good ideas are ridiculously hard to find really and also
| extremely important. However most people with ideas don't have
| good ideas, and they can't recognize that their ideas suck so
| we tell them that ideas doesn't matter rather than the truth
| that their ideas suck.
|
| 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.
| jollybean wrote:
| This is upside down.
|
| 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.
| js8 wrote:
| Um, Minecraft was executed very well. Maybe not as
| technically advanced as it could be, but Notch had a very
| good grasp on the player loop (you explore, you get
| resources, you build something..) and his artistic choices
| had a certain "poetry" (take now iconic creeper as a
| canonical example), which I think greatly contributed to the
| success of the game.
| dorkmind wrote:
| I would argue that outright heresy is the way to go; rebellion
| only gets you so far.
| ARandomerDude wrote:
| Ironically, if you succeed in your argument that heresy is the
| way to to go, you'll find yourself in a logical absurdity.
|
| 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.
| thanatos519 wrote:
| That reminds me of this:
|
| The price of success in philosophy is triviality. -- Clark
| Glymour
| dorkmind wrote:
| This is also said of mathematics, but rather when the
| student is successful in learning a theorem.
| jesus147 wrote:
| Thanks for sharing such great information, the post you published
| have some great information which is quite beneficial for me.
| https://www.myloweslife.biz/
| hermannj314 wrote:
| In my career, I have seen individuals all over the map if the
| x-axis is rebelliousness and the y-axis is value delivered.
|
| 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.
___________________________________________________________________
(page generated 2021-06-14 23:02 UTC)