Ask HN: Just made Director, now what?
Hi all, after a lifetime of software development I'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?
41 comments
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.
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.
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... (2) Manager Tools "Basics" podcasts, especially on 1x1s and feedback: 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.
(1) Andrew Grove's "High Output Management", it's easy to read: https://www.amazon.co.uk/High-Output-Management-Andrew-Grove... (2) Manager Tools "Basics" podcasts, especially on 1x1s and feedback: 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.
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.
As a very inexperienced manager (i.e. startup founder) I found some of the stuff quite helpful, which is doubtless obvious to the more experienced (although, in fairness, I also stopped reading about 3/4 of the way through, but my cofounder swears by it).
Got any books you'd recommend?
Director here. My current favorite is Managing Humans, Michael Lopp: 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
Michael Lopp is a.k.a. Rands http://randsinrepose.com/archives/category/management
Manager Tool podcasts are really incredibly good. Thanks for reminding me of them!
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... (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/
Radical Candor: https://www.amazon.com/Radical-Candor-Kim-Scott/dp/B01MY574E...
Extreme Ownership: https://www.amazon.com/Extreme-Ownership-U-S-Navy-SEALs/dp/B...
Becoming a Technical Leader: https://www.amazon.com/Becoming-Technical-Leader-Problem-Sol...
Peopleware: https://www.amazon.com/Peopleware-Productive-Projects-Teams-...
- 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.
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... (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/
Radical Candor: https://www.amazon.com/Radical-Candor-Kim-Scott/dp/B01MY574E...
Extreme Ownership: https://www.amazon.com/Extreme-Ownership-U-S-Navy-SEALs/dp/B...
Becoming a Technical Leader: https://www.amazon.com/Becoming-Technical-Leader-Problem-Sol...
Peopleware: https://www.amazon.com/Peopleware-Productive-Projects-Teams-...
- 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.
> 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!
Manager of a software development team here. Great advice. Thanks!
>"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."
That is a very salient point. Managing a team of multiple people of different backgrounds, experience levels, quirks, communication styles, pet peeves, etc. is an exercise in adaptation.
As a Director, there are certain things you need your team to adapt to in order to keep your team on track with your strategy and process. How you go about getting them to do that is all about you adapting to them to get them excited, help them overcome hurdles, break down communication barriers, and build your relationship so they know you have their backs and you know you can rely on them.
It sounds easy in principle, but it is incredibly difficult in reality, particularly for those who may be stronger on the technical side than the communication side.
And P.S., you won't always be successful, so start planning for when (not if) you will fail in that regard. That means making sure your team knows that you are always open to their candid feedback so you can do a better job of supporting them.
On a final note, I'm quite partial to this illustration that nicely sums up your role in relation to your team [1]. In another sense, some see an org chart with them at the top and their team beneath them. I see it as an inverse pyramid with the leader at the bottom supporting each and every one of their team members because your success is wholly dependent on their success at that level.
[1] http://www.modernservantleader.com/wp-content/uploads/2013/0...
That is a very salient point. Managing a team of multiple people of different backgrounds, experience levels, quirks, communication styles, pet peeves, etc. is an exercise in adaptation.
As a Director, there are certain things you need your team to adapt to in order to keep your team on track with your strategy and process. How you go about getting them to do that is all about you adapting to them to get them excited, help them overcome hurdles, break down communication barriers, and build your relationship so they know you have their backs and you know you can rely on them.
It sounds easy in principle, but it is incredibly difficult in reality, particularly for those who may be stronger on the technical side than the communication side.
And P.S., you won't always be successful, so start planning for when (not if) you will fail in that regard. That means making sure your team knows that you are always open to their candid feedback so you can do a better job of supporting them.
On a final note, I'm quite partial to this illustration that nicely sums up your role in relation to your team [1]. In another sense, some see an org chart with them at the top and their team beneath them. I see it as an inverse pyramid with the leader at the bottom supporting each and every one of their team members because your success is wholly dependent on their success at that level.
[1] http://www.modernservantleader.com/wp-content/uploads/2013/0...
[deleted]
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.
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.
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.
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.
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.
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...
[0]: https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...
Yup, this is a great recommendation. There is a chapter on managing managers.
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!
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.
Yeah, exactly. Set the example. If you take ownership, your team will take ownership.
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.
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.
- 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.
- 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.
> If the place is toxic, learn how to stockpile cash or human fodder.
Care to elaborate?
Care to elaborate?
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.
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.
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?
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?
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.
Usually good techs make better managers than typical politically-embroiled middle management.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Edit: surely it is the responsibility of whomever promoted you to provide the definition of what is expected from you.
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.
Start planning on the next jump. Can't stay a director forever.
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
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
The Effective Executive by Peter Drucker is another good book to consider.
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.
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.
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.
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.