5 ms·
Exactly this experience happens in big teams internally as well. It works like this according to my experience: You see a problem before it really does financi
by erikb 9y ago
Exactly this experience happens in big teams internally as well.
It works like this according to my experience: You see a problem before it really does financial harm to the company. You start developing a solution. You expect to get rewarded with prices, raises, titles and public encouragement, because you solved the problem before anybody even saw it.
But instead this will happen: The employees who run into the problem first and therefore would be the one who suffer from it, find that your solution may be an answer. But instead of making it work they find ways to complain about it publicly. Since management hasn't yet realized that there is a problem, they just hear that you are not doing your job and put pressure on you to fix all the bugs, because of your bugs nobody else can work, so it seems.
This is not stupid by the other people or by accident. The moment they have found a way to complain about you it doesn't matter anymore if the task will be successful or not, since a failure wouldn't be blamed on them anymore as well. Everybody knows that the bugs are your fault, right?
In this regard open source seems less harmful to me. In open source at least there is no boss who can push you to solve the bugs, or fire you if you don't.
- BeetleB 9y agoI had somewhat a similar experience in a previous job. Automated a lot of stuff to speed up our workflow. Never got anything material out of it (bonus/raise, etc). The reward was an expectation to increase our output ("Now that it takes half the time to do X, everyone should double their output.") The other reward was maintaining my code while expected to double the output. At one point the manager made it clear I would not get a promotion based on this. I left, and in my next job I tested the waters a little to see if they'd value such contributions. They did, and so I happily continue to make them. Had they not, I would have stopped quickly and moved on to another job. As an engineer, my job is to solve problems that need to be solved. I could be like everyone else and just go along with it (not solve them and maintain the status quo), but that's not why I became an engineer.
- icebraining 9y agoCompanies are generally hierarchical systems. By developing the solution on your own initiative, you bypassed that. You should never expect a good reaction from a social system when you break its rules, even if for its own benefit.
- cname 9y agoOne thing that's so confounding about this is that so many hierarchical organizations (companies, non-profits, universities, etc) encourage "initiative", but then when you take that initiative, you may/often catch shit for it, even if you're doing the right thing from an objective point of view. Of course, there are complex politics at play and the reaction you get depends on largely on "who you know" and if you effectively kiss ass.
- icebraining 9y agoThere was a semi-famous author in my city who did that on a personal level: he would ask his friends to keep part of his paycheck until a certain day, and not give it to him even if he asked, since he knew he'd misspend it all (often by just being generous to friends and people in need). More than once, not only did he ask for the money before the date, as upon being denied, he went around in coffeeshops and bars defaming them, telling people they'd stolen from him, etc. If even individuals can be this inconsistent, we shouldn't be surprised that companies - composed of multiple private interests, as many as their employees and board members - exhibit similar behaviors.
- erikb 9y agoThis was also hard to understand for me. But think about all the benefits people in higher positions have if people in lower positions take initiative. The higher ups can reap most of the rewards of successes while blaming all failures on the initiating people. Of course they like it if you offer such gifts for them.
- justQuestion2 9y agoI wonder what is the best strategy to this problem: You take the initiative and develop a new feature, automate a task, increase productivity, optimise costs, or increase revenue. You would like to reap the benfits (promition, bonus) but not increase your workload or take the blame for bugs that are unavoidable in the new tech. 1. Automate tasks and keep it to yourself or your immediate team and hopefully work less. 2. Talk to your boss before you reveal your solution, such that he will 'discover' it and let it be his idea. Depending on your idea, this might be hard. Any other ideas?
- raarts 9y agoDevelop your solution but don't actually implement it. When the problem is discussed offer to fix it in a short amount of time (faster then the actual time). Everybody will remember you as the one being most profitable for the company.
- philipov 9y agoThe way to handle this is to develop the solution, but don't reveal or pitch it yet. Instead, position yourself to hear about it when people start recognizing the problem and start looking for a solution. Then, be the one to solve their problems, and that's the kind of initiative that gets rewarded. Success depends on not just having the solution to a problem, but having it at the right time as well, when the market is ready to adopt it.
- adrianratnapala 9y agoI sympathise, but there is a flip-side. Code bases, get full of half-arsed framekworks and automation tools that nominally solve all your problems, but don't, either because they address the wrong issue, or because bugs prevent them from doing even the nominal job. Yet these half-working things can become the required internal standard that teams have to adopt against their wishes. They will not be forgiving when the maintainers start ignoring bug reports. Now this is fundamentally a management failure: pushing a solution without knowing its limits or counting the cost of backing it up and compensating the maintainers. But as engineers we tend to be complicit, because when we make a new shiny thing, we also want to push it and don't want to tell mangement that it will really cost three times more than they were hoping.
- regularfry 9y agoIn big companies (in my experience), projects are owned and funded, or they don't really exist. In the case of a side project that doesn't get official support, there is a perfect response pre-made for this situation: "Why are you depending on an unsupported package?"
- jackgolding 9y agoYup I agree, working in a product team however one thing I will consider a red flag with projects is internal costings (i.e. having to "hire" devs from other teams for a certain dollar amount), however I understand the importance of getting other teams to "buy in"