Fog Creek Software
Discussion Board

New CTO Looking For Help

Hey everyone,

I've been working for a small company as a computer engineer for a few years and we are about to get bigger.  Because of this, I'm going to be moving into a CTO-type position over all of our programmers.  I know I can do it but it would be a lot easier if I could get a head start by learning from others' experiences.  I've read through almost everyone of the articles here and was wondering if anyone had any additional information they could pass on?  Maybe another site or two to look at, any opposing arguments about the articles here, books to read, general tips, etc.  I really am building our whole infrastructure from the ground up so anything you can contribute will be most appreciated.

Thank you.

Chris Mills
Thursday, April 4, 2002

I like _The Deadline_ by DeMarco as a fable. The quickest summary of that is to hire good people and let them work. Your question would (imo) be easier to answer if it were a little more specific about what subjects you think you need to know some more about, and about what books and experience you have already, and about specific problems you anticipate.

Christopher Wells
Thursday, April 4, 2002

Well, I've read everything here and I just got "Peopleware" but haven't yet read through it.  Other than that I've just talked to people I work with.  So far, I'm planning on getting everything from the Joel Test implemented and have setup a salary structure similar to that in the "Fog Creek Compensation" article.  I'm also planning on setting up "flex time" so programmers don't have to be in at 8am.

I guess I'm mainly looking for other books or articles to help me prepare and tips or examples of what to do or, more importantly, not to do to limit the mistakes I make or will potentially make.  I've, sort of, been in this role for a while but, like I said, we are restructuring and I'm now going to have more control.

Thank you.

Chris Mills
Thursday, April 4, 2002

I'd guess that the biggest mistake you (collectively) could make is to disappoint (or to not acquire in the first place) your customers and your supply chain.

Sorry: still too general for me. <g?>

Re this: "Other than that I've just talked to people I work with" an obvious but trite suggestion is to also listen to these people; but also to keep tabs on what they're doing and have done, to correct their trajectory if it's heading into the weeds.

There may be two kinds of "CTO": a "chief scientist" who does research, whose Name is supposed to help the company's reputation, who suggests the future; and a "chief manager" who makes any tactical decision that the team leads cannot make ("what did this customer want anyway?" "do we have time to do this?") and who otherwise acts as a firewall.

I'd expect the team lead (the "chief developer") to help with setting the practices or process (eg "yes we're going to use version control", "no we're not going to use *that* technology").

Christopher Wells
Thursday, April 4, 2002

Yeah, I guess CTO is a little vague these days.

I will the only management on the tech side.  There will be team leads that will help with some of the design and assignment of tasks but everything else will be me.  I will be talking to everyone non-technical about the technology.  I will be making all tech decisions.  It is going to be basically me and then 10-20 programmers for at least the next year or two.

I guess I can always come back if there is something specific I have questions about.  Right now I'm only really looking for general ideas and thoughts.

Thank you.

Chris Mills
Thursday, April 4, 2002

Sounds like a VP of Engineering. I'd hire and retain talented engineers. Manage business expectations. Eliminate scope creep. Deliver on time, on budget and reasonably defect-free. Understand the business cost/benefit tradeoffs.

Thursday, April 4, 2002

Agree. You need to understand the financial side of things: Like budgets. Give people power over their area, including money, but hold them responsible for spending it. That, I think empowers others incredibly.

Thursday, April 4, 2002

What do you think would be good benefits to offer or incentives to offer to help get the talented people in and keep them?

Anyone have any ideas on what a just-graduated-with-a-4-year-degree computer person makes or expects to make a year these days?

Thank you.

Chris Mills
Thursday, April 4, 2002

Infoworld has content directed to CTO's. I'm sure there are others online.

Rich Fuchs
Thursday, April 4, 2002

> What do you think would be good benefits to offer or incentives to offer to help get the talented people in and keep them?

A place where they can continue to learn, and a suggestion that their financial and other rewards will be tied to their own performance (anticipated and/or proven). Beware though of trying to implement that, because they may optimize for whatever you define as their success criteria, to the possible detriment of any other criteria. Those are the basics imo; after that, individuals have individual preferences (could be flex-time, state of the art tools, after-hours socializing, ...).

> Anyone have any ideas on what a just-graduated-with-a-4-year-degree computer person makes or expects to make a year these days?

Where in the world?

Christopher Wells
Thursday, April 4, 2002

hmm.  Here's a few books I like:

The mythical man-month. (Brooks) Required reading.

Peopleware.  (DeMarco/Lister) Really is that good.

Rapid Development. (McConnel) A fast-paced development "cookbook"

Successful Software Development (Donaldson/Siegel) Academic but you've _GOT_ to "get" finances or you're gonna have problems.

tactics are my _next_ post ...

Thursday, April 4, 2002


(1) If your developers are good enough to do thier own systems admin, give them a "cafeteria-style" budget for hardware, software, books, and training.

(2) Your really -CAN- pay people less with a few perks.  Instead of an extra $5K in salary, spend $4K on training, and committ to it every year.  Also buy lunch on fridays and keep your people learning new stuff like CMM, PSP, Xtreme Programming, etc.  Then have someone present a powerpoint presentation on "new idea X" on a friday (with free lunch.)    Blammo.  Now all your people know a little bit about CVS, or MakeFiles, or technology X, and it cost you the price of a book and some big macs.

(3) Use Xtreme Programming as a methodology, or at least as much of it as you can get away with.  No, heck, use it all. :-)  Extreme Programming Installed by Jeffries, et al is a good book.

(4) One big point of 1 and 2 above is to get your people thinking, learning, and improving on thier own.  When you want to try out a new technology, don't mandate it.  Instead, go to one of the senior programmers who you know by temperment would like X, and say "Have you heard of X?  I got a book on X.  How about you take Friday afternoon off and read the book and let me know if you like it?  If you like it, you can maybe present on it next friday at lunch ..." (Now the person you are talking to is doing CTO-like stuff and learning to teach CS ... which will build his resume and value ... and get him excited ...)

(5) Don't ever waste your people's time.  Get them coding as much as possible.  If you find status meetings generally consist of you talking to one person, then another, and on down the line ... why not just do MBWA (management by walking around) and skip the status meeting?  Why not do one-on-ones instead of status meetings?  If you connect with your people on a personal level, they'll find it a lot harder to hate and resent "the man."  (This is esp. important when people need time off because they are getting married, having children, building a house, whatever.  If you know to ask and plan in advance, they'll have less to resent.)

(6) Learn the business stuff.  Learn to make Function Point, Developer-estimate, and risk-adjusted estimates for

(7) Grow your capability through the use of source-code control, bug tracking software, ok, ok just use the Joel Test. (I also like CMM to SOME extent.)

(8) Make liberal use of time off as a reward, especially if you people are working voluntary overtime.  Kick them out at 5PM if you have to, esp. if projects are "thrashing."  Track overtime; it's very rarely to never really free.  (over-use of time off can be just as bad ...)

(9) Never let a perk become a guarentee (except perhaps for training budgets) - You can be friendly, but you have to maintain authority.

(10) Be aware of what your people are doing!  Dis-Connected-ness is bad!  (I knew of one programmer who was supposed to be working on a remote system for 2 weeks.  His manager asks him "So, how have things been working?" and the programmer responds "I dunno.  The telnet account/password I got didn't work...."  What has that programmer been DOING for the past 2 weeks? That's potentially thousands of dollars of man-effort down the drain ...)

(11) Check out for wages.  It really depends on the experiece, ability, GPA, school, and your location.  (If you give me some details, I can come up with actual numbers!) A MIT or Canegie-Mellon CS graduate with GPA around 3.8 and a good internship might want $50K to start, more in california.  A 2nd-tier state-school graduate in CS with lower GPA and no internship might be willing to start for more like $30-$35K.  If you make it clear that the 1st year wages are low and promise and agressive training package, you can probably bring in  a new hire for $25K.  (Depends on how agressive.)

Why not hire final (or next-to-final) semester CS students as interns (testers) at $6-to-$10/hour, then hire them back after they graduate?  That way, you can get a real idea of the value of the person before you make the "real" offer.

just some thoughts,

Thursday, April 4, 2002

More on 6 above:  You've got to understand the financial side of software: budgets, total cost, how to make a profit, the giant sucking sound of money that happens when people don't have work to do.  Much more than I can cover in a post.  Writing complete profitiability-included project plans really helps. :-)

Thursday, April 4, 2002

Another thought:

  A well-thought-out mentoring/free lunch/read some books/take a class or two a year/get some time off to study for class training package can be really really cheap.

  And, to a new hire, a training program can be more valuable than a few $K in salary.  Certainly more valuable to your new employee when considering job offers than it actually costs you, because the productivity improvement pays for itself.

Thursday, April 4, 2002

My current thoughts:

1) Ask, listen and learn
Live is really easy. All you have to do is listen and learn. Just ask your developers/customers/[anyone you consider intelligent] what way to go. Chances are quite a few of them have really bright ideas. It's up to you to filter the good stuff out.

Far too many people in charge think they have to come up with all the bright ideas themselves and never ask. Asking is not a sign of weakness, it's a sign of strength.

2) People
Get the best. They are 5 to 10 times as productive. Give them as many freedom as you would have liked to have when you were still a full time programmer. Make them feel personally involved by giving them real responsibilities and clear traceable targets.

3) Don't be a revolutionary
If your company is healthy, think three times before you revolutionize. Just tweak constantly, to reduce the risks or at least bet on multiple horses. A major technology change might turn out right, but generally involves high risks.

4) More learning
Read lots of books and visit the good sites. Highly useful knowledge is lying on the streets these days. The problem is that most people are to lazy to pick it up. Why has not everyone read Peopleware or McConnell? The mere fact that you posted this question tells me that you have the right attitude and will be all right.

Jan Derk
Thursday, April 4, 2002

In addition to the good advice above, try to spend a little time thinking about your "social situation".  90% of your job from now on will be dealing with people (if not more).

It sounds as though you are being "promoted" to lead your current peers.  It's never easy to be sombody's workmate today and boss tomorrow. "Leadership Effectiveness Training" by Dr Thomas Gordon is a book which I recommend  at such a time.

Peter WA Wood
Thursday, April 4, 2002

MatteyBoy are you kidding with those salary figures? Anyone who knows what they are doing wouldn't consider that. Most good programmers are either independents or work for a startup with potential. They create their own "experience" by doing things on their own. I have to question any programmer who works as an employee for nothing.

Mr. Orange
Thursday, April 4, 2002

This is my advice.  The most important thing for tech people is to believe that they are doing something important.  Maybe they are making a statement, or introducing real quality into a market that didn't have it.  Whatever.  It has to be for something more than a paycheck and beating Q2 estimates, or even mere survival.

Jason Trelis
Friday, April 5, 2002

One tip:  Dont get sucked into HYPE that doesnt solve your business problems.  I feel programmers today sometimes need to be curtailled.  Many coders today are more interested in skillsets, then always implementing the most APPROPRIATE solution to your problem.  To be fair, sometimes they just don't know any better.  It is very easy to be misled all the hype that is prevalent in the tech media these days. 

There is also a LOT of misundstanding of what a certain technology is and is not.  For example, look all the XML hype.  It was commonly asked "Will XML replace Windows?"  People lost sight of the fact that it's simply a data file format, no more, no less.

Everyone talks about UNDERengineering a project, but there's a lot to be said for OVERengineering.  This article is a great example:

How Scient helped go from launch to bankruptcy in less than 60 days

Friday, April 5, 2002

Mr. Orange,

I think MateyBoys salary figures are accurate.  You need a wake up call.  Grads are waiting tables again.  They'll gladly take $35k in a metro area, and $25k in a rural, cheaper area.  Also, your idealistic talk about startups and changing the world is nothing more than amusing at this juncture. 

Your ego and "head in the clouds" stance is a detriment that will work against you, regardless of your skillset.  I hope you are comfortable in your current position b/c you are in for a rude career awakening on many fronts. 

Friday, April 5, 2002

The numbers I gave represent the midWest.  I just did a quick look at's cost of living gizmo:

And it said that in order to maintain the same style-of-living, you'd need to make 81% more in California.  So the numbers for CA (TO MAINTAIN THE SAME LEVEL OF LIVING; NOT WHAT EMPLOYERS ARE PAYING) become:

Entry-Level: 45K

Metro Area: 63K

MIT Graduate Sum Cum Laude: 90.5K

  Do you like those numbers better?

  Another thought:  Many companies realize that the first year a coder is out of college, the company will be investing in the resource.  Then, once the person has "experience", they can get much higher offers.  So a _LOT_ of companies pay very little money the first year (or two) of employment; then the employer either starts throwing in hefty raises, or the employee can move on to somewhere willing to pay him.  (It's easy to give big % raises out when you start out very low-pay.)

As for "does working for a company make you a wage slave?" that's a discussion I will ignore.  Starting your own company, consulting, joining a start-up for stock ... those involve risk. 

If (odds_of_success * potential reward)
  strikes you as an attractive number
    ... that's completely up to you.
    Folks with a family, house, etc often require
    a higher odds_of_success ...



Friday, April 5, 2002

oh, and I also have tuition reimbursement (100%), 401K match (within limits), a generous vacation package, flex time, etc, etc.  Without these, I would want an extra 5K, which would look more like 7-10K once you take out taxes. :-)

Seriously, benefits matter.  Or, you could go the other way:  Figure out the industry average and pay +10% or so, and skimp on benefits.  But I think the intangible value of benefits is generally worth more than having the cash-in-my-hand ...

Friday, April 5, 2002

Yes for entry level skills around $40K/yr in a big city is OK. And I did not
have any idealistic thoughts about start ups or changing the world as you
wrote or have a "head in the clouds" stance. Actually, I think most start ups
are not doing much of anything but at least they are developing and not
maintaining as is the case with big companies. I am looking out for me and my
best interest; I think a year at a startup or small company is worth three or
more years at some name brand outlet. I was an employee for about six months
after college at a big company. I quit and have been contracting for the past
seven years and have started two companies of my own. Recently, I was contacted
by my first boss (who coincidentally said "You can work here forever")
and learned of his unemployment. He, of course, has strong maintanence skills but
has not done development as far as I know. Maybe it is your own situation that
causes you to respond the way you did, but I think for a fresh college grad the
worst thing you can do is be an employee with no potential. You have nothing to

Mr. Orange
Friday, April 5, 2002

1) re salary -- while some cs grads may indeed be waiting tables, strong, large companies looking to attract top people (and not just top of the class at MIT) are still decent salaries (i.e. 60-70K metro in the U.S.). maybe there just aren't that many companies left in this category :)

2) re potential at a company -- I'm not sure that it's simply a big vs small company issue. I've worked at a huge name brand company software for the past 6 years, worked on new code the entire time, and feel like my experience has positioned me to work on my own _much_ better than experience at a small company would have. Of course having software be our main business helps in this regard.

3) re the original topic at hand :) -- I have to strongly agree with Peter's comments about people skills. In my brief time as a team lead, and my less brief time as a peon, it's been my experience that solving people issues often makes technical issues disappear, e.g:

- hiring great people helps great decisions to be made
- recognizing and solving communications issues averts technical disasters
- proper motivation of team members increases productivity
  - many more!

None of these are technical issues, but all of them have a huge impact on the technology that you are creating. Be prepared to spend a lot of time analyzing people issues just as you'd analyze technical issues. If you relegate the people issues to the back burner you'll be sorry later.

Good luck!

Saturday, April 6, 2002

Don't just talk to people that you work with, but also talk to others in the same position that you are in.  I'm sure there's other budding CTOs who are asking the same questions that you are.  There's usually conferences and/or user group type meetings every month that you can go to and schmooze with other technical executives for pointers. 

Also, I would recommend that since now you're in a management position that you also pick up some books on the management side of things that are not technical.  I.e. get some finance books and figure out how to determine the ROI on a project, the future/present values of revenue streams, etc.  And get some marketing books so that you'll have a basis for understanding the jargon and needs of marketers.  Browse around at the managment section of your local bookstore for ideas.

As for websites, any significant business site is probably required reading regardless of whether or not it has a technical slant.  The reason being that you need to be able to keep up with current market trends, articles on how and what other businesses are doing, ways to manage your employees better, etc.  Here's a sparse list of sites to look at:

Good luck with your new position!

Saturday, April 6, 2002

Chris, I offer these suggestions for your new role:

1. Have confidence to follow your own feelings when outsiders try to present a formula for you to follow. You obviously have experience and background. There will be times when the standard practices at other places don't apply at yours.

2. If you are ambivalent about the different duties of departmental management as compared to software development, hire someone else to do the day to day management for you. This works fine.

3. To retain talented developers, just treat them as you would like to be treated.

Hugh Wells
Saturday, April 6, 2002

Thank you for all of the good advice and insight.  If you come across anything else or think of anything else, please post that here as well.  If anything specific arises you will probably hear more from me.

Thank you again.

Chris Mills
Monday, April 8, 2002

*  Recent Topics

*  Fog Creek Home