"The Power of Nice" by Linda Kaplan Thaler and Robin Koval was the first in my recent spree of business topic books. I originally picked it up because I had been reading some pretty heavy books and I needed a light (quick) book to read - to cleans the pallet - before diving into other heavier books on my "I want to read" list. This book was sitting on my wife's nightstand and the cover alone - a bright yellow cover with a big smile on it resembling a happy face - made me think this would be the the quick, light read I needed.
While reading this book I found it to be in tune with the current culture of business. Coined as a book about "How to Conquer the Business World with Kindness.", it goes against the grain of thinking that business is a heartless cut-throat environment where decisions are based purely on the bottom line. Merit and integrity are now, more than ever, getting their fair shake in the business world. This book outlines the values of kindness and dives into case studies that supported the idea that kindness will get you further in the business world.
That being said, I feel many of the values of kindness shouldn't need to be written in a book. Personally, a book that tells you how to be nice is much like a book that tells you, "The sky is blue" and "fire is hot" it goes without saying. The reason it goes without saying is because it is a fundamental of life (a.k.a common sense).
When I finished reading I told her exactly that, I felt the book was about common sense. She looked at me as if I should know better and sarcastically said, "Yes, but how often do common sense and business work together?" She was being sarcastic, but it is a legitimate argument.
The principles outlined in the "Power of Nice" are not new, nor ground breaking; they are fundamentals. As a child, how often did your parents tell you to be nice, play fair, be gentle with the family pet? I don't know about you, but it was at least a hundred times... per day. Thanks to my parents I've been learning how to be nice since I was learning how to walk. Being nice is a cornerstone of my foundation because my parents realized that it is a fundamental of life.
As an adult how much experience do you have at your career? 5, 10, 20 years? Now, how long have you been being nice to people? I'm guessing at least 18 years longer than your career experience. That is a lot of experience at being nice! Wouldn't that be an incredible skill set to bring into your current job?
For those who are willing to embrace this way of thinking about business it is empowering. Empowering not only in the business world, but in all areas of life because if you practice being nice at work, you are in essence practicing a fundamental of life for at least eight hours a day. This does have it's rewards.
As Randy Pausch wrote in The Last Lecture, "You've got to get the fundamentals down, because otherwise the fancy stuff is not going to work."
In the case of work, the "fancy stuff" could be the innovation, engineering, or promotions waiting to happen. In the case of personal life, the "fancy stuff" could be a thriving relationship, quality time with your kids, or whatever you want to accomplish. In any case, this book helped remind me of my own definitions of the "Power of Nice" and by relying on my fundamental value of kindness, I'm able to succeed at both work and life.
Showing posts with label business. Show all posts
Showing posts with label business. Show all posts
August 2, 2008
January 15, 2008
Scope Creep... It Happens To Us All
What the hell is scope creep, you ask? In the IT world it is used to describe the features and functionality that hangs on the fringe of requirements. It isn't a phrase that is used a lot when the project is on target, but when there is a risk of missing the deadline this phrase is tossed around a lot!
Basic requirements are necessary for any developer/tester to get an idea of the scope. Those requirements are what ground development because there will always be something cool to develop or a new feature that can be added. These requirements, which should be derived by a business need is what allows us to understand the needs of the business and satisfy their request. It also helps when there is a need to estimate the amount of time it will take to finish a project.
It seems simple enough, but when the basic requirements are missing or vague it becomes very easy for the scope of a project to loose focus. Without requirements the developer is free to code whatever they like, the tester doesn't have a clue what they should be testing, and Product keeps asking for more, which inevitably causes the project to loose scope and everyone who is a part of it to loose focus. Suddenly new functionality and enhancements are being added and so starts scope creep.
1) Before you allow anything into test, require requirements!
2) The moment someone asks about adding a requirement ask yourself "Does this fit in the scope of the originally outlined project?"
Product:
1) The moment you think to yourself, "It would be nice if..." or "Can we also..."; shut up, unless you are willing to risk the project deadline not being met or are willing to trade out previously assigned and estimated functionality.
Back to the reason I originally started writing this:
Scope creep happens to all of us. Lemme give you a for instance. I recently sat down on my computer to work on a project on TrailCentral. On TrailCentral I assume the roles of Product, Developer, and Tester so you would think all three degrees of my personality would be on the same page, but you'll see that wasn't the case.
My original requirement was that I wanted to add the ability for people to sort the county trail list by name, city, difficulty, or ranking. Seems simple enough and I started to develop it. Since I recently started to program using AJAX, I decided that I would do this using AJAX. Seemed reasonable and well within the requirement so I kept on programming. Then I got an idea in my head. I thought it would be cool if visitors could use this page to get driving direction to each trail listed. Suddenly, my focus shifted and so started my scope creep.
I'm new to developing with AJAX and Javascript in general so this idea was good on paper, but I wasn't having much luck making it work. So instead of refocusing on the original requirement, I buried myself in trying to figure it out. I read all sorts of Google API documentation and read countless javascript tutorials. Two days later I continued to beat my head against the wall. Finally, the tester in me took over and I asked "Does what I'm trying to do fit the original scope of the project?" The answer was simply, "Hell no!"
So after two extra days of work I pulled all the code I was working on for the driving directions and I started testing the code I had added to allow users to sort the trail list, which was working a couple days ago with only a couple hours of work.
This is just an example of how scope creep happened to me. If it happens to me this easy when I have control of Product, Development, and Test; it is easy to understand how scope creep can work its way into projects that have multiple people working on the project.
Basic requirements are necessary for any developer/tester to get an idea of the scope. Those requirements are what ground development because there will always be something cool to develop or a new feature that can be added. These requirements, which should be derived by a business need is what allows us to understand the needs of the business and satisfy their request. It also helps when there is a need to estimate the amount of time it will take to finish a project.
It seems simple enough, but when the basic requirements are missing or vague it becomes very easy for the scope of a project to loose focus. Without requirements the developer is free to code whatever they like, the tester doesn't have a clue what they should be testing, and Product keeps asking for more, which inevitably causes the project to loose scope and everyone who is a part of it to loose focus. Suddenly new functionality and enhancements are being added and so starts scope creep.
Here is a super simple look at how scope creep can be avoided from each perspective
Developers:
1) Before you code it, ask yourself, "Is this necessary to meet the requirement?"
2) Ignore the Product people buzzing in your ear about additional functionality. OK, maybe ignore is a little harsh. Entertain the idea and if it has merit, include the appropriate people to discuss it.
1) Before you allow anything into test, require requirements!
2) The moment someone asks about adding a requirement ask yourself "Does this fit in the scope of the originally outlined project?"
Product:
1) The moment you think to yourself, "It would be nice if..." or "Can we also..."; shut up, unless you are willing to risk the project deadline not being met or are willing to trade out previously assigned and estimated functionality.
Back to the reason I originally started writing this:
Scope creep happens to all of us. Lemme give you a for instance. I recently sat down on my computer to work on a project on TrailCentral. On TrailCentral I assume the roles of Product, Developer, and Tester so you would think all three degrees of my personality would be on the same page, but you'll see that wasn't the case.
My original requirement was that I wanted to add the ability for people to sort the county trail list by name, city, difficulty, or ranking. Seems simple enough and I started to develop it. Since I recently started to program using AJAX, I decided that I would do this using AJAX. Seemed reasonable and well within the requirement so I kept on programming. Then I got an idea in my head. I thought it would be cool if visitors could use this page to get driving direction to each trail listed. Suddenly, my focus shifted and so started my scope creep.
I'm new to developing with AJAX and Javascript in general so this idea was good on paper, but I wasn't having much luck making it work. So instead of refocusing on the original requirement, I buried myself in trying to figure it out. I read all sorts of Google API documentation and read countless javascript tutorials. Two days later I continued to beat my head against the wall. Finally, the tester in me took over and I asked "Does what I'm trying to do fit the original scope of the project?" The answer was simply, "Hell no!"
So after two extra days of work I pulled all the code I was working on for the driving directions and I started testing the code I had added to allow users to sort the trail list, which was working a couple days ago with only a couple hours of work.
This is just an example of how scope creep happened to me. If it happens to me this easy when I have control of Product, Development, and Test; it is easy to understand how scope creep can work its way into projects that have multiple people working on the project.
September 5, 2007
Bathroom Business
A lot of business takes place in a mens bathroom. I mean to say that more than just your typical "bathroom" business happens there. I'm talking about real honest work.
I'm guessing that the mens restroom takes second place only to the water cooler in terms of spontaneous meetings with co-workers. The only difference that I see between the two is that when you are around the water cooler, the topics tend to stray from business and it becomes a break. Whereas, in a restroom, you stick to the topic. The only reason a man is going to be caught talking to another man while in the restroom is because of business. For this very reason topics in the restroom are very business focused.
I'm not sure if the womens restroom is equally as productive, but I assure you that when men appear to be taking a long time in the bathroom it may not be because they had Mexican food and a lot of beer the previous night and their stomach is upset. They may be hashing a business plan with their co-worker or boss.
The reason I bring this topic up is because I was part of an impromptu business meeting in the mens restroom today.
In restroom meeting etiquette it is OK to begin a conversation after the facilities have been used and you are washing your hands. At that point, if you feel it necessary to continue talking; only a few small steps backwards are needed to allow room for other restroom patrons to wash their hands after their "load balancing" has been completed, so to speak.
Our meeting ran longer than the typical hand wash so it was imperative that my co-worker, boss, and I take a few steps back from the sink.
I'm a bit of a germ-a-phobe and I believe a person should wash their hands no matter what kind of business they have done in the restroom. I typically - when not in a meeting - will wash my hands, dry my hands with a paper towel, grab a fresh paper towel and wrap it around the handle to avoid contact with any germs that may have collected on the door handle. Some may call me paranoid, but I have just cause for doing this.
During my meeting I had a clear view of the restroom sinks. As I participated in the discussion I couldn't help but notice the hand washing practices of others that use the restroom.
Let me give you a few examples of the types of people I saw:
Guy #1 - I don't wash my hands guy." This is the kind of guy that will zip up and head straight to the door. Leaving his germs on the handle. I cringe whenever I witness it. I want to remind these people to wash their hands, as if they have forgotten, but I'm not that bold.
Guy #2 - "My body is a temple guy." This guy washed his hands before he used the restroom; as if his hands were too dirty to do his business. After he used the facilities I noticed this guy looking at himself in the mirror, never washing his hands before leaving. Again, leaving his germs on the handle and most likely picking up a few germs from Guy #1.
Guy #3 - "Extreme germ-a-phobe guy." This guy came into the restroom with the sole purpose of cleaning his hands. He scrubbed his hands, dried them, and then bare handed reached for the same handle that guy #1 and #2 had touched. This made my stomach sink. If he only knew...
In total, the restroom meeting lasted less than 5 minutes.
Being the closest one to the door I felt it necessary to hold the door open as the three of us exited the restroom. With dry hands I reached for a paper towel, wrapped it around the handle, and opened the door.
My boss looked at me a bit oddly; as if I was a bit paranoid. However, I'm sure if he had seen what I saw in the last five minutes; he would start carrying a bottle of Lysol and a roll of paper towels everywhere he went.
I didn't bother mentioning what I witnessed. As some people say, "Ignorance is bliss."
I'm guessing that the mens restroom takes second place only to the water cooler in terms of spontaneous meetings with co-workers. The only difference that I see between the two is that when you are around the water cooler, the topics tend to stray from business and it becomes a break. Whereas, in a restroom, you stick to the topic. The only reason a man is going to be caught talking to another man while in the restroom is because of business. For this very reason topics in the restroom are very business focused.
I'm not sure if the womens restroom is equally as productive, but I assure you that when men appear to be taking a long time in the bathroom it may not be because they had Mexican food and a lot of beer the previous night and their stomach is upset. They may be hashing a business plan with their co-worker or boss.
The reason I bring this topic up is because I was part of an impromptu business meeting in the mens restroom today.
In restroom meeting etiquette it is OK to begin a conversation after the facilities have been used and you are washing your hands. At that point, if you feel it necessary to continue talking; only a few small steps backwards are needed to allow room for other restroom patrons to wash their hands after their "load balancing" has been completed, so to speak.
Our meeting ran longer than the typical hand wash so it was imperative that my co-worker, boss, and I take a few steps back from the sink.
I'm a bit of a germ-a-phobe and I believe a person should wash their hands no matter what kind of business they have done in the restroom. I typically - when not in a meeting - will wash my hands, dry my hands with a paper towel, grab a fresh paper towel and wrap it around the handle to avoid contact with any germs that may have collected on the door handle. Some may call me paranoid, but I have just cause for doing this.
During my meeting I had a clear view of the restroom sinks. As I participated in the discussion I couldn't help but notice the hand washing practices of others that use the restroom.
Let me give you a few examples of the types of people I saw:
Guy #1 - I don't wash my hands guy." This is the kind of guy that will zip up and head straight to the door. Leaving his germs on the handle. I cringe whenever I witness it. I want to remind these people to wash their hands, as if they have forgotten, but I'm not that bold.
Guy #2 - "My body is a temple guy." This guy washed his hands before he used the restroom; as if his hands were too dirty to do his business. After he used the facilities I noticed this guy looking at himself in the mirror, never washing his hands before leaving. Again, leaving his germs on the handle and most likely picking up a few germs from Guy #1.
Guy #3 - "Extreme germ-a-phobe guy." This guy came into the restroom with the sole purpose of cleaning his hands. He scrubbed his hands, dried them, and then bare handed reached for the same handle that guy #1 and #2 had touched. This made my stomach sink. If he only knew...
In total, the restroom meeting lasted less than 5 minutes.
Being the closest one to the door I felt it necessary to hold the door open as the three of us exited the restroom. With dry hands I reached for a paper towel, wrapped it around the handle, and opened the door.
My boss looked at me a bit oddly; as if I was a bit paranoid. However, I'm sure if he had seen what I saw in the last five minutes; he would start carrying a bottle of Lysol and a roll of paper towels everywhere he went.
I didn't bother mentioning what I witnessed. As some people say, "Ignorance is bliss."
August 17, 2007
Widgets (Part II)
A couple days ago I posted about the business model of a widget. I was confused by the business surrounding the bits of functionality and I asked for help with understanding it.
Brad Feld left a comment to my query and directed me to a couple of his earlier posts on the subject.
Another View on Widgets - March 4, 2007
YAWP - Yet Another Widget Post - March 15, 2007
The cool part is that Brad has since posted a couple newer posts on the subject of widgets and those posts have lead to even more posts archived in the blogsphere.
The Unbearable Slowness of Javascript Widgets - August 15th, 2007
Resources for Widget Performance - August 17, 2007
Thanks, Brad, for leaving a comment and starting me down a path of better understanding.
Side note: I'm still pretty new to the blogsphere, but when you can learn, teach, and communicate ideas and information so easily, I can't help but be happy to be part of it.
Brad Feld left a comment to my query and directed me to a couple of his earlier posts on the subject.
Another View on Widgets - March 4, 2007
YAWP - Yet Another Widget Post - March 15, 2007
The cool part is that Brad has since posted a couple newer posts on the subject of widgets and those posts have lead to even more posts archived in the blogsphere.
The Unbearable Slowness of Javascript Widgets - August 15th, 2007
Resources for Widget Performance - August 17, 2007
Thanks, Brad, for leaving a comment and starting me down a path of better understanding.
Side note: I'm still pretty new to the blogsphere, but when you can learn, teach, and communicate ideas and information so easily, I can't help but be happy to be part of it.
August 13, 2007
Would somebody please explain the business model behind widgets?
Would somebody please explain the business model behind widgets?
We appear to be entering a phase of the Internet where the major players have surfaced. Don't get me wrong, I believe others will emerge, but I think the days of needing to create a website to have a presence on the web are gone.
Players such as YouTube, MySpace, FaceBook, and many other mega-sites have millions of users. These same sites are starting to attract developers by offering APIs. These APIs allow developers to create small pieces of functionality (a.k.a widgets) which users of mega-sites can download and plugin with only a few click, thus enhancing their online experience.
The appeal for a developer to create a widget is great. In a matter of weeks you can take a general idea, develop a small piece of functionality, and put it to market where it can be exposed to millions of potential users. Beats the hell out of the old web model of building a website, crossing your fingers, and hoping the search engines brings you some traffic. Plus, it keeps developers from reinventing the wheel. Instead, they are finding ways to make the wheel roll smoother, look better, turn faster, etc.
We appear to be entering a phase of the Internet where the major players have surfaced. Don't get me wrong, I believe others will emerge, but I think the days of needing to create a website to have a presence on the web are gone.
Players such as YouTube, MySpace, FaceBook, and many other mega-sites have millions of users. These same sites are starting to attract developers by offering APIs. These APIs allow developers to create small pieces of functionality (a.k.a widgets) which users of mega-sites can download and plugin with only a few click, thus enhancing their online experience.
The appeal for a developer to create a widget is great. In a matter of weeks you can take a general idea, develop a small piece of functionality, and put it to market where it can be exposed to millions of potential users. Beats the hell out of the old web model of building a website, crossing your fingers, and hoping the search engines brings you some traffic. Plus, it keeps developers from reinventing the wheel. Instead, they are finding ways to make the wheel roll smoother, look better, turn faster, etc.
I'm a fan of widgets. I think they are fun and I've actually plugged several of them into my blog. However, I didn't pay for any of them, and I don't see any blantant advertising being done by them.
So it leaves me a bit confused on how they make money???
Recently I was reading Brad Feld's blog where he was pimping developer job openings for one of his portfolio companies call J-Squared. I'm not a devote follower of the company, but the claim to fame for the young company is that they have created a very popular widget for Facebook.
Apparently these widgets are able to make money. I'm still confused as to how???
Do people have to pay for these widgets (ie. $0.10/download)? A dime a download is nothing for a single person to spend, but multiply that times a million downloads and things get a bit more interesting.
Is it advertising? I see that as a viable means, but the more ads that start popping up on a users browser when they install widgets could be a downfall (ie. I install 5 widgets on my blog and each of them have their own advertisements. That is a quick way for me click the delete button associated to that bit of functionality.)
Is it created to be sold? Maybe the idea isn't to make money from advertising or downloads, but to be sold to a mega-site. (ie. Yahoo thinks your widget is the bomb. They are willing to part with an insignificant amount of money (to them) and in return you get a healthy purchase price for a rapid to release product.)
I'm not trying to judge. In fact, I'm trying to learn. I'm hoping someone will enlighten me on how "stable" companies can be formed and make ends meet when their product is a widget?
Subscribe to:
Posts (Atom)
