New CTO. How do I manage developers and report to CEO?
10 comments
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.
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.
Are you saying you have been given the job of CTO without knowing this stuff?
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.
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.
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.
And one more to add to the list:
Leading a Software Development Team
Leading a Software Development Team
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?
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?
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.
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.
Start with the various reading lists at http://www.joelonsoftware.com
A general "managing developers" resource is http://www.randsinrepose.com and the associated book (http://www.randsinrepose.com/archives/2007/06/24/managing_hu...).
(Disclaimer: I'm not exactly the target audience.)
(Disclaimer: I'm not exactly the target audience.)
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.
Try to put your developers closer to your customers. It always helps to put a face to the problems they are trying to solve.
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.
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.
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.
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.
"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.
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.
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.
Learn to remove/simplify requirements. That's the best tip I can give you.
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)
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)
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.
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?