The Pensive Collaborator

Do you find yourself feeling frustrated when you collaborate with certain people? Do you feel like they respond to your written communication in fits and spurts? Sometimes the conversation flows but other times they act like a communication black hole, killing the exchange in the process.

I think there's a certain kind of collaborator whose primary characteristic is that, when it comes to written communication especially, they think deeply and seriously before responding. These people are pensive and I think I am one.

I find it very difficult to participate in online forums, mailing lists and even, to some extent, email conversations. I'm not overly private but I'm coming to understand I'm pensive. Written communication comes to me after deliberation.

I read a thing and I think, "Oh, I have an opinion about that." I'll explore the opinion enough to give it a mental title, a headline maybe. But then it needs to sit. There's a part of my brain that fleshes out opinions and makes connections while I'm doing, well, pretty much anything else. The anything else could be paid work like consulting or programming. It could be exercise or taking my wife on a date or a hike with my son. I may come back, do a little research to fill in gaps in my understanding, then put the conversation back on the shelf. At some point the processing is done. I have an opinion and am ready to elucidate that opinion. I'm faced with a dilemma. Do I actually engage in the conversation? Is my pensively-formed opinion still relevant?

Face-to-face I don't have the same problem. It makes me wonder why writing is such a different kind of process.

If you come across someone who seems to respond in fits and spurts to your emails or tweets you might ask yourself if they are pensive collaborators.

Probing Code Quality

A friend of mine recently started as the CEO of an exciting new Software as a Service business. He asked me what I thought about helping him evaluate the quality of the software asset he now manages.

Code quality is such a huge topic. It’s a question of fitness for purpose. Your answer varies widely depending on what you need that software asset to do for you. For example, the method you use to assess the quality of a program to scrape Craig’s List is vastly different from the method you use to assess a web application you use to operate your online auction. This friend of mine has something closer to the auction site than the Craig’s List scraper.

Here are 10 questions I suggested he explore with someone technical he trusts:

1. How stable is the product right now? What are the outstanding functional defects and non-functional rough edges?
   
2. How well specified is the application? If we broke a feature tomorrow, how would we know? Are the specifications executable or do we need a person to manually verify new builds?
   
3. How complex is the application right now? How long would it take someone generally familiar with the technology to isolate and repair a problem? Unneeded complexity increases the likelihood of future defects and makes it more difficult to find and retain developers.
   
4. What third-party dependencies exist? Open source and commercial libraries imply license terms, fees, etc.
   
5. How does the application scale? What can you support on the current infrastructure and what’s the incremental cost of selling new subscriptions?
   
6. What provisions are in place to deal with disasters? What is the physical server architecture? How does the system handle losing critical components like servers, switches, load balancers, etc?
   
7. What does the development environment look like? What does it take to bring new developers into the team and get them productive?
   
8. How is the source code managed? How do you reproduce particular configurations of the app for historical or bug-fixing reasons?
   
9. What is the build and release process? How do versions of the software promote through different environments from development through testing to production? How do I safely push new releases into the production environment and how do I revert to previous versions if that becomes necessary?
   
10. How do you know how the app is performing? Does it notify you when something goes wrong? Are there any monitoring or management services keeping watch?

Startup CTO: Could It Work?

A CEO friend of mine recently asked my opinion about Tony Karrer's Startup CTO or Developer article.

I think the part time CTO could work. Here's why.

From a development and operations perspective, the common element in successful software businesses seems to be the technical leader. Their primary characteristics are deep technical skills and a hacker mentality (about the word hacker). They tend to have the knack for architecture. They tend to be capable planners when it comes to issues like performance and security. They tend to have the programming background to lead competent people by example and dig in and prove it where necessary. They tend to know where to find good help in terms of employees and consultants. They tend to know the operations side of a software business well enough to be the one overseeing deploys, crafting the infrastructure plans, and monitoring the health of the product. They tend to be plugged in to tech news sources to be aware of trends and understand how those trends could impact the business. They tend to understand the product management side of the product well enough to guide the technology in a complementary way.

I think that's the person you need. Common sense says you'd do your best to hire or otherwise permanently engage that lead developer. If you think that's person you need, the question becomes "what else do you expect a CTO to contribute?"

The answer to that question is contextual, based on what you, as CEO, and your board believe your "Founder Developer Gap" (reference to the Tony Karrer blog entry) to be. Surely there are some business and technology strategy problems you're going to need help with that your lead developer can't help you answer. Assuming you can't or don't want to afford a full-time CTO, that seems like the perfect fit for a consultant and that seems to be where this idea of consultant CTO makes sense.

In thinking about this problem I asked around a fair amount and couldn't find any solid answers to the question "where have you seen someone in the role of CTO for a startup do a great job?" My colleagues and I interact with startups a fair amount because we're consultants. Many of us have done freelance work in the past, often for startups. We each pointed to key technical leaders that drove the development and operations parts of the businesses. A few had the title CTO but they all fit the technical rock star and hacker profile.

The main thought that gives me pause is that of earned authority. It's about leading by example. Depending on how much face time the consulting CTO has with the team, it could be extremely difficult for a consulting CTO to effect change. The consultant's advice would have to be filtered through the leaders in the trenches. Yourself and your lead dev, along with your other key leaders like product and sales managers, would need to listen, internalize and execute the strategy. I doubt a consulting CTO would have the privilege and honor of earning your team's respect directly. That generally comes from running the business together.

The other problem area is that of growth. Assuming your business succeeds and grows you'll need a proper CTO at some point. Your lead dev may or may not make sense to grow into that full-time CTO position. You could have the same problem hiring for other leadership roles too like Director Of Software Development or Master Bottle Washer. It feels like tomorrow's trouble to me but it's something to keep in mind.