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!

Note-taking & follow-up.

In my job I get to formally meet with business staff and executives where the topic of conversation is technology. Typically, these meetings occur only a few times a year, and take the form of an update on what's launched recently, what's up and coming, and then significant Q&A time on what's needed, not working, or simple desired.

I treat these meetings as a unique opportunity to get feedback and requests. I take detailed notes about what is being asked for. While I clearly cannot get everything done, I find these notes critically in letting the business know that I am listening to them. I distribute my itemized notes a week or two after the meeting, follow up on any items that I have immediate answers for. I'll also review my notes 3 months or 6 months out and send further follow-up any issues or systems that have been fixed or deployed, or even just being discussed or considered. I also bring my notes to annual planning meetings as they'll influence priorities and decision-making.

I've gotten a lot of positive feedback from business users and executives that they are not used to getting such follow-up from technology. Their past experiences were frequently that they were not listened to. Interesting, this follow-up does not create the unrealistic expectation that everything will get done, a fear some technologists have (if I write it down, I am committing to it).

Note-taking and follow-up are active listening tools that will get the attention of your user-base, and help you on the road to creating a service-focused technology organization.

Architecture & People

Architecture in technology is a term bantied about with all sorts of meanings. Some use it for standardization, or innovation, or infrastructure, or platform, or interfaces. Regardless, it's clear to me that architecture is a very important element of successful software development.

My favored definition of architecture is "glue", the stuff that makes different systems work together. I also like "gap" as a description, that when something falls in the gap between two systems, it's architecture.

But architecture really means people working , communicating, designing and working together. CTO John Helm describes architect as "people working together". My focus on architecture is communication, from which comes sound architecture. Are we getting input from all tech leads, is DB team involved, what about ops? It is also key that Architecture leads not "lord over" the development teams. The best architects act as shepherds of technology, and include the development teams in technology architecture exploration and outcome, making it a team effort.

With teams in place collaborating and communicating, you will be on the right track to architecture.

Rules vs Rationales

In deploying desktop technology, we strive for standardization to make this a managable task. If every employee had a different make of PC, a different version of software, it quickly becomes a desktop management nightmare.

As part of this standardization, IT departments come up with rules / policies, like no email PST files, size limit on email, no IM software  (Note: I am not advocating these specific rules). When a user asks for something against policy, they are told "no", often with no explanation. This is where the stereo-typed, difficult IT support persona comes from.

What I prefer to do, in place of quoting policy, is to explain in rational terms the reason behind the rule. We can't support rogue wireless devices plugged into our network because it could breach are security or compromise our network performance. I'll even quote examples of past issues, which is often where the policy comes from in the first place.

The difficult thing about providing a rational reason is that you need to be prepared for an alternate view or argument that shows that the example reason is not at issue (wireless is completely separate from network and therefore poses no risk).

Technology managers need to be careful not to preach policy, but instead engage in rational dialog to reach the desired standardization outcomes.

Another reason why I blog

Saw this poem on LinkedIn answers, it's represents how I feel about this
blog.

The Bridge Builder

An old man, going a lone highway,

Came, at the evening, cold and gray,

To a chasm, vast, and deep, and wide,

Through which was flowing a sullen tide.

The old man crossed in the twilight dim;

The sullen stream had no fears for him;

But he turned, when safe on the other side,

And built a bridge to span the tide.

"Old man," said a fellow pilgrim, near,

"You are wasting strength with building here;

Your journey will end with the ending day;

You never again must pass this way;

You have crossed the chasm, deep and wide-

Why build you a bridge at the eventide?"

The builder lifted his old gray head:

"Good friend, in the path I have come," he said,

"There followeth after me today,

A youth, whose feet must pass this way.

This chasm, that has been naught to me,

To that fair-haired youth may a pitfall be.

He, too, must cross in the twilight dim;

Good friend, I am building the bridge for him."

- Will Allen Dromgoole (1860 - 1934)

Tivo for conferences

Tivo has changed the way I watch television, and there are times I wish I had this efficiency tool elsewhere.

My last two posts were (1) vendors (2) conferences, this one is about vendors at conferences. I think promotional videos at conferences are a turn-off, and there I am sitting there with no Tivo. This happened twice recently, and one was not a tech vendor but a large music company which showed a 15 minute promo of their artists. Fifteen minutes of self-glorification. Apple, eat their hearts out.

I've seen many great presentations from vendors at conferences. This happens when they stay away from marketing and discuss trends/roadmaps, or explore new concepts and opportunities. I want to hear how vendors are exploring and making future markets, not about what products they have today (I can get that by visiting their booth, website, or sales rep for that).

Without vendors, there wouldn't be (many) conferences, but vendors need to understand they are on show, and are being judged by the respect they show the audience. Present to our brains, not our budgets.

Vendors are people too

I was recently discussing vendors with Dan Holewienko, a consultant I trust, who said "vendors are people too". We sometimes forget this, instead treating them as a nameless member of a corporate entity.

Technologists may treat vendors as the enemy, especially when discussing price. Why? Because discussing pricing and terms is a battle, and the vendor is trying to push you into the highest price possible, so fight for price. I don't believe this is the right model. Vendors are business people, you're a business person, do business.

Do give vendors all the information they need to understand your business and your goals. Do share your pricing targets. Do share which other vendors you are talking to. Do share where you are in approval process. Do negotiate. Do give losing vendors your final decision and reasoning.

If you haven't had significant experience negotiating and working with vendors, hire an independent consultant who has.

Working with a vendor is not a transaction. Maintain a relationship with the vendor, touching base at least every 6 months. You don't have to purchase anything to touch base, but you'll be better off when you do.

Conference day-dreaming

I've been lucky enough to attend a few 1-day conferences recently (last year was a no-conference heads-down year). While I find the hit rate for a good presentation is about 50%, what I value most is taking the opportunity to lift my head out of the day-to-day and think openly about future technology plans.

While the conference content is typically valuable, that's not where I get the most benefit. When a speaker is interesting but not completely engaging (typically good content and poor presentation), I find my mind wondering to my own ideas and plans. Are we planning SOA? Where does Agile fit? What about virtualization? I'll convert what the speaker is saying into my own thoughts, teams and plans. Sometimes it's completely unrelated to the speaker's topic, but triggered by it. I come up with more ideas at conferences than at any other time.

My team gets a lot of spam email from me at conferences, "what about this...". What I am trying to do is engage them in my new thinking. Frankly, a better way to do that is to take them to the conference with you. If you can't do that, then write up your conference notes and share them with your team.

Give yourself a "safe" place away from your day-to-day responsibilities to day-dream about your technology plans.

Testing assumptions

When I was a computer science major, our available computer lab time was extremely low in my first year. This drove me to come up with the perfect solution in my weekly coding assignments, since I had little time for trial and error. I remember one major assignment where I only compiled twice (one minor mistake), and thought this was perfect. I've since then spent the rest of my career unlearning this training, clearly there is no "perfect".

Like many technologists, I assumed outcomes without fully testing my changes. I see this is over and over again, and I encourage my team to "try it out" or "show me" or "ask". Because developers work in a virtual world, they extrapolate and make assumptions about their code/config changes, its their MO. Because managers work in the real world, they need to check these assumptions. Does your new printer work? Is the new blackberry working same as old? Can you access that directory now? Is date range on that report query what you needed? I have an adage that it doesnt work until it's been observed to be working.

Test-driven development is a great step towards getting developers to test their assumptions, but many businesses could improve with a test-first CTO.

Why Do I Blog?

I've gotten this question a lot, "Why do I blog?". The simple answer is, "To share my technology management experience with others", but let me expand on that.

In my own career, I found learning new technologies both challenging and rewarding, and I thrived on them. But when it came to management challenges, it was a miserable. I failed consistently, and I believe that I failed because (1) I had no management training, and (2) I had no management mentors (I did have great technology mentors).

What makes a great technologist is very different from what makes a great manager. But over time, through trial and error, I overcame my shortcoming, found some kind mentors, and finally had some break-throughs in management, along with the more infrequent setbacks. One of my break-throughs was soliciting input from my network (and listening) about their management advice and experience.

My goal now is to be able to assist great technologists become great managers, with (hopefully) significantly less pain than I went through. It's not hard (like writing a new operating system or learning a new programming language is hard), but it does require a different approach, a different point of view.

This blog is targeted to technology managers or "would be" managers. I manage every day, and I hope my little insights help you achieve your management goals.

Now crossblogging

Since I do all my blogging via email, and Blogger supports email (MovableType does not), I am going to continue blogging here, and then crossblog to my Infoworld blog at http://weblog.infoworld.com/ny-cto .

MY BLOG HAS MOVED

UPDATE Nov 2009: I stopped blogging for Infoworld, this Blog has all my posts. Ignore below.

My blog has moved.

The folks at Infoworld have offered to host my blog, please switch your readers/feeds to :- http://weblog.infoworld.com/ny-cto

(UPDATE: since I do all my blogging via email, and Blogger supports email (MovableType does not), I am going to continue blogging here, and then crossblog to my Infoworld blog at http://weblog.infoworld.com/ny-cto )

Kaizen meets Agile

I recently sat in on my first ever kaizen meeting (I am learning Agile by observation). The purpose of the meeting was to review the week, a post-mortem of sorts to discuss issues in an open, constructive way. One meeting directive is "Blame has no place in kaizen". This meeting was strikingly different from other meetings I attend.

- Step 1, each team member wrote an action or issue from the week on a postIt note (different colors help), and placed on a whiteboard which was split into Monday to Friday (left to right), happy to sad (top to bottom). This was frenetic as they had only 5 mins, and were dodging each other.
- Step 2, each day was reviewed, both the good and the bad. As this was occuring, members were transfering issues to index cards (a staple of Agile processes). Interestingly, one of the sad postIt notes was "spectator in kaizen meeting", referring to me.
- Step 3, index cards were laid out on table (including some old ones from previous week), a postIt affixed to side of each card, and team members voted which issue they wanted to discuss, having 5 votes each to distribute among cards. Very democratic.
- Step 4, index cards we discussed in detail in voting order until meeting's end (1.5 hours allocated in total). Cards we given to members who would work on issues the following week.

It was really quite amazing. My observations of the meeting were:-
1) Interactive, due to physical components (posting & voting)
2) Successes were acknowledged and celebrated
3) Opportunity to vent
4) Lo-tech (pen & paper)
5) Productive
6) Fun

Fun? Yes, fun. A fun post-mortem. But aren't post-mortems supposed to be serious affairs? Well, this meeting was serious, and productive, and fun.

CTO as translator

The job of a CTO is to translate technology to business executives. I found a recent excellent example of this, a 4 min video on how a wiki works. I wish I could say I've perfected translation, but frankly its not always easy, and I have my slip-ups. Sometimes I get asked what an acronym means and I've forgotten, but I've probably already erred by including it in the first place.

When I am communicating an issue via email, I try to keep it short, in 3 sections:-
1) What happened - 1 or 2 sentences, mentioning business impact, not just servers/services
2) Next action - usually a now and later, or plan A/plan B
3) Decision needing executive input ($'s, unscheduled maint downtime, project delay, etc).

The key is to keep it short (just the facts), and to reread it with a non-technology eye. Using bullets helps. I'll sometimes run it by a non-technologist first to see if they understand it. Just make sure not to let your executive emails get lost in translation.

The check-in

We all make assumptions about our communications. We assume that email gets read and understood, reports are reviewed, decisions made. Well, guess what? Executives and managers get hundreds and hundreds of emails a day, and they don't always take action on every email. An issue with email is that it's a one-way dialog. What if the receiver has a question or doesn't really understand the issue, and therefore can't make a decision?

To get past this possible impasse, I use the "check-in", either email or even better, in person. If it's email, I will send a followup to a long or complex or critical email, with simple text asking "does this make sense". I'll also send to mutliple business managers if possible, knowing that not all will respond.

I also do the "walk-around", where I'll walk from office to office to touch base with execs or managers, and simply ask what's up. Did you have any follow-on questions to email X? Any other issues? Email is a simple tool which fails when things get complex, and is never a substitute for a real business discussion.

Until the 20-something execs who use Instant Messenger (IM) take over corporate america, rely on the check-in.

Owning mistakes

I've made lots of mistakes in my technology career, call them my battle scars. From when I was a junior developer (accidentally typing DEL *.* when I meant DIR *.*), to significant management mis-steps (under-investing in Infrastructure). They've shaped me, and made me a better manager. It's what people mean when they say they are "experienced" (now there's a euphamism!).

One thing I've learned is that making mistakes is a fact of business. It's unavoidable if you are pushing past norms, what we call "stretching". Trying not to make mistakes is not a good strategy, the outcome will be one of conservatism and negativity, and many IT departments are view this way.

I have a few simple rules about mistakes, for both me and my team:-
1) We are all allowed to make mistakes, no blame will be laid
2) Mistakes are an opportunity to learn
3) Get lots of opinions and input to mitigate against mistakes
4) Don't make the same mistake twice
5) Own the mistake

This last one is key, owning mistakes. There is incredible power in saying "we screwed up". Acceptance of mistakes is a key to conquering them. Some of the best leadership moments I've witnessed are around owning mistakes. I know I will follow somene who admits and owns their mistakes, and so will your teams.

Mitigation solves problems

Technologists love solving problems, that's how we are wired. But not all problems can be resolved, or at least not in a timely manner. Mitigation in technology terms means alternatives for a when a problem occurs, reducing or completely removing business impact. I find mitigation to be an under-used tool.

By my own definition, an outage is a system incident which negatively impacts my business, either staff or customers. If an outage occurs which has no impact, then it was never an outage, and will be reclassified as just an incident (significantly less severe than an outage). A clear example of this is our RAID systems, where a disk fails but the outage has no impact. In this case, the "R" in RAID stands for redundancy. Unfortunately, redundancy across all systems is extremely expensive and complex.

I've often asked my teams not to focus on problem-solving, but instead focus on mitigation. If system X fails, how can we get services back up without fixing the problem? Doing this in advance will create a level of preparedness for the inevitable system issues occur.

There's another artifact of mitigation that's less obvious:- Mitigation takes the pressure off a situation. An outage that has no recourse is high stakes, high pressure, and not the best conditions for you and your team's optimal performance. Mitigation can then become the safety net as the team performs their high-wire act. For me, mitigation solves problem.

The stuck bit

To follow my last posting on The fuzzy bit, another bug we had on our internally built motherboards were "stuck" bits (similar to stuck pixels on a monitor or flat-screen TV). These bits were much easier to diagnose and discover than a fuzzy bit, but pesky none the less.

Technology teams sometimes get viewed as the harbingers of No when it comes to working with the business. No, we are too busy. No, its too complicated. No, we can't reuse it. No, but you just won't understand why (the all-knowing IT). This comes from technologists being logical, binary engineers. And since saying yes would require knowing all the facts, and how can anyone know all the facts over a first conversation, they say no. They don't really mean no, in fact, they are often open to the idea, but that's not the message they send.

Technologists need to work on how to say "yes", without committing to deliverables in the same breath. Yes, that's a good idea. Yes, its worth further discussion. Yes, your business needs technology innovation. After all, the business sets the agenda, not technology. The answer should always be yes, it's just a matter of how, when, who and where (and how much $). Then your No bit will get unstuck.