Putting the bottom line up front, it is not the CEO’s job to be a technical wizard in ANY company.  The CEO has to be worried about too many other things to also need to worry about being the CTO or for that matter the CFO, CMO or any other “C”-level position within the company.  You need competent people in the CTO/CIO position doing the technical heavy lifting.

From our perspective it is also inexcusable for the CEO of a technology company to not attempt to make a connection and better understand the teams and technology that build and comprise the product offerings of their companies.

It is hard to imagine that someone would rise to the position of CEO and not understand how to read a balance sheet, income statement or statement of cash flow.  That same person, unless they have an accounting background or were a former CFO is not likely to understand the intricacies of each accounting policy nor should they need to do so.  The CEO’s job is to ask the right questions, get the right people involved and get the right outside help or advice to arrive at the right answer.

The same holds true in the technical world – the CEO’s job is to understand some of the basics (the equivalent of the statements mentioned above), to know which questions to ask and to know where to get help.  Here is some advice for CEOs who have not been a CTO/CIO, do not have technical degrees, or have never been an engineer:

Ask Questions and Look for Consistency in Explanations
Part of your job is to be a truth seeker, because only with the truth can you make sound and timely decisions.  While we do not think it is commonplace for your team(s) to lie to you, it is very common for teams to have different pieces and perceptions of the truth.  When you do not understand something, or something does not seem right, ask questions.  When you are unable to discern fact from perception, look for consistency in answers.  If you can get over any potential ego or pride issues with asking what might seem to be ignorant questions, you will find that you not only quickly educate yourself but you will create and hone a very important skill in finding truth.

Seek Outside Help
Seek help from friends or professionals who are proficient and knowledgeable in the area in question.  The proper approach is not to bring them in and try to sort things out for you – that can be very damaging.  The approach we suggest is to create a professional or personal relationship with a firm or peer who is more technically literate and can help you generate the right questions or coach you on approach to your technology team or technical concern.

Improve Your Technical Proficiency
Create a list of your weaknesses in technology – things about which you have questions -and go get help to become smarter.  You can ask questions of your team and outside professionals.  Read blogs on technology relevant to your company or product or attend workshops on technology for people without technical backgrounds.  You probably already do this through professional reading lists on other executive topics – add technology to the list.  You do NOT need to learn a programming language, understand HOW an operating system or database works or understand how “Collision Detection Multiple Access/ Carrier Detect” is implemented.   You SHOULD understand simple concepts such as the interactions between time, cost and quality in development.

We know that your responsibilities as a CEO are enormous, and your time rather limited.  We believe that simple changes to your self-education approach, additions to your professional and personal network and modifications to the way in which you ask questions can pay huge dividends to your company.

Image provided by freephotobank.com.

One of the issues all development teams will face at least once and sometimes several times as the team grows is how to allow multiple versions of the code to exist in a variety of different states.  The solution to this problem (as implemented within many source code management systems) is commonly referred to as “branching”.  The purpose of branching as described above is to allow individuals or teams of developers to work on the same code without constantly interfering with each other.  For example let’s say engineer A is working on the application’s admin module and decides to check in his work to the source code repository in order to not lose it in the event of his hard drive crashing.  Unknown to him, he has a major bug in it that prevents the admin module from working properly.  Engineer B wants to fix a production issue so he checks out the source code but cannot get the admin module working properly to debug the production issue because engineer A checked in a bug.  This scenario and many others can be avoided by proper branching. 

The term branching refers to isolating changes onto a separate line of development that does not appear on the main trunk (aka “production branch” or “release candidate branch”) of code.  You can move changes from one branch to the main trunk or from main trunk to a branch by merging.  Some shops avoid branching all together because of the fear of merging.  While merging can be problematic there are ways to minimize this issue as well that we will address in future articles.

As with most things in software development there are as many branching strategies as there are opinions and most of them have pros and cons that make them worth discussing amongst the team.  There is no single right answer for every organization, so your approach should be to choose the strategy that works best for the given the skills of the team and the toolset/systems employed.  Here are two sample branching strategies that we have seen work in the past and you might want to consider.

The first strategy, for those of us who do not need the extra complexity and want a simple way to keep our code safe,  follows the KISS principle (Keep It Simple Stupid).  In this scenario you can use the main trunk for new development and pull a branch right after the release for maintenance.  For example if you just released version 2.5 then call this new branch “2.5_maint” and use the main trunk for development of version 2.6.  The “2.5_maint” branch is used only for production fixes and gets merged into the main before QA.  This is a very simple and easy to understand strategy that suffices to keep a pristine copy of the code base ready for any production issues but does not overburden the engineers by making them manage too many branches and thus environments.  A permutation of this strategy is to leave the main trunk as the code that is in production and pull a branch whenever you start a new release.  Continuing with our example, if you currently have version 2.5 in production and are starting development on 2.6 someone would create a new branch from the main code base (trunk) and name it “2.6”.  All developers working on 2.6 check out this branch and use it for committing their new features.  This branch is utilized through QA until the code is ready for production and then the branch is merged into the main trunk.  If there have been production fixes in the main trunk these need to be either double committed to the main and branch or merged up from the main to the branch. 

The second strategy that is much more complex but tends to work well with large development teams who are releasing code at different times, typically because of an iterative SDLC, is to give each developer or pair of developers their own branch.  The developer chooses their next feature and pulls a branch for themselves.  When they are done coding, unit testing and sometimes feature testing right on their personal branch, they merge it into a release branch that is the gathering place for all features ready to be sent through QA regression for a near term release.  The advantage of this is that features can be pulled out or added at the last minute before regression and therefore the release will have less chance of being delayed because of one feature.  A modification of this approach is to have a group of developers associated with a specific release have their own branch, which in turn enables parallel development.
These are just two of the myriad strategies that exist but these or permutations of these are ones that we have seen work well in the past.  Tell us your favorite branching strategy!

In many of our engagements, we find ourselves helping our clients understand when it’s appropriate to build and when they should buy.

If you perform  a simple web search for “build v. buy” you will find hundreds of articles, process flows and decision trees on when to build and when to buy.  Many of these are cost-centric decisions including discounted cash flows for maintenance of internal development and others are focused on strategy.  Some of the articles blend the two.

Here is a simple set of questions that we often ask our customers to help them with the build v. buy decision:

1. Does this “thing” (product / architectural component / function) create strategic differentiation in our business?
   Here we are talking about whether you are creating switching costs, lowering barriers to exit, increasing barriers to entry, etc that would give you a competitive advantage relative to your competition.  See Porter’s Five Forces for more information about this topic.  If the answer to this question is “No – it does not create competitive differentiation” then 99% of the time you should just stop there and attempt to find a packaged product, open source solution, or outsourcing vendor to build what you need.  If the answer is “Yes”, proceed to question 2.
2. Are we the best company to create this “thing”?
   This question helps inform whether you can effectively build it and achieve the value you need.  This is a “core v. context” question; it asks both whether your business model supports building the item in question and also if you have the appropriate skills to build it better than anyone else.  For instance, if you are a social networking site, you *probably* don’t have any business building relational databases for your own use.   Go to question number (3) if you can answer “Yes” to this question and stop here and find an outside solution if the answer is “No”.  And please, don’t fool yourselves – if you answer “Yes” because you believe you have the smartest people in the world (and you may), do you really need to dilute their efforts by focusing on more than just the things that will guarantee your success?
3. Are there few or no competing products to this “thing” that you want to create? We know the question is awkwardly worded – but the intent is to be able to exit these four questions by answering “yes” everywhere in order to get to a “build” decision.  If there are many providers of the “thing” to be created, it is a potential indication that the space might become a commodity.  Commodity products differ little in feature sets over time and ultimately compete on price which in turn also lowers over time.  As a result, a “build” decision today will look bad tomorrow as features converge and pricing declines.  If you answer “Yes” (i.e. “Yes, there are few or no competing products”), proceed to question (4).
4. Can we build this “thing” cost effectively?
   Is it cheaper to build than buy when considering the total lifecycle (implementation through end-of-life) of the “thing” in question?  Many companies use cost as a justification, but all too often they miss the key points of how much it costs to maintain a proprietary “thing”, “widget”, “function”, etc.  If your business REALLY grows and is extremely successful, do you really want to be continuing to support internally developed load balancers, databases, etc. through the life of your product?  Don’t fool yourself into answering this affirmatively just because you want to work on something neat.  Your job is to create shareholder value – not work on “neat things” – unless your “neat thing” creates shareholder value.

There are many more complex questions that can be asked and may justify the building rather than purchasing of your “thing”, but we feel these four questions are sufficient for most cases.

A “build” decision is indicated when the answers to all 4 questions are “Yes”. 

We suggest seriously considering buying or outsourcing (with appropriate contractual protection when intellectual property is a concern) anytime you answer “No” to any question above.

It’s that time of year again that a lot of companies are conducting annual performance reviews.  One question that we’ve heard often, albeit in various forms, is “what is the path to the top technology position in the company?” 

At a high level, the chief technology executive within a company is most often either someone who has proven him/herself in the technical ranks or someone who has proven him/herself in the business and has some technical acumen or knowledge.

Unfortunately, the path alone does not determine success and you can see this from the rate of turnover in chief technologists in so many companies.   The reason for this turnover we believe is that there are so very few chief technology executives out there with all the right skills, attributes and characteristics to make them successful in their job.  Success in their job is predicated on the ability to speak to both the business and to the technologists implementing the business through software and systems and in so doing to get the right things to happen to create shareholder wealth.

“Path” then is less important than the experiences that you gain along the way.  The right question is not how to get in the chief technology executive’s office, but how to get there and be successful such that you can make a positive difference in shareholder wealth.  Whether you come from primarily a business background or primarily a technology background we suggest that you have the following skills and/or experiences:

1)      Good knowledge of your business and of business in general.  This is important for several reasons, but the most important reason is your ability to communicate with and understand the needs of the business associates in marketing, product, etc.  You must be able to both understand what they are saying and be able to communicate in THEIR language.  You are the bridge to the technology and you should not expect that they are going to understand “engineer speak”.  While it’s not absolutely necessary that you get an MBA, it is generally a good idea that you take business classes and learn the basics of marketing and finance for example.  With respect to knowledge of your specific business, ideally you will have spent time as an engineering or product manager and/or time as an analyst, manager or individual contributor within one of the business units in your company.

2)      Great technical experience.  This is the one area that can truly test the capabilities of a business person-come-technologist without a technical degree or specific hands-on technical experience.  We’ll address this one more in future articles, but for the greatest chance of success we believe it is important that just as the chief technology exec needs to be able to speak the language of the business, so must they be able to speak the language of the technologists.  We recommend time as an individual contributor within one of the many areas of technology (software engineering, infrastructure, operations, QA, etc) as well as time managing more than one discipline within the team. 

3)      Great leader.  Too many of us fall down here quite frankly.  The aforementioned points really deal with one’s ability to communicate (i.e. that he/she “speak the right languages to the right constituents”).  But that alone really won’t get things done and won’t in and of itself create shareholder wealth.  The person needs to be able to motivate teams and inspire them to not only do the right thing but that thing the right way, in the right amount of time, with the right quality and at the right cost.  The leader needs to be morally and ethically beyond reproach within the workplace (read our future articles on whether you should accept vendor schwag) and put the needs of his/her team ahead of the needs of him/herself.

4)      Great manager.  Yes, the two (management and leadership) are very different.  The person should know how and what to measure and be capable of contributing to a team responsible for determining how to improve those measurements appropriately.  They need to be able to task manage and keep things on track.  When you think of management, think of things that a good project manager needs to do to ensure that a project comes in on time.  Also think of the things that you need to do to ensure that your people have the tools and equipment to do that which you are asking of them.

5)      Great communicator.  You have all the tools to be successful with the above pieces, but none of it is worth a damn if you can’t or won’t communicate.  You need to communicate to your teams, your boss, your peers and your customers.  Truth be told, you can’t communicate enough.  Even if you’ve told somebody something, they’ve likely forgotten it due to competing priorities.  You can’t get things done if you aren’t communicating – trust us on this point.

6)      Willing to let go.  This job isn’t about the decisions you make, or what magazines you get your picture on.  It’s about creating shareholder wealth and measuring the value of your TEAM – not you as an individual.  Park your ego at the door – it doesn’t have a place in this job.  Be willing to be wrong and always look to do the right thing – not the thing that is “your baby”.  Be a servant leader and do what’s necessary to get the right thing done in a morally and ethically correct fashion.  Team success, and not your individual contribution, is what is important here.

A good idea as part of your personal growth is to use the list above and score yourself as honestly as possible in terms of skills and experiences.  If you’re missing some of them make sure you have some goals in place that help you acquire a few more of these each year so that you know when you do arrive at the CTO position you will be one of the successful ones.

The wrong selection for a new hire can make your life miserable whether you are a manager having to deal with counseling and possibly firing of the employee or a coworker and having to pick up the slack or deal with a wacko in a cube next to you.  Since the interview process is incredibly time consuming for the organization, the question we all have is:  How do you make the right decision?  Passing on great candidates out of fear can be just as detrimental as hiring the wrong person.  Here is our outline for how the interview process should flow:

Recruiting – Having a knowledgeable technical recruiter is a blessing.  They can start right away weeding out the candidates that are not up to speed on the technical skills that you need.  If your recruiter isn’t technically savvy, write up five questions for them to ask and the acceptable range of answers for each.

Phone Screen – This is a must it because it saves a ton of time and money.  We prefer to see two separate phone screens:  a technical screen performed by an engineer or manager and focused on the core technologies in which you are interested, and a second one focused on culture and fit.  For the technical interview prepare 5 – 10 questions ahead of time and try them on a coworker over lunch to see if someone can explain the answer sufficiently without writing anything down.  Engineers are notorious for being visual so this is a good check of your questions.  For five essential phone-screen questions try Stevey’s blog.  The second phone screen can be done by HR, a manger or an engineer and should be focused on culture and fit.  The goal is to compare this candidate’s style of work and play with that of the team’s. 

Code Test – This is can be a sensitive topic.  Some people swear by the code test, claiming it separates the wheat from the chaff, while others abhor it, thinking it too sophomoric.  Personally, we say that you have to do it.  Even if you’ve worked with someone in the past, treat all candidates the same and make them participate.  If you don’t want to do a separate test to evaluate an individual’s code, just incorporate the questions in the phone or in person steps of the process.

In Person – If the candidate has gotten past your recruiter, two phone screens, and possibly a code test, they are ready for the in person interviews.  I recommend three or more separate interviews with each interviewer assigned a specific subject matter to cover.  At a minimum you want one technical, one culture, and one logic (think puzzles) interview.  I like the technical interview broken out into two sections if possible; one for the specific programming language and the other focused on related technologies such as SQL.

Offer or Decline –The most important thing whether you are giving someone an offer or declining them is that you give them the feedback as soon as possible.  This will increase your chances of getting the candidate or leave them with a positive experience.  Dragging out the decision or the communication about that decision for days or weeks is guaranteed to leave a bad feeling with the candidate.  All offers should come with a drop dead date; this gives you the advantage over those other companies that can’t put offers together quickly.

Pitfalls – One of the most common reasons for a “mis-hire” in our experience is that not enough time was spent with an individual before offering him/her a job.  It is critically important that the hiring manager spend enough time with the candidate to “know” that they will be comfortable with him/her.  This is usually more than an hour.  The hiring manager must feel as comfortable as possible that the person is not only a good technical fit, but a good cultural fit as well.  A really talented engineer can completely ruin the culture of a high performing organization and cause it to underperform.  Unfortunately, it is not so easy for an underperforming organization to be changed culturally for the better with one really good hire.

We also suggest that you not give into the urge to have “everyone” interview a candidate.  If you’ve been in an interview process where you meet 8 to 10 people in 1 to 2 days for an hour each you know what we mean.  Wearing the candidate down with numbers doesn’t increase your probability of a good hire – more likely it will give you false positives or negatives.  Per our suggestion above, fewer people with more time spent with the candidate will likely yield a better result.

You might have seen the article Computer Science Education: Where are the Software Engineers of Tomorrow? written by two professors emeritus of computer science at New York University in which they cast dispersions at their own university and others for various atrocities such as removing mathematic prerequisites and not teaching languages such as C, C++, Lisp,  and ADA.  Their abstract states:

It is our view that Computer Science (CS) education is neglecting basic skills, in particular in the areas of programming and formal methods. We consider that the general adoption of Java as a first programming language is in part responsible for this decline.

Jeff Atwood from Coding Horror recently posted a similar blog about how we should teach CS.  Now we love a good lambasting of the younger generation who’ve had it so easy and blah, blah, blah…but what we find more interesting is the question of what basic skills a solid software engineer should have, regardless of when they matriculated into the venerated halls of our fine universities?  So here is our list of topics (and the reasons for them) with which an engineer should have some level of proficiency.

1. Algorithms – Engineers should know the concept of asymptotic notation (Big-O) and that it is used to describe upper, lower, and tight bounds for algorithms and how their growth can be constant, linear, logarithmic, etc.  The reason is clearest in the needs of Software as a Service (SaaS) businesses on the internet.  Much of our practice is dedicated to helping companies understand how to scale their product and technology.  Often one of the first things we find is that no one is paying attention to the way in which work is being performed by the system and no one has first looked at whether there are more efficient ways of performing this work.

2. Object Oriented Programming – Engineers should know the fundamentals of inheritance, encapsulation, abstraction, and polymorphism and how these are implemented or not in their particular language of choice.  While procedural programming is still useful and in use, in order to be a good engineer you need to understand the different programming paradigms and theories in order to weigh the tradeoffs of each and understand how decisions impact performance, scalability, and security.

3. Language – It’s not enough that an engineer knows the language they use every day.  A language is a tool, and just as a carpenter would not consider sawing a board with a hammer, neither should an engineer assume that one language is appropriate for each possible need.   With respect to the language they use most often, they should know they following:

a. Syntax – They should be able to write a simple method without syntax errors.  The more correctly that an engineer can do this the first time; the faster, and more efficiently he/she will produce code.

b. Data Structures – Engineers need to understand the common data structures such as arrays, vectors, linked lists, hashtables, map, etc.  An understanding of data structures also means understanding the performance implications of each of them and knowing when one is better to use over another, etc.  To the extent that you are using data structures that are already implemented within your language, be careful that you understand the performance implications of the implementation.

c. Types – They should know if the language is strong/weak and static/dynamic typed.

4. Design Patterns – Engineers should know about these and at least a couple of the more common ones such as factory and bridge.  Extra points for knowledge of anti-patterns.  The reason should be obvious, don’t reinvent the wheel and don’t invent the square wheel either.

5. Software Development Life Cycle – Engineers should at least know the difference between Waterfall and Iterative lifecycles and be able to argue for the appropriate uses of each.  Be careful of engineers (or be careful of yourself!) if you think that there is one lifecycle that best fits the need of every company and/or every project.  Lifecycles, like languages, are tools with specific purposes.

6. Source Code Control – Engineers should believe in the concept and practice it with knowledge of at least one platform.  All too often this topic is skipped in college and learned “on the job”.  But more and more often companies are struggling with how to perform massive parallel development and a basic understanding of the tools that enable this activity is key to being successful as an engineer.

7. Compiler and/or Interpreter Understanding – In saying this we are also implying that an engineer should have an understanding of the debugger and that they be able to read and step through the compiler output (assembly equivalent) in the debugger.   What separates an engineer from a technician in most disciplines is an understanding of “why things work” rather than just “how things work”.   It’s why engineers have bachelors and/or graduate degrees while technicians typically attend 2 year (or less) colleges.  Understanding how something gets changed from code into something easily understood by a computer is very useful in understanding how to debug what you’ve written when you have a problem.  Understand how the compiler and/or interpreter works and you will likely produce better, more efficient code.

Let us know what you think every engineer should know.