

New CTO. How do I manage developers and report to CEO? - lgbr

Can anyone point me to guides, books, or provide any advice for managing developers? How about reporting to your CEO for timelines and progress?<p>I struggle with keeping timelines that I've set, and then have been late to achieve. I also struggle with communicating just how critical our timelines are to my developers.<p>I'm been through the Mythical Man-Month. Its relevance today is astounding, but I think I need a more general guide to management. Can anyone recommend any other texts?
======
hoodoof
Look for all these at Amazon:

Death March

PeopleWare

Debugging the development process

Rapid Development

Software Project Survival guide

If you are a CTO you should probably read them all.

The most important book for software development management is:

The Prince by Niccolò Machiavelli

The problems that you describe in your post however are solved partly by book
reading but mostly through years of experience and toughening up of your
character in the right ways.

~~~
blazzar
And one more to add to the list:

Leading a Software Development Team

------
vishaldpatel
How many developers are you managing, exactly? Are you a developer yourself?
Some random advice:

On timelines: -> An old guideline is to try breaking each deliverable into
individual, atomized tasks. Put an estimate on each task. Add it all up and
double the final amount. -> Use something like pivotal tracker, or redmine, or
Jira.

On getting reliable estimates from developers: -> Each dev is different in
their estimations. Get to know their quirks. Some feel that everything is easy
and tend to say "two days" for everything. Others will try to buy as much time
as possible and will tell you "a week" for something that will normally only
take them a day. Knowing their tendency will let you make adjustments.

On getting to know the devs: -> Start by getting to know the difference
between estimated and actual time on smaller issues.

Quick Daily Meeting: -> Spend 10 minutes at the start of each day to get a
status update - what is each member working on? Are they facing any problems?
Is anything taking more time than it should? -> Make adjustments to your
timelines accordingly if you have to.

Try not to micromanage. They should let you know when they face problems. That
said, radio silence is bad... thats what the daily should help alleviate.

~~~
iworkforthem
To add to @vishaldpatel's list.

Complexity of a task: -> If a task takes > 3 days to complete, time to review
the complexity of task. I.E. What's the other alternatives or approach to
complete the task? Are we doing it right? How are others doing it? etc...

Assumptions & risks: -> Not too much assumptions, if your assumption turn out
wrong, it instantly become a risk and that takes much effort to resolve. If
unsure, back to the drawing board, analyse, plan again.

Limit communication channels: -> I have this feeling that there exist some
form of communication gap. Limit the communications channels you have with the
team, keep all the project communications in a Prologue WP blog or a project
management tool like Basecamp. This is important to keep communication
transparent and clear.

------
SocratesV
Regarding timelines, just bear in mind that is better to be ROUGHLY right that
EXACTLY wrong.

As it has been said already, always give yourself a considerable buffer beyond
the time that was estimated and that you ought to try to breakdown development
into cycles, since you'll get better estimates down the line, given you also
have more information available to work with and base your new estimates on
the previous work and how it went (it's only indicative... but better than
nothing if you are cautious with it)

Accept that tasks won't take exactly the time you think they will. Break them
down as much as possible and, if your current methodology allows you, only
break down the tasks you'll be working on in the next few weeks (I know, you
have to break the others too to get an estimate for the whole project, but
honestly you'll be doing nothing more than guesstimates if you haven't started
coding the very first few, do it but know that the more further away from the
present you estimate, the worse the worse they'll be).

Another golden rule is never to let business estimate times for development
tasks. Developers should be estimating time for the tasks they will be doing.
They might be optimistic of pessimistic or roughly right, when you come to
know them, prefer the last two estimates (in worst case, it's better to
underpromise and to overdelivery and you can always help the over pessimistics
to tune their estimates). This might be difficult and business people may not
always (if any time) buy it and can impose hard deadlines... Just make them
aware that there is a risk that they might be entering in technical debt,
which as any debt will have to be paid sooner or later, whether that means
that a new feature will take longer because the code is a mess or because bugs
will pop up since there wasn't time to have proper automated and acceptance
testing.

Books I found useful, although I'm not a CTO myself (a bit methodology
dependant, sorry): The Art of Agile Development (O'Reilly) Agile Estimating
and Planning (Prentice Hall)

------
JoachimSchipper
A general "managing developers" resource is <http://www.randsinrepose.com> and
the associated book
([http://www.randsinrepose.com/archives/2007/06/24/managing_hu...](http://www.randsinrepose.com/archives/2007/06/24/managing_humans.html)).

(Disclaimer: I'm not exactly the target audience.)

------
peteretep
"I struggle with keeping timelines that I've set, and then have been late to
achieve. I also struggle with communicating just how critical our timelines
are to my developers."

That's ... wrong.

Your developers are unlikely to be missing deadlines because you haven't
explained to them how important you think the deadlines are. Developer
productivity is rarely linked to how important for the company a goal is
perceived to be.

Sure, you can squeeze out an extra day a week, once or twice, maybe, by making
a big song and dance about deadlines.

One of the things I like about Agile, or whatever you wanna call it, is the
explicit statement that if something's going to miss a deadline, you can
change three things:

You can change the amount of resource; you can descope functionality; you can
move the deadline.

And that's all.

~~~
petervandijck
And in practice, it's much harder than it seems to add resources.

Learn to remove/simplify requirements. That's the best tip I can give you.

------
robflynn
While I do not have anything to add in the sence that I have never been a CTO,
I would like to say that while you probably should have known some things
going into this, I appreciate/admire your honesty regarding your shortcomings.
I think that is an admirable trait that many lack.

Always be honest with yourself and others with respect to your
knowledge/understanding.

I assume you work for a small company/start up. Have you talked with your CEO
about what he expects from you regarding timelines and progress estimates?

~~~
kls
_I would like to say that while you probably should have known some things
going into this_

I have been a CTO at 3 companies and a VP at a few others. I am astonished at
the amount of companies now hiring CTO's that do not come from the technical
ranks or worse yet calling the wrong job the CTO. The CTO position is about
being the chief technologist, the CIO or the VP of technology is a more
appropriate title for the tasks that where outlined above. That being said,
given your candor I an assuming that you where elevated into this position,
forgive me if I am wrong on that, but as such it will be a learning process.

The first CTO position is the hardest and if you did not come from development
or a technical position, then you are going to be at a deficit given the fact
that you are in charge of the technical vision of the company. You have to
decide Open Source or Oracle, .Net or Java or Ruby do we start our own social
branch on our site or do we use Facebook, build or buy, etc. etc. These are
the responsibilities of a CTO and a good grounding in how the stuff is built
helps in formulating those decisions. My advice, if you are not technical,
would be to find a strong developer in your team whose opinion you can trust
and consult him on these type of decisions.

------
petervandijck
Next time, tell your boss it will be done in 3 months, tell your developers it
needs to be done in 6 weeks.

Why do you feel you need to communicate how critical timelines are to your
developers? In what way are they critical to _them_?

For general management: hire the best, then set a goal, then set them loose.

------
hoodoof
Are you saying you have been given the job of CTO without knowing this stuff?

~~~
geuis
Suppose you're the lead technical guy in a 2-3 person startup. You suddenly
get enough funding to start hiring a larger team. Since you are one of the
original folks, it's easy to see a situation where you take on such a role as
CTO. If you went from general engineer of everything to a lead role, you may
have never had team leading experience before. Don't conflate a title with the
actual job. You can be CEO of a lawncare company comprised of you and a
friend. CTO doesn't necessitate something like CTO of google.

------
teyc
Also read Tom de Marco.

Try to put your developers closer to your customers. It always helps to put a
face to the problems they are trying to solve.

------
callmeed
Start with the various reading lists at <http://www.joelonsoftware.com>

