[font="arial"]I've recently been given the position of technical director at my studio. I've worked there for almost two years. When i started there were 7 employees. Now there are nearly 40, 8 of which are programmers, spread across 5 projects! I've been there the longest and have the most experience with the code base. I also feel that i am most personally connected to the existing code and seek to preserve its essence and ensure that it's extended in the right directions.[/font]
[font="arial"]
Like any promotion i'm having a bit of stage fright at the moment. Being in charge is a lot of pressure. I need to stay open minded, and listen to the needs and suggestions of my colleagues. But i also need to be firm and direct about my stance on the matters.

On my first day as TD we reinterviewed a programming candidate and i decided we needed a set of real questions, not just the "hey how ya doin? do you like programming? what did you do in school?" questions. I feel like I put together a very fair set of questions, covering a wide spectrum of topics. It was by far our longest interview and unfortunately the candidate did not pass the test. I feel like for the company this was a movement in the correct direction.

I really love designing and writing code and I dont want to see myself slip into a purely managerial role. I want to lead with experience and prove by example. I kind of have some possessive issues when it comes to programming though. I'd rather do everything myself and see that it get's done correctly than to allow someone else the chance of screwing it up.

But now i need to delegate more than ever. To lead game/engine programmers, IT, art leads, designers, test teams. I must really live up to the name director. And I most certainly need to get more organized; start documenting and planning more. I need to look at the very long range picture as well as the near range, weekly tasks.

I'm posting here because i'm seeking advice.

What kinds of things would make me a better technical director?
Will you please share your experiences, either as, or dealing with a technical director?
What would have made that experience a better one?

Thank you very much[/font]

I can't speak to being a "technical" director, but the hardest part of being a manager is accepting that your task is no longer your work, but the success of your team. You no longer have the right to "just get things done myself." It's the ultimate compliment of respect to your team to say, "I trust you to get this done correctly." If you delegate a task and it doesn't get done correctly, it's no longer your job to just get it done yourself, it's your job to build your team so that they can accomplish the task directly. Just to be clear I'm not saying you can't work on anything, just that your focus should not be on working, but on delegation and people building.

I just read a book on leadership in management and one survey on new managers found that if the new manager kept the "just get it done" mentality they ended up not moving up in their career and ended up hating their new jobs. Of those that embraced the task of delegation, they ended up advancing further and enjoying their jobs more.

I can't imagine this is any different for a technical vs non-technical job. I can promise that if you don't change the way you think about your new job you'll only grow to resent it. You can't handle your managers, the demands of your job, and all of the people reporting you, if you feel like you're the only one that can do things correctly. You'll end up burning out in short order. I'm speaking from personal experience mostly. I had the perfectionist mentality and it was detrimental to my team. Luckily my boss is a good teacher and helped me see the light. Since then, my job has been easier, my direct reports are happier, and I have given my team the ability to get promoted instead of pigeon-holing them into their initial roles.

[font="arial"]
2.What kinds of things would make me a better technical director?
3.What would have made that experience a better one?
[/font]

1. Congrats
2. Bring in Donuts.
3. Donuts.

I didn't answer your second question because most of my interactions are once removed from the technical director so he's more like a guy who sits in a corner somewhere and occasionally comes out to mess with our stuff in my interactions with him.

Great idea dpadam!

Wow these forums have really died down lately though.

Thanks for the other replies also!

Read useful stuff.

http://pragprog.com/book/rdbcd/behind-closed-doors seemed quite good for example.

I've found that so far the best tool we have is communication.

All of the programmers are talking more than ever, because there is a clear leadership position.
They bring a majority of their problems to me and then i can answer their questions, quash their concerns, pair them up, or redirect them to someone else who would be better at helping them.

I create inquiries for other people, refactor the information, and pass it on.
One of my main objectives is to stop new programmers from reinventing the wheel, in major, sometimes catastrophic ways. (dont change all the guid keys to new sequential ones just because they looked almost sequential) I can only do this by talking the programmers regularly. Poking around in changelists and throwing in my two cents on code they've written.

And since all the really heavy stuff ends up on my desk, i still get to have a lot of fun.
During a crunch, a game programmer may ask, hey can you look at this camera code? or can you help me with a crash? and more often than not i have a few cycles to burn for that purpose.

But other times i have to say no i can't help you right now, i'm implementing an entirely new renderer, or other major system.
All in all i'm pretty happy with the way things are going.

@BZRoom: congrats on your new position!

I'd like to ask you what is your education level to reach this position, and if there is any specialization you're missing right now for it (some extra-curricular course you wish you had taken for this, for instance).

Best of luck.

You need to learn to pass off that 'heavy' stuff as well. Junior programmers will never get better if all they do is the same cut and paste over and over.