Big article this time. Too big to paste in here. Therefore, please click on the following link!
Geeky thinking an "Email Guideline"
It is about:
How do you use email? Email is certainly eating a high percentage of our life. For some it becomes the main way of expressing themselves in relation with others. For some it becomes the activity that they spent most of their active life with.
Then, what do you do to keep it organized and efficient? Do you think you are efficient enough? Think again. It is always about establishing the point of reference: are you more efficient that others? Are they efficient? Can you be more efficient with this activity? What do you do to improve?
I’ve been seeing companies that get drown in email exchange. I’ve been seeing initiatives that get killed due to email inefficiency. I’ve been seeing relationships that got broken due to assumptions both parties made when communicating by emails.
I don’t know how efficient emailing should look like, but hey, who am I after all? Feel free to teach me!
Open the file posted HERE and read the “Email Guideline” I’ve been initiated during a collaboration with some corporation.
You might not find the answers to the questions above but it certainly helped me to get some order in emailing.
Rules might vary a lot from one corporation to another and it is only about corporate culture. If for some, the rules here might be rubbish, for others might be enlightening. They worked for me and for the contractor using them.
If they are useless to you, keep just one general idea: make no assumptions, email communication can be efficient or can lead to massive and costly waste. Not everyone acknowledge that, but without a clearly enforced email guideline, a company might loose up to 30 minutes per person per day. Think about a 300 persons company, loosing 30 minutes / day per person. That means 150 man-hours per day lost, that means 3000 man-hours per month lost. At a rate of 30 EUR / hour company costs per employee, that leads to 90,000 EUR per month lost, therefore a million a year. Wooohaaa!
Ok, so you don’t actually lose 30 minutes a day, maybe an email guideline will only bring you an average of 5 minutes a day per resource. That represents a virtual increase of efficiency or a saving of about 180,000 EUR. Still motivating for me to get this thing going. Think about the minutes cumulated as work, you turn wasted time in productive time. If email usage efficiency will get you 30 minutes more during a day you can certainly address a 30 minutes task that can make more than a 15 EUR cost saving for corporation, but can even have a serious impact.
Feel free to comment or add to my email guideline. Here’s my knowledge sharing with you!
http://www.scribd.com/full/20560526?access_key=key-1298h567pl366d220u8u
Give something back.
Showing posts with label lessons learned. Show all posts
Showing posts with label lessons learned. Show all posts
Thursday, September 24, 2009
Tuesday, May 26, 2009
Motivating software developers
Here are a few general known statements: success is about passion and motivation. You need to put your heart and efforts into it in order o fully succeed. You cannot take something to the limits if you don’t believe in it and if you are not ready to make some compromises on the way.
Compromise is when you decide for example, for one of the following:
> Career. When you see that investing in one technology / company / team / location / brand / trend… might mean something to you for the future. Might lead you to where you actually want to be, no matter what that is. What mattes is that the compromise you make, the crap you accept for the moment will take you one step closer to your career path. Of course if you have one.
> Money. Usually money does not come on the first place if you are truly honest with yourself. If money comes on the first place when you make a compromise, then yes, you have an income issue that has to be fixed or a planned investment. Otherwise money is a general motivation for a career path. They come either with your skill growth or evolution on the hierarchical scale.
> Environment. Especially in software area environment is key critical to assure an innovative state of mind. Creation and invention is about being open minded, having a friendly environment that welcomes any crazy idea, eventually inspiring crazy new ideas.
> Team. Even if team is part of the environment, I especially named it separately since it has a special influence. Of course you can be a lonely freelancer, but show me a freelancer that is not part of some community. Team, communication, bounding… are all very important even if this is sometime virtual.
> Technology. Again something surprising, something that you might as well consider it as part of the “career” section, but it is not. Don’t full yourself, as much as a guy grows as a manager / career path, he will still stick to one or more technologies and he will still get back to code something. Maybe less, maybe more, but once a developer, always a developer. It is not about what you do, but it is about that satisfaction that you create, that you figure it out by yourself, that you find a fast solution, a better solution.
> Ego. Hmm… what is that? Well it is something that does not eventually translate into 0 or 1, not even in OOP, not a web-service or anything in this area. It is about us humans, being sometimes so proud or so foolishly honest, or anything that has to do only with us. Sometimes ego drives developers (known as having a huge ego) towards decisions and compromises.
> Amount of work, time, exhaustion. This is, of course, part of any job. Within software development, same as other brain efforts, this is important and, depending on the level of it, certain compromises are made. It is very often combined with one of the above. So it usually has a hidden reason. For example you might love a job that allows you to have spare time within working schedule so you can actually focus on studying a technology or on a product or on… making money for other clients, etc.
> Coolness. Yes, this can probable be included in one of the categories above or defined as a certain percent of each of the above combined. Developers have their own world. If you, the one reading my blog, are not part of software world, you would be surprised that we have here our own fashion shows, our trends, our online meetings, our chat, our social networking, our brands, our certifications, etc…
Of course there are other reasons and compromises but I will not get into personal issues such as location or region or economical trends, etc. for the goal of this article we basically stick to the ones above.
So what we learned so far is that a software developer will basically make some compromises and chose his work, keep his work based on the above statements. Sometimes his work and decision is defined by a combination of them, sometimes only by only one direction.
If you as a manager really care about your team and need to keep them motivated, not just working, not just showing up at work, but really impassionate and long term committed (whatever long-term might mean these days for software industry), then you need to know your people. You need to know what drives them. What is the element (for example from the ones above) that really drives the individual?
From my experience a software – related person will be motivated if:
> You, as a manager, make sure you identify and assure a combination of the above
> You, as a manager, make sure you intensify the most important element for each resource.
So far it is all logic and somehow applicable to a range of industries not only software.
If we relate only to software, then I would insist on the ones I mentioned above as special for the industry. You will not find an accountant choosing to work on a specific part of the accounting because of coolness or because of the trend. They will work on it because of the income, because of the market demand for such jobs, because of the general opportunity, because of the corporation brand, etc. They will put passion into it, but they will not chose it because of technology. They will not chose it because of the ego or because it allows them to innovate more.
More than this, software developers tend to become introverts, tend to give up or never grow communication skills, tend to make software their world. Impassionate software developers become their work and behave their work and vice versa: their work will reflect their character and behavior. Sounds freaky or scary? It is so real.
I had friends (yes more than one) that made a mistake when they were tying their shoes and their immediate thought was to do a “Ctrl + Z”. Not laughing? You’re not a developer, then. Oh yeah, there are so many jokes about it, but so many are real. You behave as you think and if you think in algorithms you will behave as such. You will end up planning your life by bubble sort so you organize things fast... Etc..
One of my favorite examples when presenting Software Project Management Tips and Tricks is the one related to shopping list. You may choose a specific methodology (agile, extreme, waterfall, scrum, RUP, etc…) when you do shopping and approach the “cash and carry” shop by using that specific methodology: faster, better, by shelf, by brand, cheaper… depending what you aim.
I can continue but I won’t. I made my case in giving you a glimpse on software developer’s state of mind.
How do you motivate them? Go by their passion.
> By technology – round robin them on technologies (move them from one to another), give them the opportunity to know best one but also constantly get the new ones evaluated.
> By growing their EGO in allowing them to invent and take the credit. Make them special. Make sure the product become their child. Make compromises on decisions when it is THEIR decision.
> By the coolness – stay up with trends and what is cool to learn and put them on that technology / methodology / state of mind /environment. Even if you don’t have the opportunity: invent one. Make all possible compromises that all new requests are going to be built with the “cool” stuff. The results will really make a difference.
> Create the craziest environment. I learned by myself so many times that environment with basically no restriction and actually invitation to wild will not cause you productivity decrease, but even more, will build a team that is productive in spikes but with the average of success and quality clearly above any corporate restrictive environment.
> Select very careful your team. Involve anyone in your choices and never make compromises. Once part of the team and fully accepted, the guy will glow and the team will count on him even if you have some doubts on some of the skills.
> Keep up / high the amount of work. Yes you read it right. A developer with nothing to do will find something to do somewhere else. Keep them very busy and even more, ask extra 3 to 5 cool tasks out of them. Most of us (yeah I am part of it) will go home, do the boring life-related stuff, then switch back to work on the cool tasks.
> Monitor their behavior constantly in order to check all these. Never give up. Not monitoring a resource will lead to loosing it.
> Invent personal projects; encourage them to work on personal ideas for a certain amount of time. Most of them will be useful later. Plan time right and allow them to grow freely their ideas.
> As much as possible make sure money do not become an issue. If handled well all above, money will not become a burning issue. This is of course subject of discussion and economical constraints but I’ve learned that when a developer is reaching to constantly think about money even if YOU DO all that I mentioned above you either are paying him crap or he has issues and you don’t need him.
Is this all? No, there it is so much more in motivating people. This is no general solution, no magic methodology. Really knowing each of your team members and really communicating with them will lead you to so much more thing you can do just to motivate them and keep them focused.
Each one of the above criteria and suggestions can be detailed within a long chapter: environment, ego, money, technology, etc… Maybe I will.
.
Compromise is when you decide for example, for one of the following:
> Career. When you see that investing in one technology / company / team / location / brand / trend… might mean something to you for the future. Might lead you to where you actually want to be, no matter what that is. What mattes is that the compromise you make, the crap you accept for the moment will take you one step closer to your career path. Of course if you have one.
> Money. Usually money does not come on the first place if you are truly honest with yourself. If money comes on the first place when you make a compromise, then yes, you have an income issue that has to be fixed or a planned investment. Otherwise money is a general motivation for a career path. They come either with your skill growth or evolution on the hierarchical scale.
> Environment. Especially in software area environment is key critical to assure an innovative state of mind. Creation and invention is about being open minded, having a friendly environment that welcomes any crazy idea, eventually inspiring crazy new ideas.
> Team. Even if team is part of the environment, I especially named it separately since it has a special influence. Of course you can be a lonely freelancer, but show me a freelancer that is not part of some community. Team, communication, bounding… are all very important even if this is sometime virtual.
> Technology. Again something surprising, something that you might as well consider it as part of the “career” section, but it is not. Don’t full yourself, as much as a guy grows as a manager / career path, he will still stick to one or more technologies and he will still get back to code something. Maybe less, maybe more, but once a developer, always a developer. It is not about what you do, but it is about that satisfaction that you create, that you figure it out by yourself, that you find a fast solution, a better solution.
> Ego. Hmm… what is that? Well it is something that does not eventually translate into 0 or 1, not even in OOP, not a web-service or anything in this area. It is about us humans, being sometimes so proud or so foolishly honest, or anything that has to do only with us. Sometimes ego drives developers (known as having a huge ego) towards decisions and compromises.
> Amount of work, time, exhaustion. This is, of course, part of any job. Within software development, same as other brain efforts, this is important and, depending on the level of it, certain compromises are made. It is very often combined with one of the above. So it usually has a hidden reason. For example you might love a job that allows you to have spare time within working schedule so you can actually focus on studying a technology or on a product or on… making money for other clients, etc.
> Coolness. Yes, this can probable be included in one of the categories above or defined as a certain percent of each of the above combined. Developers have their own world. If you, the one reading my blog, are not part of software world, you would be surprised that we have here our own fashion shows, our trends, our online meetings, our chat, our social networking, our brands, our certifications, etc…
Of course there are other reasons and compromises but I will not get into personal issues such as location or region or economical trends, etc. for the goal of this article we basically stick to the ones above.
So what we learned so far is that a software developer will basically make some compromises and chose his work, keep his work based on the above statements. Sometimes his work and decision is defined by a combination of them, sometimes only by only one direction.
If you as a manager really care about your team and need to keep them motivated, not just working, not just showing up at work, but really impassionate and long term committed (whatever long-term might mean these days for software industry), then you need to know your people. You need to know what drives them. What is the element (for example from the ones above) that really drives the individual?
From my experience a software – related person will be motivated if:
> You, as a manager, make sure you identify and assure a combination of the above
> You, as a manager, make sure you intensify the most important element for each resource.
So far it is all logic and somehow applicable to a range of industries not only software.
If we relate only to software, then I would insist on the ones I mentioned above as special for the industry. You will not find an accountant choosing to work on a specific part of the accounting because of coolness or because of the trend. They will work on it because of the income, because of the market demand for such jobs, because of the general opportunity, because of the corporation brand, etc. They will put passion into it, but they will not chose it because of technology. They will not chose it because of the ego or because it allows them to innovate more.
More than this, software developers tend to become introverts, tend to give up or never grow communication skills, tend to make software their world. Impassionate software developers become their work and behave their work and vice versa: their work will reflect their character and behavior. Sounds freaky or scary? It is so real.
I had friends (yes more than one) that made a mistake when they were tying their shoes and their immediate thought was to do a “Ctrl + Z”. Not laughing? You’re not a developer, then. Oh yeah, there are so many jokes about it, but so many are real. You behave as you think and if you think in algorithms you will behave as such. You will end up planning your life by bubble sort so you organize things fast... Etc..
One of my favorite examples when presenting Software Project Management Tips and Tricks is the one related to shopping list. You may choose a specific methodology (agile, extreme, waterfall, scrum, RUP, etc…) when you do shopping and approach the “cash and carry” shop by using that specific methodology: faster, better, by shelf, by brand, cheaper… depending what you aim.
I can continue but I won’t. I made my case in giving you a glimpse on software developer’s state of mind.
How do you motivate them? Go by their passion.
> By technology – round robin them on technologies (move them from one to another), give them the opportunity to know best one but also constantly get the new ones evaluated.
> By growing their EGO in allowing them to invent and take the credit. Make them special. Make sure the product become their child. Make compromises on decisions when it is THEIR decision.
> By the coolness – stay up with trends and what is cool to learn and put them on that technology / methodology / state of mind /environment. Even if you don’t have the opportunity: invent one. Make all possible compromises that all new requests are going to be built with the “cool” stuff. The results will really make a difference.
> Create the craziest environment. I learned by myself so many times that environment with basically no restriction and actually invitation to wild will not cause you productivity decrease, but even more, will build a team that is productive in spikes but with the average of success and quality clearly above any corporate restrictive environment.
> Select very careful your team. Involve anyone in your choices and never make compromises. Once part of the team and fully accepted, the guy will glow and the team will count on him even if you have some doubts on some of the skills.
> Keep up / high the amount of work. Yes you read it right. A developer with nothing to do will find something to do somewhere else. Keep them very busy and even more, ask extra 3 to 5 cool tasks out of them. Most of us (yeah I am part of it) will go home, do the boring life-related stuff, then switch back to work on the cool tasks.
> Monitor their behavior constantly in order to check all these. Never give up. Not monitoring a resource will lead to loosing it.
> Invent personal projects; encourage them to work on personal ideas for a certain amount of time. Most of them will be useful later. Plan time right and allow them to grow freely their ideas.
> As much as possible make sure money do not become an issue. If handled well all above, money will not become a burning issue. This is of course subject of discussion and economical constraints but I’ve learned that when a developer is reaching to constantly think about money even if YOU DO all that I mentioned above you either are paying him crap or he has issues and you don’t need him.
Is this all? No, there it is so much more in motivating people. This is no general solution, no magic methodology. Really knowing each of your team members and really communicating with them will lead you to so much more thing you can do just to motivate them and keep them focused.
Each one of the above criteria and suggestions can be detailed within a long chapter: environment, ego, money, technology, etc… Maybe I will.
.
Saturday, May 2, 2009
What does come first, the Client or the Project?
"A camel is a horse designed by committee."
Well, this is a version of the same old problem: what does come first? The Client or The Project?
When you work in a Client-oriented scenario you basically cannot say "No" to your client. You may suggest things, you may guide him towards your ideas (if you are good enough in doing that) but if he is stubborn enough, you just can't say "No". In fact... he will pay at the end of it, so it is his decision, as long as he pays your efforts, no matter the service you provide.
But is this really healthy as mentality? What does the Client really want as end result? He wants to solve his problems. He wants a product (or a solution or any service you provide...) that will solve his problem, that will make him happier, that will lead to his growth.
Does he know better than you what is best for him? Maybe not, since he already has the problem he cannot solve. Maybe yes, because he knows better his business, he was already struggling with various solutions and... why not... maybe you are just not the best provider.
My believe is that project comes first, but I tent to believe also that this will happen only in the ideal situation when all parties are looking to understand, are listening and all are looking towards same goal: to find the best solution for the problem, the best idea to fulfill the needs, etc.. not focusing on personal or private, isolated needs.
Usually the Client is focused on suggesting and enforcing solutions that are not always the right ones. Usually the provider is focused on getting the highest profit. Both of the parties meet somewhere in the middle after climbing a mountain of compromises. Then they call this "the project" and start to execute.
There's also the ego. Personal issues since we are all human.
Sometimes the good thing happens. Sometimes you are the right Provider and at the sam time the Client hires you and looks at you as at a specialist, allowing you the freedom you need. Sometimes both of the parties are willing to make all efforts so the project, their "baby" will succeed.
In software development, this (Client enforced solutions vs. proper system design) is a common problem that usually gets self-defined in the beginning of the project. You will see how the project becomes strictly a contractual agreement or becomes something alive, something with a life of it's own, growing...
Is it the same with User-driven development? With online communities and platforms? I think so, yes. You HAVE to listen to your Client, you HAVE to rate your features, but do they always know what is better for them? Not always, (in case of custom software development - not even even frequent).
Does the Provider "surrender" to their Client? Does the Client "surrender" to his Provider? None of the above is right. They both have to "surrender" to the Project... well.. it rarely happens.
Do you surrender to your Client?
Here's the inspirational link of the day:
No! Never Surrender To Your Users, Facebook.
http://www.ngkhai.net/bizdrivenlife/writings/2009/04/13/no-never-surrender-to-your-users-facebook/
Since you are here, read other interesting articles...
The Problem with Problems
""Deficit thinking" sees organizations focusing on what's wrong and problems that need to be solved. In doing so, they often overlook real opportunities"
http://www.ngkhai.net/bizdrivenlife/writings/2009/04/13/the-problem-with-problems/
Why A Blog Can Be Good For Your Business
"You can establish yourself as an expert. Blogs give you a way to reach out to clients..."
http://www.pheedcontent.com/click.phdo?i=e0ee3424bade975c2432439d089de68a
Retaining your best people
"In spite of the obviousness of this crucial responsibility, many organizations suffer from the ‘leaking reservoir’ syndrome"
http://www.codeproject.com/KB/work/Retainingyourbestpeople.aspx
.
Well, this is a version of the same old problem: what does come first? The Client or The Project?
When you work in a Client-oriented scenario you basically cannot say "No" to your client. You may suggest things, you may guide him towards your ideas (if you are good enough in doing that) but if he is stubborn enough, you just can't say "No". In fact... he will pay at the end of it, so it is his decision, as long as he pays your efforts, no matter the service you provide.
But is this really healthy as mentality? What does the Client really want as end result? He wants to solve his problems. He wants a product (or a solution or any service you provide...) that will solve his problem, that will make him happier, that will lead to his growth.
Does he know better than you what is best for him? Maybe not, since he already has the problem he cannot solve. Maybe yes, because he knows better his business, he was already struggling with various solutions and... why not... maybe you are just not the best provider.
My believe is that project comes first, but I tent to believe also that this will happen only in the ideal situation when all parties are looking to understand, are listening and all are looking towards same goal: to find the best solution for the problem, the best idea to fulfill the needs, etc.. not focusing on personal or private, isolated needs.
Usually the Client is focused on suggesting and enforcing solutions that are not always the right ones. Usually the provider is focused on getting the highest profit. Both of the parties meet somewhere in the middle after climbing a mountain of compromises. Then they call this "the project" and start to execute.
There's also the ego. Personal issues since we are all human.
Sometimes the good thing happens. Sometimes you are the right Provider and at the sam time the Client hires you and looks at you as at a specialist, allowing you the freedom you need. Sometimes both of the parties are willing to make all efforts so the project, their "baby" will succeed.
In software development, this (Client enforced solutions vs. proper system design) is a common problem that usually gets self-defined in the beginning of the project. You will see how the project becomes strictly a contractual agreement or becomes something alive, something with a life of it's own, growing...
Is it the same with User-driven development? With online communities and platforms? I think so, yes. You HAVE to listen to your Client, you HAVE to rate your features, but do they always know what is better for them? Not always, (in case of custom software development - not even even frequent).
Does the Provider "surrender" to their Client? Does the Client "surrender" to his Provider? None of the above is right. They both have to "surrender" to the Project... well.. it rarely happens.
Do you surrender to your Client?
Here's the inspirational link of the day:
No! Never Surrender To Your Users, Facebook.
http://www.ngkhai.net/bizdrivenlife/writings/2009/04/13/no-never-surrender-to-your-users-facebook/
Since you are here, read other interesting articles...
The Problem with Problems
""Deficit thinking" sees organizations focusing on what's wrong and problems that need to be solved. In doing so, they often overlook real opportunities"
http://www.ngkhai.net/bizdrivenlife/writings/2009/04/13/the-problem-with-problems/
Why A Blog Can Be Good For Your Business
"You can establish yourself as an expert. Blogs give you a way to reach out to clients..."
http://www.pheedcontent.com/click.phdo?i=e0ee3424bade975c2432439d089de68a
Retaining your best people
"In spite of the obviousness of this crucial responsibility, many organizations suffer from the ‘leaking reservoir’ syndrome"
http://www.codeproject.com/KB/work/Retainingyourbestpeople.aspx
.
Subscribe to:
Posts (Atom)
Posts
