« More Pictures from IIW2005 | Main | Decipher This »
CTO Breakfast Report
This morning’s CTO breakfast was a lot of fun. We’re getting a very good turn out and the discussion is excellent. The tenor of the discussion is different than at other technical meetings because the group has a fair number of CTOs, past CTOs, Director of Engineering types. That said, it’s not exclusively that—there are plenty of young, fresh perspectives as well. It’s a great mix that leads to good discussion.
We started off with a question about recruiting good technical talent and that led to a 50 minute discussion about hiring, managing, and, when necessary, letting go of programmers. Some of the comments from my notes:
- There was some discussion of testing and screening candidates with the observation that often seemingly good people can’t answer simple technical questions. Is the set-up too artificial (i.e. no access to references, standard environment, Google, etc.)? Are people just nervous or intimidated? How can this be done better?
- Ask questions about outside interests, particularly those that are technical. Has the person every participated on an open source project? What code do they write when they aren’t forced to?
- You have to be willing to get rid of people that don’t work out. Engineering organizations don’t always hold everyone accountable for good work. Use a mandatory 90-day probation period.
- No one in the room has used LinkedIn with any success to find employees although several had tried. some had used it to find jobs.
There was a lot of discussion about DRM and the increasing balkanization (my word) of the user experience. Scott Lemon made the observation that book publishers the next big battle. Textbook publishers will fight things like MITs online courses because it cuts their revenue. Publishers sell textbooks by providing free course material to instructors that’s tailored to a book. They all want to know how their “content” and (mostly) their revenue model can be protected.
I posted a short piece on wikis at Between the Lines yesterday and this morning got a comment back from someone to the effect that current wikis are too technical. Regular folk don’t want to be bothered with mark-up. I brought the comment up.
There was consensus that wikis are too technical and markup doesn’t make sense to most people. Even people who think of themselves as “technical” ask “how do I use this thing?” Written text has a mark-up of sorts called punctuation and even educated literate folks struggle to get punctuation right. (See Eats, Shoots, and Leaves)
We need a web-based editor that really works. There are plenty of Javascript tools out there, but they suffer from two fundamental problems:
- Poorly chosen feature sets.
- Fragmentation. Its almost as if every document you write had a different editor.
We need 2 or 3 really good editors, not 1000 bad ones.
A few other things that were mentioned and people might want to look at:
- Ajaxpatterns.org - writing a book in public.
- Flock - suite of browser tools with an open API and modular architecture.
- Mologogo - $60 pre-paid cell phone married to a GPS tracking service.
Posted by windley on December 2, 2005 1:20 PM
Comment from Bryant Cutler at December 2, 2005 2:21 PM
Thanks for reporting on the CTO breakfast for those who can't make it - it's always interesting to see just what is discussed...
On the issue of document editing you brought up... why is there more than one wiki syntax? If a single graphical editor is going to make wikis easy for nontechnicals to edit, the wikis will have to agree on some kind of syntax first (I'm continually amazed at the number of wikis people are still running that don't allow spaces in title - come on! and why can't wikipedia start an article title with a lowercase letter??)
Comment from Nathan at December 2, 2005 8:42 PM
Ditto on the reporting. I was sick and couldn't attend this one.
I was reading a 'wikibook' tutorial about blender (an open-source 3d modeling program) yesterday and got stuck in a section that assumed an older version of the program. When I finally figured out what the problem was and how to work around it, I edited the page and added a note for anyone using a recent version. It felt really good. To my surprise, they didn't even force me to register.
Comment from Jordy at December 3, 2005 1:27 PM
In my opinion, every professor who requires group papers should require groups to use a wiki. I've used wiki for several group papers and have found them to be indispensable tools for collaboration. They enable students with varying schedules to get together and write without needing to be in the same room at the same time. Because everyone can edit, wiki papers come together with more consensus and fewer errors as well as better flow and more consistent style and formatting. Material is not duplicated and problems with content can be fixed well before the last night. By allowing the quality of contributions to be reviewed in real time, wiki usage also discourages social loafing and procrastination.
Despite our successes, some students in my groups have struggled with the syntax. My observation, however, is that it’s always the ones who don’t do real research, intentionally pack papers with fluff, and (as Phil pointed out) haven’t figured out the syntax of sentence structures either. In other words, syntax problems happen mostly because people don’t care and don’t try. That being said, good graphical editors would beat down the learning curve and encourage broader usage. Those are good things.
Comment from Carlos Ribeiro at December 5, 2005 2:29 AM
I have some experiences to share regarding the recruiting problem. I have lots of experience in the IT field (more than 20 years) doing almost every imaginable job - from computer maintenance to programming to system analysis, and now network engineering. I tend to have trouble answering a test question from the top of my head; instead I rely upon my ability to find the answer quickly, either on the manual or googling around. I'm not the kind of guy that gets a dozen certifications; in over 20 years working in IT the only one I got is a CCDA, and that was only last week, as required by my current employeer. However, I often solved problems that certified people could not. I reckon that I'm really good at diagnosing problems, and that's a specific skill that depends more on a different mental discipline than on certification-style knowledge. It depends on how you look at the whole issue, how you proceed towards isolating the problem, and finally, how you design a bullet proof test case to make sure that you really found the cause. I'm usually hired by people that saw me working with a real problem; I was never hired based on a single interview.
More recently, I started to manage a small technical team. We're still pretty early in the team building process, but one of the hardest things is to select the right people. Some people are too lazy (never follow rules); others are too disciplined (always follow rules, which may a problem sometimes). Some people get to known every little detail in the manual, but are never able to turn that knowledge into results. Others seem entirely disconnected from the world, but are able to come up with a solution that nobody imagined before. Selecting the "right" people is hard. But I like it a lot, because in the end, it's always about people, and that's the most important part of the job.