The fuzzy bit

Technologists think in black and white, zeros and ones, yes or no. But management is not all about yes or no. There is a grey area, let's call it the fuzzy bit. (For non-techs, a "bit" is the smallest unit of storage or calculation, and all other elements are comprised of bits. Each of the letters typed here are comprised of 8 or 16 bits, depending on which system you are viewing them from).

When I programmed on proprietary motherboards, we would occasionally come across a fuzzy bit, which oscillated between zero and one. As a programmer, the fuzzy bit caused all sorts of inexplicable errors in my code, but in management, it's an essential tool in the process of decision-making. Why? It promotes discussion and collaboration in reaching a final outcome, either one way or another. Technologists are not always comfortable with this, prefering a known, immediate outcome. But, an outcome squelchs discussion and exploration.

As a programmer, the fuzzy bit cost me countless lost days and all-nighters, and I dreaded encountering it. As a manager, I couldn't live without the fuzzy bit.

Networking - people, not computers

I am a prolific networker, it comes from my days as a consultant, where my network was my livelyhood. I've shunned the ways of consulting for life as a full-time CTO. But I still network.

Why network? It increases ones knowledge of technology. Don't know the latest Open source CMS tools, or how to scale MySQL, or optimal email backup stategies? Someone in my network knows, and would be happy to share.

I approach networking by doing the first favor. My good friend Kevin Sickles of Sun Microsystems put it best "plant the seeds, you never know where the flowers will grow". So I plant seeds. I don't track who's returned favors and who hasn't, that's not the point. It's having a whole network I can go to with a question when I am in need.

I've recently incorporated networking as I interview senior candidates. I look for past connections, and when a candidate is not a good fit for a position, but a good technologist, I might give them advice, and maintain a connection as they track into their next job. Just because they are not on my team, doesn't mean I can't learn from them, or even recommend them to another CTO. I recently found an excellent PM through a candidate I interviewed but never hired.

My tool of choice for networking is email (was doing this long before LinkedIn). For a connection email, I'll use subject "Ping", "Hey", or "Catchup", and simply ask how are things going. That way if the person is too busy to respond, they'll understand its just a touchpoint and we'll get another chance to connect. I also try to do 2 lunches a week with my network, nothing beats a face-to-face interaction. I roll through my contact list, ping some contacts, suggest lunch with others.

I can't imagine doing my job without my network.

Perception is Reality

Technology is a service provider to its business at most companies, and its important to get feedback on that service. Its not always easy to do. Either the business doesn't want to tell you the bad stuff, or when they do, you and your team have a hard time hearing it.

I have a saying that helps frame this:- "Perception is Reality". If the business thinks we are providing bad service, then we are, regardless of what we might believe to be the facts. This is a lesson companies know to be true with consumers, yet IT organizations struggle, I believe because they are so enamored with the facts (mainly because we are engineers).

This saying also works in that it shifts focus from whether a team or individual is "wrong" or "bad", and moves focus to the type of service they are providing. A team can be good and provide bad service (and visa versa, although much less common IMO).

Technology teams that focus on service will succeed.

Early management experience

I had lunch today with a programmer I hired and managed 14 years ago (another excellent LinkedIn outcome). Besides catching up and remembering the rest of the team, I got a view into the type of manager I was 14 years ago, and... I was awful!

Back then I focused on 3 things, technology, technology and technology. There was no "soft side" of management, at that time I thought management was telling people what to do. Luckily, they were a highly talented group of programmers, and as individuals they did some great stuff with the bleeding-edge, latest and greatest technology we were using (I also hadn't yet figured out risk of using new technlogy). But there was no "team", really. People helped each other out, but there was no break-through, what I describe as 1+1=3, when the team creates an outcome that no individual could have even conceived.

In hindsight, it was an opportunity lost, but lesson learned.

Lunch AND Learn

We have a great program in our technology department that I am quite proud of, called "Lunch AND Learn". We regularly have a team member give a subject-matter expert presentation on a technology topic to the rest of the team. Lunch is provided (pizza), and the goal is to provide a learning opportunity outside of one's normal job skills. The program is the brain-child of Gautam Guliani, our head architect.

We cover a wide variety of topics (the most recent was Word & Outlook Tips & Tricks, the next is Ruby on Rails). I once gave on overview on company executives and the products/departments they are responsible for. We also had one presentation on how to give a presentation, so team members would have the skills needed to present at a future Lunch AND Learn. We quite often have non-tech department staff join us.

The program was previously called "Brown Bags" where attendees brought their own lunch, but we upgraded the program since it was so successful. I can just see the proposal for next year, "Back massage AND learn" :-). Jokes aside, this is a program that will continue to have my full support.

(Update: Gautam shares tips on how to give a good Lunch AND Learn presentation)

Ignore Technology Risk at your peril

Risk is something I never understood as a developer, optomistic is not a strong enough word to describe my approach. My favorite example was the day I independently decided our windowing system needed a complete rewrite (1988, pre Microsoft Windows 3.0). I announced to my boss that I would work through the night to get it down, and expect resolution in 24 hours. Well, two weeks later I had removed the last major bug (can someone say "whoops"?).  If I had been managing by risk, this would have been approached completely differently (I.e. Peer design review, estimate assessment, plan B fail-over plan, business interruption consideration, and the list goes on...).

Managing by risk is asking the question "What could go wrong? What might not work as planned?", predicting that likelyhood, and planning mitigations and contigencies. I will often ask my team to include top 3 risks in project status reports as a mechanism to bring risks to the fore, and believe this to be a best practise. My experience has been that known risks can always be managed, and that unknown (or ignored) risks are the ones that cause grief.

Sharing a risk is itself a mitigation, and also serves the purpose of quantifying and qualifying it. (That idea alone would have saved me 20 all-nighters). Yes, I've ignored risks. Yes, I've had grief. But I've learnt my lesson enough to know that a focus on risk is a key to success.

Kaplan on Myspace

http://www.myspace.com/kaplan - Make sure to watch the video. Fun stuff!