The answer varies wildly based on the size of the company. At smaller companies, they tend to oversee hiring, technical work, and act as managers, but don't necessarily have budgetary authority. At larger companies, they tend to have more authority and involvement in larger strategic efforts; they tend to be "managers of managers."
Depends on the company. When I was director at a large social network, i didn’t have much authority around my budget or headcount. That was made by the VP. When i was a director at a startup which was the highest technology position, I had full authority over everything. I also drove the roadmap and attended board meetings.
The real way to determine your role and authority is measuring from top down. How many steps are you away from the CEO. Titles don’t mean much.
Absolutely this. There's a huge difference between a real Director of Engineering at a FANG-size company versus a "Director of Engineering" who is just some kid who decided to call their side-project a startup and give themself a hugely inflated title.
There are also FAANG-sized corporations that give director titles to individual contributors because it's the only way to get them into a salary band where they can be paid a competitive rate.
It's not as simple as company size, it's responsibility and authority.
Necessarily the nature of the job changes a bit if you are a the head of an organizational unit of 600, or 60, or 6. But it changes fundamentally if you have ultimate budget authority, hiring/firing, etc.
Agree there are a lot of somewhat ridiculous titles in early stage startups (ever seen a 5 person company with 3 "C" levels?) but even when you are small (but growing) there is a role distinction between exec and non-exec roles, and there is a difference worth drawing between director-in-name and director-in-fact positions.
If you are truly acting as a director of engineering, I'd expect you have broad authority to act; you don't ultimately decide your budget or technical goals (but you should be involved in determining both) but within those constraints you have most of the decision making responsibility for how & who.
The case in between is the developer who's been with the company the longest (>2 years) and so just gets bubbled up the chain into the CTO role while the dev team consists entirely of graduates/juniors
Totally agree. My experience has been interesting because I've grown with the company in this position so I've seen both sides of it. I'm now getting to the point where I'm elevating myself out of the day-to-day "now" and focusing on future strategy and whats "next"
