
Ask HN: Just made Director, now what? - yegborscht
Hi all, after a lifetime of software development I&#x27;ve been promoted to Director of a 30-man software development team. What do I need to learn and where do I learn it? Anyone make the jump from tech to management successfully?
======
EliRivers
Director.

All I ever wanted from the directors; strong leadership. Decisions made.
Directions set (the clue is in the job title). Listen to what we have to say,
ensure that everyone knows that their points have been taken on board, and
then for God's sake make strong decisions, tell everyone why that's the
decision made, and enforce the notion that it is never inherently wrong to
pursue the direction you set. I want to know that you're going to support
actions that pursue your direction, so support them publicly.

I have never had any problem getting 100% behind a direction I disagree with
when it's been made and communicated well.

Direct.

------
gtf21
Would recommend very highly:

(1) Andrew Grove's "High Output Management", it's easy to read:
[https://www.amazon.co.uk/High-Output-Management-Andrew-
Grove...](https://www.amazon.co.uk/High-Output-Management-Andrew-
Grove/dp/0679762884) (2) Manager Tools "Basics" podcasts, especially on 1x1s
and feedback: [https://www.manager-tools.com/manager-tools-
basics](https://www.manager-tools.com/manager-tools-basics)

There's a hell of a lot to learn outside of these things, but I think they're
a good start.

~~~
tbrock
I was recommended "High output management" and found it pretty bad. Some of
the insight at the end was ok, but most of it was very boring and obvious.

~~~
howscrewedami
Got any books you'd recommend?

~~~
stumblers
Director here. My current favorite is Managing Humans, Michael Lopp:
[http://www.springer.com/us/book/9781484221570](http://www.springer.com/us/book/9781484221570)
Excellent reminder on everything I'm doing right and wrong.

Michael Lopp is a.k.a. Rands
[http://randsinrepose.com/archives/category/management](http://randsinrepose.com/archives/category/management)

------
Stwerner
I made the transition from engineer to managing a team of around 12 at
Groupon. So I made the transition with a smaller team than you are - forgive
me if some of this isn't as useful for your situation.

What worked for me:

\- One on Ones. Nothing I've done has had as much of an impact as weekly one-
on-one meetings with everybody on my team. I tend to follow the format
outlined on Rands In Repose: [http://randsinrepose.com/archives/the-update-
the-vent-and-th...](http://randsinrepose.com/archives/the-update-the-vent-and-
the-disaster/) (This is an incredible blog for engineering management. I would
highly recommend reading everything he has written.)

\- Read everything you can find on the topic and about leadership in general
and start figuring out how you can incorporate the lessons from those books
into your situation and context. This is a brand new skill set that you need
to approach with the same effort that you had been approaching engineering.

Some suggestions:

Rands in Repose:
[http://randsinrepose.com/archives/category/management/](http://randsinrepose.com/archives/category/management/)

Radical Candor: [https://www.amazon.com/Radical-Candor-Kim-
Scott/dp/B01MY574E...](https://www.amazon.com/Radical-Candor-Kim-
Scott/dp/B01MY574EE)

Extreme Ownership: [https://www.amazon.com/Extreme-Ownership-U-S-Navy-
SEALs/dp/B...](https://www.amazon.com/Extreme-Ownership-U-S-Navy-
SEALs/dp/B015TM0RM4)

Becoming a Technical Leader: [https://www.amazon.com/Becoming-Technical-
Leader-Problem-Sol...](https://www.amazon.com/Becoming-Technical-Leader-
Problem-Solving-Approach/dp/0932633021)

Peopleware: [https://www.amazon.com/Peopleware-Productive-Projects-
Teams-...](https://www.amazon.com/Peopleware-Productive-Projects-
Teams-3rd/dp/0321934113)

\- Finally, one piece of advice I got when I first transitioned into
management was that "first-time managers usually fall into the trap of
becoming the manager they wish they had. What you really need to do is figure
out how to be the manager that each person on your team wishes they had, and
become that manager." Easier said than done, obviously, but I've always found
it useful to return to it whenever I am struggling.

~~~
mavelikara
> What you really need to do is figure out how to be the manager that each
> person on your team wishes they had, and become that manager.

Manager of a software development team here. Great advice. Thanks!

------
killjoywashere
I like Lazlo Bock's book, Work Rules!

If you think HR isn't central to management, I offer to you that the top
junior officers in the US Navy are sent back to the Academy as Company
Officers to

* run herd on ~120 talented young midshipmen, basically a high stakes RA.

* meet each other

* earn a master's in HR, focusing on leadership, administered by the Naval Postgraduate School. Spitball annual cost: $10M for 15 a year (2 year program and they're drawing salary and benefits, which could have been invested in having them driving ships or flying airplanes).

Focus on your people, their development, their well-being. Let them handle the
technical challenges.

Communicate your people challenges to company HR aggressively. Make sure they
are giving your folks money for training. If you have a weak player, talk to
HR early. If they think you can handle it, they'll tell you. If they have
tools for you, they'll bring those to bear.

Collect data, ask HR what data they collect company-wide. Talk to the other
directors. Those are your colleagues now. Use them. Be frank with them.

------
dvfjsdhgfv
Everybody will give their own advice, but from my experience there are two
aspect of it: (1) management in general, (2) issues related specifically to
managing a team developing software. As for (1), I personally recommend the
Theory of Constraints. To simplify: you identify weak points and fix them.
There are several more modern management theories, but this one is
particularly efficient and simple enough to apply as a part of your daily
routine. As for (2), I'd recommend being open minded, but at the same time
following common sense, especially if everybody is convincing you that you
should follow some modern trend.

------
bboreham
Focus on doing the things that you alone can do.

There's a bug in the code: you can fix it. But can anyone else fix it? If so,
let them. Even if you can do it better. Let them learn, let them grow.

What can you alone, as the Director, do? Direct. Lead. Set a direction, make
sure people are following. Figure out your goals and values, and state them,
often. Visibly live them.

Make sure people are following your lead, by knowing what they are thinking
and what they are doing. Create ways to find that out, because people won't
tell you straight out they think your leadership is shit.

------
helper
Maybe read "The Manager's Path" by Camille Fournier[0]. It focuses a lot on
the transition from being an engineer to going into management.

[0]: [https://www.amazon.com/Managers-Path-Leaders-Navigating-
Grow...](https://www.amazon.com/Managers-Path-Leaders-Navigating-
Growth/dp/1491973897)

~~~
romanhn
Yup, this is a great recommendation. There is a chapter on managing managers.

------
simonhamp
I'd highly recommend reading Radical Candor by Kim Scott. Incredible book.
Really focuses on practical ways to be a great manager. I'm not in management
at the moment, but I plan to re-read carefully and apply almost all of it when
I am!

------
rpmcmurphy
Hopefully this will not apply to you, but be prepared to take one for the team
if malignant stupidity or malice come down from on high. All too often it is
easier for managers to "let shit roll downhill" rather than put up meaningful
resistance. Like I said, hopefully this doesn't apply to your company, but
since you posted here, you probably work in tech, so there is a non-zero
chance it will. Best of luck and congrats on the promotion.

~~~
TYPE_FASTER
Yeah, exactly. Set the example. If you take ownership, your team will take
ownership.

------
manyxcxi
I went from architect to director, partly because I recognized I was already
doing a lot of what a director should have been (we didn't have a Director of
Technology at the marketing agency I worked for).

Here's what I intuitively understood that made it easier for me to get the job
and be broadly successful:

\- You're the public face of your group, you're essentially responsible for
championing your team to those in the organization as a whole.

\- You need to be listening to those other groups and thinking about what your
group can do to help

\- Aggregate all those things you hear at a more global level and think about
how you can gather interested parties (from all areas) to solve them

Specific example, we weren't closing as many software development projects
because our sales teams didn't know what we could do.

First, I worked with some of the sales guys to create some training to help
them pick up on the signs that "this might be a dev project" and "this could
be worth a lot of money".

Second, I got in on a lot of RFPs and proposals to see what was being asked of
us. I refactored the initial training to target the patterns we were seeing.

Third, and this may not be applicable, I actually became a part of proposals
and pitches. Nobody was bringing the tech folks in.

Here's what I didn't think about/had to work on:

\- HR and management strategy at a much higher level. Knowing impending cuts
are coming, the knots that come with having to be part of firing or laying off
people.

\- Instead of keeping a smaller number of people that you work with closely
happy and interested, you're trying to keep them AND their employees
interested

\- Managing managers is totally different than non-managers

\- Budgeting strategy. Fighting to get training dollars, head count, new
hardware (that wasn't really an issue), etc. It's kind of a zero sum game and
politics will absolutely come in to play here. Maybe more so than anywhere
else.

\- So many meetings.

\- It's a lot harder to feel like you've accomplished anything at the end of
the day. You need to start measuring by weeks and months.

\- So many meetings, again.

\- You need to get people interested in your ideas for change. You really have
to sell them in a new way to every person you talk to.

\- You better have ideas for change.

------
Spooky23
\- Don't put up with jerks.

\- it's not all about you. Make sure that you piblically represent your team,
not yourself.

\- politics isn't above you. Learn how to be effective with your peers. At the
director levels even your friends can become your competition.

\- appreciate that your decisions impact people around you and the company.

\- study budgeting. Know where the money goes.

\- when tough times come, know where you will cut. If the place is toxic,
learn how to stockpile cash or human fodder.

~~~
jackgolding
> If the place is toxic, learn how to stockpile cash or human fodder.

Care to elaborate?

------
umbs
For past 2 years, I have interacted with Directors a bit more and following
stood out among the Directors I like.

1) Clarity in vision and ability to articulate it to the team is very
important. 2) Engineers will zone out if you sprinkle sales (and/or
management) mumbo, jumbo. Engineers (anyone for that matter) appreciate clear
communication and reasoning behind management decisions. Many times,
management decisions aren't clear cut. That's OK. But calling it out as is is
being honest and engineers appreciate that.

Most recently, I had an interesting experience speaking with a Director during
a job interview.

I asked for reasons behind building a product by their team. I explained why
it's not a good idea. The Director kept throwing sales and marketing terms and
was clearly out of his depth. What should have been a 30 min interview was cut
short in 10 min and I was walked out. I did not get the job. I'm glad I
didn't.

But key take away for me was, as a Director, they will be bridge to many
departments (Engineers, Sales, Marketing, Customers). They should have good
understanding of the product, how to pitch to everyone.

I hope this will be useful.

~~~
shostack
Without knowing the context, I'd like to cautiously play devil's advocate
here...

Often times sales and marketing are driving factors behind building products
because that's what makes the money come in that funds their development. Was
it truly meaningless jargon? Or is there a possibility that they were using
business language that has actual meaning and was totally applicable in this
case?

------
rurban
Good directors communicate (e.g. they don't manipulate and lie), make good
decisions (early enough), are straightforward (and not overly polite), don't
avoid conflict and cannot be easily manipulated.

Usually good techs make better managers than typical politically-embroiled
middle management.

------
sjg007
A lot depends on your company and how it works. Some directors drive programs
so abstractly, you are an interface to the rest of the company. You coordinate
with other directors. Protect your engineers and managers. You have to shield
them from the upstream shit. I presume you have 5 managers or so under you.
You should have a boss above you as well. Your boss delegates to you and you
delegate to your reports. You have a reputation and probably skill with
working with others. You have to ensure that your teams are building the right
thing in the right way (abstractly of course).. you don't need to micromanage.
The best managers and directors bring people together and lead a common cause
but let their people figure out how to achieve it.

------
gji84
Just repeat the process of what you just did here at HN. I mean, your Open-
mindedness to learn from industry and team, willingness to listen to your
team, contemplating on the opinions and choosing the best to make it win-win
for stakeholders. To do the above to the best, you need "Clarity in thoughts,
purity in heart and sincerity in action" (Quote by Sri Sri Ravishankar,
Founder of "The Art of Living"). While I was in a similar position as yours, I
did the same. Where I learnt to be in that state is, in this program called
"Happiness program" by "The Art of Living". All the very best in your new
role.

------
tpae
Don't burn out too quickly.

Being a director means you have more responsibilities, but if you are too
focused on trying to make everyone happy, you could set yourself up for a burn
out.

Identify key individuals to help you (usually lead engineers), and give them
your trust to do their job.

Focus on larger initiatives, give both positive and negative feedback,
encourage healthy competition, and always be forgiving. Always be
approachable, but never let them take your presence for granted.

Ultimately, you will find a larger reward when you take time developing
individual relationships. They will appreciate your attention, and in turn,
you will have direct influence over them.

------
juancn
Besides all the managerial stuff, you're at a point where you need to exhibit
what I call "higher order leadership". At this point you should be able to
help others become leaders themselves and find people in your team that can
eventually replace you. Also your team is your responsibility, hiring and
managing growth is likely the most important thing you have to deal with.

------
random101
Make sure you when you make important decisions you surround yourself with the
smartest people. You cannot know everything, but knowing how to proceed with
your most trusted and smartest people will be the core of your success.
Provided you can make the right decisions, and learn from the wrong ones.

------
muzani
I'm going to assume director means upper leadership of a project?

The transition is not so hard. Think of it as another programming language,
another architecture.

Your team is like a machine. You are not in it. You don't work in it. You
build it. You improve and iterate on it. Your job is to look at it from the
outside and see what can be improved.

You also have to make sure that information flows from top to bottom well. The
lowest intern needs to understand that strategic goals and focus of the team.
That's really what motivating is.

As tech management, one of the most effective thing you can do is to train the
ones below you.

You should take complete responsibility for what happens in your team. One of
your junior programmers breaks the product? Sexual harassment? A core member
ragequitting? Your fault.

Ben Horowitz's The Hard Things About Hard Things is what I'd recommend most on
engineering leadership. Extreme Ownership by Wilink, Jocko is a good book on
general leadership. Do avoid a lot of the things on Business Insider, Forbes,
or other business blogs.

------
tehlike
Make decisions. If someone cant make a decision, do it for them. There is
nothing worse than not making a decision - it prevents progress, it lowers
morale, makes everyone involved frustrated. If lower management gets into cya
mode, make sure you fix that.

------
wdfx
Red flag: how could you possibly be promoted into a position you know nothing
about? How did the rest of the management allow this?

Edit: surely it is the responsibility of whomever promoted you to provide the
definition of what is expected from you.

~~~
devwastaken
Management hiring management rarely tell you what you should be doing from the
view of non-management workers. Also, you're assuming that the management that
hired this director knows everything, but I don't think they do, so I don't
see why it would be a problem to ask more about it in a public space where
other directors and those who work with directors are located.

------
wolco
Start planning on the next jump. Can't stay a director forever.

------
zhte415
1\. manager-tools.com

2\. have a support network or establish one through a coaching or mentoring
program. if you've not done such before, seek to hook onto an existing one and
go from there

------
tmaly
The Effective Executive by Peter Drucker is another good book to consider.

------
tapanjk
This is not exactly the answer to your question, but others have posted many
resources in this thread. While you spend time to learn from those resources,
I have a few words about what could be done in the first few weeks, and this
is based on my own experience (i.e. I wish someone told me this).

I would not change anything in a hurry just to prove that "I've got this one."
You are promoted to Director (you do not mention this but I assume) because
your management sees you do at least some of this job already, and they also
see that you have demonstrated potential for growing in this role. (The other
possibility is that someone got fired and you are asked to step into that
role, in which case, that is a different game altogether.) So, here are the
Dos and Don'ts.

Do:

1\. Own the tech roadmap. You will not know why some of the items are on the
roadmap and now is the time to find out and be able to explain why, and at
this stage you need not be convinced that each item on the roadmap should be
there.

2\. Build relationships with your business stakeholders in order to understand
what is their definition of success, and what is your and your team's role
there.

3\. Take a look at your team again. This time you will see a different
perspective. You want to quickly reach an understanding about your team's
strengths and weaknesses.

4\. Reevaluate your communication style. What worked so far, may not be
suitable or sufficient in your new role.

5\. Meet with as many of your team members 1x1 and ask them what they think is
working well, and what they think needs to change/improve. Just listen and
take notes, without agreeing or disagreeing to what they are saying.

6\. Be prepared to receive feedback. From anywhere -- your team, stakeholders,
management, customers, etc.

Don't:

1\. Try to prove yourself a good leader. This is something that takes time,
and there are rarely any actions that can be taken directly only to accomplish
this goal. Also, if you think too much about "am I a good leader," you will
stress out very quickly.

2\. Make changes in the roadmap too soon. At this stage, you are more likely
to not have enough information and context about why the roadmap is what it
is. If you make changes too soon, be prepared to change it again after you
have gained context in the next few months.

3\. Make changes in the team structure too soon. In your new role, you are
likely to change your opinion about some of your team members' effectiveness
and impact on business.

Over a period of time, you will intuitively know what needs to change, and
that is the right time to start making any changes in the way the team
operates, the team's priorities, the team structure, etc.

------
ifoundthetao
Yeah, it's not too bad. Odds are, you were probably doing it already anyway.

My recommendation, learn how to translate "unquantifiable" ideas to
quantifiable ones. You can do this through a simple tool called an "OKR",
which stands for "Objectives, and Key Results".

OKRs are generally built for quarterly runs. No need to stick to that. But
come up with four objectives, split them each into six or so actionable items.
So those actionable items can be split up into tasks, sprints, etc..

At that point, you will have quite a bit of work set up, and it will be easily
measured. Take the percentage completed of each of the tasks, which make up
the percent completed of the Key Result, and then the percentage of the Key
Results completed make up how far along in your objective you are.

The objectives should spread across several different domains that you're
directing, and your priorities should take care of what goes in there.

Take a good amount of measurements on those, do Gap Analysis' often, to find
out why you overshot, undershot, etc., and keep track of that information. Do
Root Cause Analysis' often as well, so you can find out what is really going
on.

The crux of it all really depends on what you're willing to do with your team,
and how accountable you're all willing to be held. Without their backing on
your objectives, it'll be a bit more difficult. So if they understand what it
is that you're trying to accomplish, and they see your leadership (i.e. owning
up to all mistakes, and sharing all accomplishments), they will back you. But
the keys to that are understanding the goals of the objectives (not just the
objectives, but the reason that they're up there).

If you can do those things, you'll find it very easy to manage.

Other more specific things might be setting up controls so that you can easily
audit the SDLC: get "sensors" and "measures" in place. Sensors would be
something like a CI server, automated testing, security unit tests, post
deployment tests, code sniffing, static code analysis, dynamic code analysis,
regular fuzz testing, ensuring that your environment is locked down with file
integrity checking, track third party tools that are in use for any known
vulnerabilities, get software bill of materials (while you're at it), get a
known authorized hardware list, get a known authorized software list, have a
monitoring system for when these are violated, and get the response time down
to 1 - 24 hours.

The measures will be something like: * adding a benevolent unauthorized
machine to the network. * adding benevolent unauthorized software to an
unauthorized machine in the network * adding benevolent unauthorized software
to an authorized machine in the network * make a change to a file that does
not decrease the security of the environment (ex: change from 10 char password
complexity to 14 char password complexity), and see if the file integrity
check finds it.

Basically for every sensor, you want to have a measure that checks it,
otherwise you won't know if you have it set up properly, or if it is broken.

