I acquired a Kindle 2 a few months ago, and had been using it on my daily train commute. I spend 1st hour reading NY Times, and 2nd hour reading blogs and book samples. Having fun with it, and I am almost ready to cancel my NY times print subscription.
What I like:-
- It’s .3 inches thin, and very style-ly. Has that iPod/iPhone/Palm coolness feel to hold and touch
- Screen is easy to read in all but low light, no eye strain
- All buttons and controls are excellent from physical/mechanical perspective (see "don’t like" below on navigation)
- Power lasts a week, whereas iPod doesn't, although I find myself turning off wireless after daily NY times download, which triples battery time
- Wireless connectivity always works. Full books download in 60 seconds after purchase
- Daily subscription downloads (NY Times, Newsweek, Blogs) happens automatically
- Pictures in articles make NY Times feel like the NY Times. Has a Table of Contents (TOC) for NY Times, easy to browse around
- 14 day free trials of periodicals and first chapter free samples of books. Love this!
- Saving my place in what I read
- Looking up words in dictionary automatically (using this when reading bed-time stories to my son)
- Shopping for books on Amazon store works very well. Auto connected to my Amazon account
- Emailing documents to myself my 10 cents is good (they will be very long documents), although this can be done for free using USB cable to PC
- Seems to bounce well when dropped occasionally
What I don’t like
- Navigation is ok, but not intuitive like the iPod. Needs learning (i.e. difference between back and previous buttons)
- Almost every person in the office whom I demoed to thought it was touch screen for navigation
- Comes with no physical cover, what about just a cheap one?
- $15 for NY times monthly subscription? What about ½ price for existing print subscribers
- Paying monthly fee for blog subscriptions (basically subsidizing free wireless, which Amazon pays)
- Can't have automatic search against NY times (i.e. basketball, Australia, Drupal), has to be manual
- Can't tell which sections of NY times I’ve read, and which I haven’t
- No NY times crossword or KenKen (plus side is I spend more time reading)
- Article clippings lose all formatting, its like Unix (i.e. it just copied text appended to one long file of clippings)
- I don’t like the text-to-speech in general, but that’s just me.
- Cant read reviews of books in store, only overall rating
- I have been unsure about using it on subway.
UPDATE: Went to buy Harry Potter, Book 7 for recent overseas trip and was not available. And I thought initially that search was broken. Same experience as searching for Beatles in iTunes store. Had to carry heavy Harry Potter book 7 on plane, so that soured me a bit on Kindle, but guessing I will get over it.
Monday, June 1, 2009
Wednesday, December 17, 2008
Voodoo meetings
Technologists are typically far from superstitious, I am near the top of that list. But there is one thing I am superstitious about... systems failing over holidays or long weekend. Nothing like blissfully leaving the office for more than 2 days off and having it interrupted by an outage call.
One technique I use to ward off these holiday/long weekend outages is to hold a "readiness" meet just before the time off. My experience is that doing such a meeting usually meant nothing bad would happen, or at least if it did the team would be prepared for it.
My team recently did a readiness meeting before the US Thanksgiving holidays, and one of my team came to me early the Monday after and exclaimed "that Voodoo meeting worked, no issues/outages". Hence, the name, which has since stuck and people know what it means if they are invited to a Voodoo meeting. .
Seriously, there is nothing better to get ready than assembling your team together and asking them if the are ready. Are we doing any changes that we should review? Are there any projects launching? Who's going to where should something happen? You may find they go to the desks and double-check systems and changes.
And just as important as a readiness meeting is reaching out to the business to tell them you are "ready", and reiterating incident escalation process. Once we discovered a major issue on a Tuesday after a long weekend, and later determined some end-users had suspected something, but didn't want to bother the IT team on the long weekend.
My message back them:- "Please bother us", its our job.
One technique I use to ward off these holiday/long weekend outages is to hold a "readiness" meet just before the time off. My experience is that doing such a meeting usually meant nothing bad would happen, or at least if it did the team would be prepared for it.
My team recently did a readiness meeting before the US Thanksgiving holidays, and one of my team came to me early the Monday after and exclaimed "that Voodoo meeting worked, no issues/outages". Hence, the name, which has since stuck and people know what it means if they are invited to a Voodoo meeting. .
Seriously, there is nothing better to get ready than assembling your team together and asking them if the are ready. Are we doing any changes that we should review? Are there any projects launching? Who's going to where should something happen? You may find they go to the desks and double-check systems and changes.
And just as important as a readiness meeting is reaching out to the business to tell them you are "ready", and reiterating incident escalation process. Once we discovered a major issue on a Tuesday after a long weekend, and later determined some end-users had suspected something, but didn't want to bother the IT team on the long weekend.
My message back them:- "Please bother us", its our job.
Wednesday, August 20, 2008
Grad school for future CTOs
I have the distinct pleasure of being a mentor in Columbia University's Masters of IT program in continuing education (other posts mentioning Columbia program - http://newyorkcto.blogspot.com/search?q=columbia). My second student just graduated, and I am about to receive my third student in the coming school year. I find it be extremely satisfying to teach a student how to prepare a technology business case, and at the same time find myself reflecting on my own management style, something I am constantly learning and tweaking.
I can't think of a better way for a future CTO or CIO to prepare for the job, and I've given this advice to aspiring CTOs. Check out this recent article on the program: -http://www.informationweek.com/news/management/interviews/showArticle.jh
tml?articleID=210004259
Monday, June 16, 2008
East coast vs. West Coast
There is no getting away from it in the US, there is the East coast and the West coast, and they are quite different when it comes to CTOs (in my opinion). This gross generalization can be easily shot down, but let me move ahead anyway. West coast CTO = super-tech ex-developer. East coast CTO = less tech but very business focused.
Have I offended anyone yet? Not my intention. My point is that we don't see a lot of transporting of CTOs between the coasts. But I love it every time I get to visit and do business in San Francisco/Silicon Valley. I have the same experience each time, technology rocks there. What I find myself doing is figuring out how to take West coast learnings back to the East coast. There's an easiness/flow to technology development on the West coast which is hard to find back east (along with a little more risk-taking).
As an East coast CTO, you should take every chance you can get to visit the West coast. My first-ever US trip (in the 80s) was to Silicon Valley, and that was my main reason for deciding to move to the US. I "missed" my mark and landed in NYC, but no regrets.
And talking about moving coasts, I am extremely happy to announce that New York got one of its finest back recently, Curtis Brown, the new CTO at Kaplan Test Prep & Admissions (my previous job), formerly CTO at McGraw-Hill/CTB in Monterey. Curtis is the quintessential New York CTO who combines tech know-how with business-savvy. Kaplan will excel under Curtis, and we New York CTOs welcome him back to "our" coast.
Wednesday, June 11, 2008
Agile and the social developer
I was talking the other day to a technologist who had made the switch early in his career from software development to infrastructure. I asked him why, his answer:- "I didn't want to spend days not interacting with people".
When I was a software developer, it was a lonesome affair. There was no open source community, just manuals and API docs. I got the occasional check-in from my boss and questions to a sysadmin, but mainly was left alone (and liked it). My response to passers-by as to my well-being was often a grunt, as I maniacally focused on the code on my (green) screen in front of me. But that was in the days before agile development.
Agile development practices require a developer to be social. There's a daily scrum, pair programming, end-users on team, kaizen meetings and the like, all situations which require high social interaction. Even open source development is by its nature social. There's no room for a loner.
One of the reasons I stopped coding and became a manager is because I enjoy social interaction (I've been accused of being a "social animal" :-). I do get a buzz out of an interactive tech meeting with developers, admins or CTO peers. For me, this begs the a/b question:- (a) Does Agile push developers out of their comfort zone to be more social, OR (b) Did Agile come about because developers want to be more social?
But clearly, an agile developer is a social developer. That's a good thing.
When I was a software developer, it was a lonesome affair. There was no open source community, just manuals and API docs. I got the occasional check-in from my boss and questions to a sysadmin, but mainly was left alone (and liked it). My response to passers-by as to my well-being was often a grunt, as I maniacally focused on the code on my (green) screen in front of me. But that was in the days before agile development.
Agile development practices require a developer to be social. There's a daily scrum, pair programming, end-users on team, kaizen meetings and the like, all situations which require high social interaction. Even open source development is by its nature social. There's no room for a loner.
One of the reasons I stopped coding and became a manager is because I enjoy social interaction (I've been accused of being a "social animal" :-). I do get a buzz out of an interactive tech meeting with developers, admins or CTO peers. For me, this begs the a/b question:- (a) Does Agile push developers out of their comfort zone to be more social, OR (b) Did Agile come about because developers want to be more social?
But clearly, an agile developer is a social developer. That's a good thing.
Friday, June 6, 2008
Interim CTO
When a CEO leaves a company, usually the first thing that happens is that the sitting Chairman is appointed as interim CEO. Their job is to steer the company until a full-time CEO is hired.
What do companies do when their CTO leaves? Usually get by without one while they begin the search for a new one. Something that I've experienced recently at both my old and new companies is an Interim (or Transitional) CTO someone to take care of technology until a full-time CTO is found.
An interim CTO doesn't start coding software nor configuring servers. Their job is to provide technology representation for the existing team. Technology teams need an advocate, and can feel completely unrepresented without one. Interim CTOs don't need to come up with a technology strategy, but they do need to mind the store, including shepherding in-play projects, running the budget, and executive communication.
iVillage had an interim CTO when I arrived, and his help has been invaluable to me as I got my head around the extensive technology footprint here. Its made me more effective. I could choose what to focus on first, fully knowing that anything I wasn't focused on was being taken care of by someone else. I recommend a 3 month overlap as ideal.
So, for any company losing their CTO, get an Interim CTO. There are plenty of talented consultants/ex-CTOs out there to help you, use them.
What do companies do when their CTO leaves? Usually get by without one while they begin the search for a new one. Something that I've experienced recently at both my old and new companies is an Interim (or Transitional) CTO someone to take care of technology until a full-time CTO is found.
An interim CTO doesn't start coding software nor configuring servers. Their job is to provide technology representation for the existing team. Technology teams need an advocate, and can feel completely unrepresented without one. Interim CTOs don't need to come up with a technology strategy, but they do need to mind the store, including shepherding in-play projects, running the budget, and executive communication.
iVillage had an interim CTO when I arrived, and his help has been invaluable to me as I got my head around the extensive technology footprint here. Its made me more effective. I could choose what to focus on first, fully knowing that anything I wasn't focused on was being taken care of by someone else. I recommend a 3 month overlap as ideal.
So, for any company losing their CTO, get an Interim CTO. There are plenty of talented consultants/ex-CTOs out there to help you, use them.
Tuesday, May 6, 2008
Bloggers beware
As we are now all a part of the brave new world of blogging, I am personally discovering some of the unintended outcomes of a CTO blog.
At my previous company, I started blogging well after I became CTO, and some of my team read it out of curiosity. But now at my new company, the new technology team got the chance to read my blog before I arrived, as did other department members. An experience on my first day in the office was someone stopping me in the hallway, and saying "you must be Jon Williams, I read your blog" (hope you liked it was my first thought).
I also discovered that some the tech team learned I was their new CTO via a blog post (not mine), and not from senior management. Not a desirable outcome, yet not something we can control. After we announced my departure at my previous company, and told our contacts of the change, it seemed someone would ending up blogging about it (and did). Clearly the time when companies controlled how information is passed to their employees is changing.
Recently, a fellow CTO at a smaller company was describing how he uses his public blog to influence his internal company agenda. Making his comments public often has a larger impact on his fellow co-workers than a private email. While that is not my intent in this blog, my writings do certainly reflect my views on technology, representing my thoughts and goals.
We should all by now be familiar with the stories of technology leaders who were fired for blogging about their company's technology detailed plans and architecture. This was my main reason for not starting a blog until 2007, quite a few years after those incidents. But in the same way we all figured out the correct "tone" of email, we've hopefully figured out the right tone, content and context for blogging.
And lastly, to the question I posed to another CTO blogger that "our kids will read all our blogs", he replied "...and stop part way through and say 'Dad, your blog is so boring, its all about technology'". Yikes!.
At my previous company, I started blogging well after I became CTO, and some of my team read it out of curiosity. But now at my new company, the new technology team got the chance to read my blog before I arrived, as did other department members. An experience on my first day in the office was someone stopping me in the hallway, and saying "you must be Jon Williams, I read your blog" (hope you liked it was my first thought).
I also discovered that some the tech team learned I was their new CTO via a blog post (not mine), and not from senior management. Not a desirable outcome, yet not something we can control. After we announced my departure at my previous company, and told our contacts of the change, it seemed someone would ending up blogging about it (and did). Clearly the time when companies controlled how information is passed to their employees is changing.
Recently, a fellow CTO at a smaller company was describing how he uses his public blog to influence his internal company agenda. Making his comments public often has a larger impact on his fellow co-workers than a private email. While that is not my intent in this blog, my writings do certainly reflect my views on technology, representing my thoughts and goals.
We should all by now be familiar with the stories of technology leaders who were fired for blogging about their company's technology detailed plans and architecture. This was my main reason for not starting a blog until 2007, quite a few years after those incidents. But in the same way we all figured out the correct "tone" of email, we've hopefully figured out the right tone, content and context for blogging.
And lastly, to the question I posed to another CTO blogger that "our kids will read all our blogs", he replied "...and stop part way through and say 'Dad, your blog is so boring, its all about technology'". Yikes!.
Subscribe to:
Posts (Atom)
