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.
> 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.
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.
> 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.
I find that boxed thinking quite problematic. Plenty of great solutions came without loyalty or optimism. Why did we throw positive thinking into the mix of otherwise confrontantional systems.
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.
both of these are difficult to act on or enable if management doesnt make it worth while to do so (because of blame, micromanagement, politics etc)
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
BTW, for the down-voters, this was rhetorical question and not a personal attack. The GP comment created this dichotomy and I was just pointing it out.
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".
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.
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.
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.
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.
that can lead to a lot of toxic situations and is not sustainable long term; it breaks expectations all across the board of fair arbitration that a manager/leader is supposed to do
Well that’s a ceo culture responsibility to not make themselves a bottleneck. Generally this is done by delegating more decision making expectations downward.
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.
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.
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.
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.
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.
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.
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.
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.
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]
> 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.
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.
>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.
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.
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.
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.
>>> 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'
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 ;)
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.'
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.
Well, I like the extremity of your point, its instructive. However, I think challenging the majority usually comes with more baggage than just volunteering better ideas.
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.
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..
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.
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.
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.
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.
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.
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?
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.
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.
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?
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.
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.
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.
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'.
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.
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.
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.
'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.
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.
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.
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.
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.
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.
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.
Yep. There's probably a function that describes this. Since I started experimenting in games development and design, I've learned that ideas are like a daily crossword puzzle (or a similar analogy).
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.
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.
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.
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!
> 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.
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.
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”
“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.
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.
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.
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.
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.
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.
That idea was made by an extremely competent programmer. It was called InfiniMiner and it exactly fits the mold you've provided. Minecraft was then executed on it to an astounding creative success.
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.
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.
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.
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.
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.
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!
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.
>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.
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.
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.
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.
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.