I am relatively young and I am certainly early in my "career" but I think that I have come to some fairly powerful conclusions for myself in the working world that I think might be valuable to share with others. I have spent some time bouncing around corporate space as well as some time consulting and have consistently come up against the following question: When is it time to bail out and find a new position?
The question is one of those questions that nags at you while you are working when things are not going quite the way you thought or if you are new in the position, not what was advertised to you when you got hired. This single question can actually drive you mad as you sit and contemplate it because the thought of changing jobs of potentially going for some period of time without an income is scary. It is nerve wracking to think that by leaving a job you might not be able to make it long enough to find a new one before money gets tight and things start to weigh on you like a 1000 lbs. gorilla sitting on your back. So - like the question said, when is it time to go.
What I have decided is that it is time to go when you can no longer bring anything to the table that will help the company. This ability to help can take many forms - it can be your feed back about what the processes that the company is using are doing, it could be simple things that would make things you do every day faster. Things that can help can even take the form of off handed comments to your boss about the people and processes that you work with twice a month. So - why do I think that this is the best indicator that it might be time to leave?
My biggest reason for this is thinking that a job is not just about money, a job is about your talents and doing something that you should (SHOULD) enjoy doing. Think about it - we spend a good portion of our days toiling in the jobs that we are in, WE SHOULD be happy while we are doing it. This is not to say that we will always be happy because the world is just not that way. It is more to say that we should endeavor to improve what we do for ourselves and the company. We spend too much time working as it is to HATE going in to work every single day. Each one of us has the power to effect change no matter how small that change is. We should use that power to improve what we do. When our voice ceases to be heard in any meaningful way it is most likely time to move on. Life and time is too short to feel undervalued or not valued at all.
Why? Because, the world is supposed to be constantly changing - when it stops changing something is wrong. Same thing holds true for jobs, when you can no longer improve the situations that you have to deal with it is time to find a new situation that you can apply your knowledge and experience to. If the current place of employment doesn't appreciate you then another one, somewhere will.
Not all of us are independently wealthy and not everyone has the drive to be the "Rich Dad" but all of us do have control over ourselves and what we do. Enjoy what you do - if you don't and no one is listening - move on. Its time to go.
Monday, June 25, 2007
Friday, June 15, 2007
My way or the highway (reprise)
In my original post My way or the high way I pointed out a bunch of reasons that a boss type person @ BigCo might be seen as a pain in most respects. It seems I was remiss and I left out one of the ways that this syndrome can manifest. This new way to manifest this syndrome is something like this:
It wasn't something I sanctioned or choose and as such should be turned off immediately.
Now there are certainly times where in a security conscious world that this particular decision making process might make sense. However, I am of the opinion that this process is more of a pissing match then it is really about solving problems.
My Reasoning: Bosses rarely if ever know what the developers need better then the developers do. So once the boss makes the "my way or the highway decision" to turn off something that the developers use and have made use of - the only thing she is doing is harming the organization that she counts on the most. Once might additionally argue that the farther up the "boss chain" or "chain of command" she sits, the less likely the decision is going to be based on fact or need and the more likely it is to be based on some wild personal feeling or desire to do something different.
In the end - I personally think it should be forbidden in companies for CIOs/CEOs to be making decisions about the individual software that developers 3, 4, 5, levels under them in the BigCo food chain use. They are just not in any position to make that decision wisely from where I sit.
It wasn't something I sanctioned or choose and as such should be turned off immediately.
Now there are certainly times where in a security conscious world that this particular decision making process might make sense. However, I am of the opinion that this process is more of a pissing match then it is really about solving problems.
My Reasoning: Bosses rarely if ever know what the developers need better then the developers do. So once the boss makes the "my way or the highway decision" to turn off something that the developers use and have made use of - the only thing she is doing is harming the organization that she counts on the most. Once might additionally argue that the farther up the "boss chain" or "chain of command" she sits, the less likely the decision is going to be based on fact or need and the more likely it is to be based on some wild personal feeling or desire to do something different.
In the end - I personally think it should be forbidden in companies for CIOs/CEOs to be making decisions about the individual software that developers 3, 4, 5, levels under them in the BigCo food chain use. They are just not in any position to make that decision wisely from where I sit.
Social Software Development
Working for a company, any company is often loosely based on your experience and the things that you as a worker are able to produce - at least this is what the companies would like you to think. Working for a company especially when you are a software developer or a project manager who oversees a software development project is so much more then more then the sum of the capabilities of the people on a given team.
Recently a friend of mine wrote a post on predicting the outcome of a software development project by objectively observing it. He posited that it should be possible to predict the projects outcome and if it is possible to do that, there should be a way of mechanizing the observances being made so that you could always accurately predict the outcome of a given software project. The perceived desire would be to be able to cut off a project that was destined to fail - long before it actually DID fail. What he found is something that I have often felt was at the heart of working for a company in general and more specifically and directly about software development as a whole.
What he found was that it was damn near impossible to mechanize the observations about a software development project and as such to use that information to predict the general health of said project. What he did find was that the social aspects, the interactions that the team was having and how they were having them was actually a far better indicator of the success or failure of a given project. More specifically he stated that the good Project Management of a project was about getting the people on the project who have information that can help you determine the general health of said project to give it up freely.
"Project management is a social problem. It is 99.5% about getting everyone who knows something about the state of the project to share what they know with everyone else. Getting all the relevant information is 99.5% of the problem, analyzing the information is 0.5% of the problem."
For some time now it has been my observation that working for a company and specifically doing software development is a social thing. You spend a great deal of time with the people that you work with, in some instances more time is spent with the people that you work with then you spend with your family at home - it should, due to that fact, stand to reason that what you do at work is going to have a social aspect to it. Beyond that you have to take into account that in order to like where you work you will also have to at least like "SOME" of the people that you work with. Add to the above facts that software development when you are part of a larger team is about information and its exchange you can not help but come to the conclusion that Project Management is about being social.
Think about it this way:
Software you are developing on your own, by yourself only requires that you know whats going on. Software developing in a team requires that the whole team know what is going on and that the information about whats going on is 'well' communicated to the company / project management.
I am sure you have all been on projects where this is not the case. Better yet you may currently work for a company that doesn't foster open and honest communication about project/development status. Did you feel that any of those projects where successes even if they actually did succeed? Or did you feel that the project somehow miraculously succeeded in spite of itself? I personally fall into the later case more often then not.
So whats the take away? Spend time in your company fostering open honest communication, either through tools (wiki, threaded forums, IM) or via personal interactions. Those open lines of communication can only help the situation not hurt it. If you squelch the lines of communication and ignore the social aspects of the working world you will almost certainly be destined for failure.
Recently a friend of mine wrote a post on predicting the outcome of a software development project by objectively observing it. He posited that it should be possible to predict the projects outcome and if it is possible to do that, there should be a way of mechanizing the observances being made so that you could always accurately predict the outcome of a given software project. The perceived desire would be to be able to cut off a project that was destined to fail - long before it actually DID fail. What he found is something that I have often felt was at the heart of working for a company in general and more specifically and directly about software development as a whole.
What he found was that it was damn near impossible to mechanize the observations about a software development project and as such to use that information to predict the general health of said project. What he did find was that the social aspects, the interactions that the team was having and how they were having them was actually a far better indicator of the success or failure of a given project. More specifically he stated that the good Project Management of a project was about getting the people on the project who have information that can help you determine the general health of said project to give it up freely.
"Project management is a social problem. It is 99.5% about getting everyone who knows something about the state of the project to share what they know with everyone else. Getting all the relevant information is 99.5% of the problem, analyzing the information is 0.5% of the problem."
For some time now it has been my observation that working for a company and specifically doing software development is a social thing. You spend a great deal of time with the people that you work with, in some instances more time is spent with the people that you work with then you spend with your family at home - it should, due to that fact, stand to reason that what you do at work is going to have a social aspect to it. Beyond that you have to take into account that in order to like where you work you will also have to at least like "SOME" of the people that you work with. Add to the above facts that software development when you are part of a larger team is about information and its exchange you can not help but come to the conclusion that Project Management is about being social.
Think about it this way:
Software you are developing on your own, by yourself only requires that you know whats going on. Software developing in a team requires that the whole team know what is going on and that the information about whats going on is 'well' communicated to the company / project management.
I am sure you have all been on projects where this is not the case. Better yet you may currently work for a company that doesn't foster open and honest communication about project/development status. Did you feel that any of those projects where successes even if they actually did succeed? Or did you feel that the project somehow miraculously succeeded in spite of itself? I personally fall into the later case more often then not.
So whats the take away? Spend time in your company fostering open honest communication, either through tools (wiki, threaded forums, IM) or via personal interactions. Those open lines of communication can only help the situation not hurt it. If you squelch the lines of communication and ignore the social aspects of the working world you will almost certainly be destined for failure.
Subscribe to:
Posts (Atom)
