3 ms·

As a veteran in this field, I find myself not trying to ask permission as much for new ideas that I can do on my own. Multiple times in the past I have done my

As a veteran in this field, I find myself not trying to ask permission as much for new ideas that I can do on my own. Multiple times in the past I have done my own ideas,while getting feedback from peers and those that are affected, but generally leaving management out of it and not seeking permission. Some ideas panned out, some did not. But I had a great time, got satisfaction from my work, grew and learned. Then other times I would get into this mode where I want to get permission and let managers in on what I am doing. At first it starts out OK. You scale back your ideas due to their concerns. Then you get redirected... "maybe later but now i want you do focus on this". Eventually it leads to a new job. I think this article helped me pinpoint this pattern, even though I suspected it. It is a balancing act. You do not want to waste company time with oddball ideas, and some of your ideas will be oddball. You need to seek feedback on them so that they can be improved. You need freedom to try them out, and fail. I think this article is good for both managers and developers. Developers should know that this pattern is real, and there are things you can do to protect yourself from going down this path. For me, its basically not always asking for permission to try stuff out... take a risk and believe in yourself, but also get feedback to filter out oddball ideas that waste time.

golergka 9y ago
As a (relatively) young less developer, I love it if my team members put on their own initiative – as long as it doesn't affect the deadlines dramatically. Sometimes developers want to implement the feature they're working on in the best possible way, while what there project really needs instead is ten different features, implemented just well enough.
stuaxo 9y ago
Definitely second this. Taking risks like this is the only way I've kept the job interesting, and managed to make the projects actually good. The downside is when it doesn't pan out, you can have a bit of catching up to do.
- jmartrican 9y ago
  > The downside is when it doesn't pan out, you can have a bit of catching up to do. That is so true as I am catching up now on a Saturday. You also learn to not roll your own solutions and check a second or third time for a solution on Github or open source community.... and check again if you don't find it.
- vbezhenar 9y ago
  I'm doing that too and I'm always extending my estimation of work to include those potential researches. Smart people said, estimate work to be done and multiply it to Pi. If I'm feeling uncertain, I'm additionally multiplying it to E. Result estimation might be a bit pessimistic, but I've found that it's better than wrong estimate resulting in missed deadlines and work at nights.
throwaway123785 9y ago
(throwaway because I don't want to identify the company) That works for some things, but not the others. For instance, right now I can almost mathematically prove that we're building the wrong thing, starting from 2 very "common sense" and reasonably easy-to-believe "axioms". I have no trouble convincing fellow engineers that we're not building the right thing, but that's more harmful than useful. I've managed to convince some director-level people, but trying to bring this up to VP-level yielded clear warning signs that not only will I achieve nothing, but it's going to be a career limiting move. The Upton Sinclair quote is quite true - "It is difficult to get a man to understand something, when his salary depends on his not understanding it." In the meanwhile, my company spent in excess of two years, and increasingly more resources trying to build the same thing and being not an inch nearer to their true goal - I wonder how soon till the outside world starts to notice. The CEO is frustrated because the strategy is sound and he doesn't get why it's not getting done. In the meanwhile, trying to tell to the VP that the tactics is wrong (and how it's wrong, and how to fix it) gets you the axe. It's messed up, but all I can do right now is say "it's not my job to fix this mess" and play along with it/ learn interesting technologies & cash my cheques. :(
- deleted 9y ago
  [deleted]
scarface74 9y ago
It doesn't have to be a balancing act. When I know Im going off the rails and trying to implement an idea that might not pan out, I'll do it in off hours. Yes I might be doing "free labor" but I'm usually scratching and itch and the learning process helped me. I've made the mistake recently of being too detailed an open about the joe and it's come back to bite me since we have "gone agile". I try to be as vague as possible now. The less they know the better. We do have Code reviews by the "dev lead" since most of the other developers are junior, but luckily, I am the "dev lead".
maxxxxx 9y ago
I try to do something like "80/20" in my team. 80% of time goes to current issues and 20% goes into refactoring or experiments. Management never sees this, it's just part of the regular estimates.

golergka 9y ago

As a (relatively) young less developer, I love it if my team members put on their own initiative – as long as it doesn't affect the deadlines dramatically. Sometimes developers want to implement the feature they're working on in the best possible way, while what there project really needs instead is ten different features, implemented just well enough.

stuaxo 9y ago

Definitely second this. Taking risks like this is the only way I've kept the job interesting, and managed to make the projects actually good. The downside is when it doesn't pan out, you can have a bit of catching up to do.

jmartrican 9y ago
> The downside is when it doesn't pan out, you can have a bit of catching up to do. That is so true as I am catching up now on a Saturday. You also learn to not roll your own solutions and check a second or third time for a solution on Github or open source community.... and check again if you don't find it.
vbezhenar 9y ago
I'm doing that too and I'm always extending my estimation of work to include those potential researches. Smart people said, estimate work to be done and multiply it to Pi. If I'm feeling uncertain, I'm additionally multiplying it to E. Result estimation might be a bit pessimistic, but I've found that it's better than wrong estimate resulting in missed deadlines and work at nights.

throwaway123785 9y ago

(throwaway because I don't want to identify the company) That works for some things, but not the others. For instance, right now I can almost mathematically prove that we're building the wrong thing, starting from 2 very "common sense" and reasonably easy-to-believe "axioms". I have no trouble convincing fellow engineers that we're not building the right thing, but that's more harmful than useful. I've managed to convince some director-level people, but trying to bring this up to VP-level yielded clear warning signs that not only will I achieve nothing, but it's going to be a career limiting move. The Upton Sinclair quote is quite true - "It is difficult to get a man to understand something, when his salary depends on his not understanding it." In the meanwhile, my company spent in excess of two years, and increasingly more resources trying to build the same thing and being not an inch nearer to their true goal - I wonder how soon till the outside world starts to notice. The CEO is frustrated because the strategy is sound and he doesn't get why it's not getting done. In the meanwhile, trying to tell to the VP that the tactics is wrong (and how it's wrong, and how to fix it) gets you the axe. It's messed up, but all I can do right now is say "it's not my job to fix this mess" and play along with it/ learn interesting technologies & cash my cheques. :(

deleted 9y ago
[deleted]

scarface74 9y ago

It doesn't have to be a balancing act. When I know Im going off the rails and trying to implement an idea that might not pan out, I'll do it in off hours. Yes I might be doing "free labor" but I'm usually scratching and itch and the learning process helped me. I've made the mistake recently of being too detailed an open about the joe and it's come back to bite me since we have "gone agile". I try to be as vague as possible now. The less they know the better. We do have Code reviews by the "dev lead" since most of the other developers are junior, but luckily, I am the "dev lead".

maxxxxx 9y ago

I try to do something like "80/20" in my team. 80% of time goes to current issues and 20% goes into refactoring or experiments. Management never sees this, it's just part of the regular estimates.