Design pattern standards

</Warning - old coder>One of my first programming jobs was writing code for proprietary hardware. I wrote most of the code after the "bootstrap", excluding a 3rd party 5K operating system (that's 5K memory, not dollars!). I wrote code to write each pixel on the screen, communicate with the keyboard and mouse, talk to server, etc.etc.</End - old coder>

It was a revolution for me when Apple and Microsoft came out with APIs to do this for you. It would be absurd to have a programer today write pixels, keyboard handlers, or operating systems. Yet why are programmers today working on writing code for mailing addresses, or work orders? Why is there no API?

Furthermore, its happening over and over again. How many programmers wrote or debugged code for address handling in the last year? The remedy to this would be a vendor or industry standard, but that's where it gets complicated.

While industry standards for communication (tcp/ip), data (XML), and the internet (HTML and http) have been hugely succesful, standards around commerce (credit cards, addresses, work orders, etc) have mainly failed. Seems we can't agree on scope.

While a single vendor (ie SAP) would solve the problem, most of us are not willing to give control away, both system and budget.

Maybe open source is the holy grail of design pattern standards. Who knows?

How ready are you for disaster recovery

With some power blackouts in NYC today, my team asked the question "How ready are we for disaster recovery?".

We do Business Continuity Planning (BCP) regularly, but there is nothing like the threat of the real thing to get the team really thinking if their plans are complete. Didn't we just change system X? Isn't system Y already running on backup? What about that new app we launched last month? How will we push latest code release without staging? Didn't Jack just replace Fred since our last DR run-through?

A CTO's job during a disaster recovery (DR) situation is to (1) create a sense of urgency, and (2) communicate to the business. I trust my team's ability to handle the difficult task of recovery once they are put on alert, and I can get out of the way.

I find it useful to treat potential disasters as the real thing, call it an unplanned drill. Ok, so power didn't go out in our NY data center, but what if it had? What if just data lines went down? It's a chance to freeze all project development for an hour or two and have your teams run through scenarios and contingencies.

Don't miss the opportunity to practise Disaster Recovery when the opportunity arises, one day you'll be glad you did.

Balancing old and new

When you have time to look up from your daily tasks, you find you come across an astonishing amount of new technology. I could easily spend my entire day looking at and researching what's out there, all of it being of potential benefit to my business.

How do you do spend time on the new and still keep focus on the job at hand of supporting your business' existing technology? Google does this by allocating 20% development time for its employees. This is a luxury most of us don't have.

The trick I believe is to quickly focus on how new technology will benefit your business (I.e. How will the iPhone impaxt your business? What impact might virtualization have in your data center? Will a wiki improve your teams productivity?). I recently became entranced by social networks, to which a fellow CTO asked "What are you going to do about it?". My task now is to marry it to a business project and objective.

I'll also strive to figure out how to incorporate the new with what's working with the old. I've heard so many technologists tell me they could do a better job if they throw a system out and rewrote it from scratch. But it's the smart technologists who'll figure out how to integrate the new with the old, maybe evn seemlessly, and eventually be able to phase out the old at the appropriate later time.

Cone of silence

I used to enjoy watching the 60s TV show "Get Smart", a spoof on secret agents. While there were many gags that stood out, one enduring one was the "Cone of Silence". Taking many physical forms, often absurd, the device's purpose was to keep the conversation private.

A technology manager needs to keep certain conversations private. You need a cone of silence with your team, where they know they can trust you to keep their confidence. This is truly important, as you'll want your reports to share all information with you, regardless of how difficult or sensitive. Sometimes its as a group, sometimes its 1-on-1.

This cone of silence also applies to networking groups, where trusted relationships allow group members to share sensitive information with each other. You only need one member to carelessly share information with a vendor to break this trust. While I belong to a number of social networks, its the trusted ones that I most rely on. I can share real concerns without fear of disclosure or reprocussions.

While Maxwell Smart's cone of silence seemed always to fail, you'll need to make sure your teams and contacts have a working cone of silence with you.

Advice from CTOs - top 10

I've gotten a lot of good advice from fellow CTOs over the years, and figured I would share a top 10 list (of advice):-

1) Get a coach (Igor Shindel) - having an executive coach has been an extremely valuable tool for me, and I continue to use a coach.
2) It's the people, stupid (Curtis Brown) - it's not about being the brightest technologist in the room, it's about supporting great technologists.
3) Reward and compliment your teams (Dan Woods) - Recognition goes a long way, plus technology teams typically work long and hard, and deserve an extra nod.
4) Bring it on! (David "Yak" Yakimischak) - When systems start to fail, don't cower and hope they go away. Reproduce the problems at will, and then conquer them. Load testing tools are critical here.
5) Make a list (old boss) - During a critical or rare opportunity meeting, make an action list, and email to all participants after meeting. Simple, obvious, yet highly effective.
6) Architecture is people (John Helm) - Have the right people in place and you'll have the right architecture.
7) Good vendor relations (Dan Holewienko) - Vendors are not out to get you (and your budget share). Make good working relations beyond Purchase Orders.
8) Give to get (Kevin Sickles) - Help out other CTOs and technologists freely, it will all come back in time.
9) Network with other CTOs (me - Jon Williams) - It's like having an all-star baseball team at your fingertips, the cummulative knowledge of a network is outstanding. And meet in person as often as possible.
10) Have fun (Chad Dickerson) - Technology is fun, that's why we do it.

Kaizen management meeting

Would you believe me if I told you that I had a "fun" management meeting? Ha, you say. Impossible. Well, it was fun.

I recently attended a (non-management) Kaizen Agile development meeting with our mixed staff/consulting team (blogged about it previously), and I became intrigued in how engaging and effective it was. Since I was only an observer (not being a team member), I wanted to participate in a kaizen meeting myself. I convinced my technology management team to join me, with the simple goal of having them take agile learnings back to their teams. I had little hope of any management outcomes, but I was dead wrong here.

We started the meeting at 4:30pm on a Friday, 5 mins with postIt notes on whiteboard, 5 mins reviewing good and bad for the week, 5 mins voting on index cards, then rest of time reviewing top cards voted for (see previous blog for meeting format details). It was fun, and incredibly productive. We discussed 6 key management issues from the week that we had voted on, in order of voting. This was one of the rare times I did not set the agenda in my own management meeting! At the end of each discussion, I handed the card to the manager who would follow up on the issue. If we were having these meetings regularly, the card would be brought back to the next meeting.

There were important logistical elements of the meeting that I left out of my previous post:- (1) beer (2) snacks (3) kaizen kit containing postIt notes/cards/markers (missing bottle opener!). What made the meeting fun was that it was like a board game (whiteboard/postIt's/cards/voting), with an element of chance as you don't know which cards will get the most votes.

My team and I enjoyed it, and we had some good outcomes which we'll follow up on. What more can you ask?

How I made the jump to technology manager

My first experience as a manager was horrible, and I swore I would never be a manager again, convincing myself that lead programmer was the be all and end all.

I eventually made the permanent jump to manager purely by accident. As a lead developer who mainly worked alone coding, I was always tagged along by a Project Manager on client meetings and projects. As we grew, I soon got sent to clients without a PM, and had to assume that role, copying what I had seen the PM do. Not even on-the-job training, more trial by fire. I coded 50% and project managed 50%. I can't say I was great, I stumbled through it, losing one client along the way. But I made it through because I communicated frequently on what was going on, and asked for lots of help when I got stuck.

My next experience was hiring and leading a technology team at my own consulting company. Managing people was way different (for me) than managing projects. I squeaked by getting the job done, but I had no touch for the "soft side" of managing people. In hindsight, I wouldn't have enjoyed working for me!

It wasn't until I got the CTO title that I started realizing that my success was dependent on supporting my team to succeed. I also realized that being a good technologist didn't translate into being a good manager (step 1 in 12 step program?). I started soliciting (and listening to) feedback on what I was like as a manager, from everyone. I made mistakes, slipping back occasionally into my lead programmer ego, but at least I was aware of these mistakes, and able to modify my behavior each time.

When learning as a technologist, I was downloading, practising and mastering new technology (think Trinity in the Matrix just before she pilots a helicopter). A difference between my technology and management experiences is that I learned technology from just a few mentors, but learned management from everywhere and everyone. And I realized management wasn't about becoming a master, but a permanent student!