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.
(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.
Michael Lopp is a.k.a. Rands http://randsinrepose.com/archives/category/management
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.
Manager of a software development team here. Great advice. Thanks!
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...
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.
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.
[0]: https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...
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.
- 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.
Care to elaborate?
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.
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?
Usually good techs make better managers than typical politically-embroiled middle management.
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.
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.
Edit: surely it is the responsibility of whomever promoted you to provide the definition of what is expected from you.
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
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.
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.