I am not a manager. But I will list down a few traits of one of the best manager I have had:
- Shield the team from all the churn that happens from manager upwards. There can be so much shift in priorities, uncertainty in the upper management that it's mind boggling. "Shielding" team means - Providing a sense of stability, making sure the engineers are working on problems that are important for company now & will be important 6 months from now.
- Team succeeds: Attribute everything to people working for you. Publicly recognise folks who have gone above & beyond to achieve an impossible milestone/project.
- Team failed: Take the blame on you/process. Confront with engineers in private but at an organization level you bite the bullet
- Know everyone's interest & goals, like really know. On a longer horizon, try hard to align projects that matches individual's passion & challenges her skill level.
I tried to practice the above, to an extent where possible. Sometimes upper management or other teams have a way of interrupting engineers with stuff that isn't a priority. It happens. Most engineers "aren't bothered" but it does impede on current workloads.
Another thing I practiced was only taking on low priority, or menial engineering tasks. I have seen some managers want to be directly involved with higher priority and larger efforts when really that isn't their role. Its good to keep hands on work, but don't take that away from your team.
I think the depends a lot on big company vs small company.
At a small company, here are a few bullet points I find helpful/effective:
1. Lead by example: others will follow you if they believe in you. Manager has be willing to do and seen to do any and all tasks that they delegate. This does not mean that the manager has to be the best one at it or do it the most. But they should do some of those tasks that no one really wants to do.
2. Be sure to acknowledge success of others. Do this both directly and indirectly. One great way is to tell person B how good a job person A did when in a place/situation that person A can hear. This could be in passing or explicitly complimenting them in a group. Don’t do this for every single task but do do it for both large and small tasks. People want to know that their work has been acknowledged and valued.
3. Ask questions of your team. Don’t be afraid to get opinions. Don’t be afraid to not know the answer. Do be clear if you change you mind/approach if you learn new facts. If someone helps you find the answer/path acknowledge (see #2)
4. Think before you speak.
5. Share the Why not just the What.
6. Be excited about your goals. Explain where to want to go and why. You are your teams link to upper management and customers. A good team member may be able to find the path better than you if they understand the destination.
7. Don’t overwork your team. This will enable you to call on them for they extra job/extra hours the few times it is really needed. (See #1)
These are by no means the only items. But certainly some items I’ve found useful.
Note, they do not apply only to programming. They do not apply only to engineering. I think they apply to all disciplines.
There's a lot to it, you can't really sum it up as a brief philosophy. It's like asking people "what's your philosophy for programming".
That said, here's some philosophy. As a manager you are responsible for two things - you are responsible for making sure your team gets things done, and you are responsible for making sure each of your team members is happy in their job. The precise ways of making sure your team gets things done, well that depends on what you're getting done. And the precise ways of making sure each of your team members is happy, well that depends on why they are or are not happy.
From there it gets less "philosophical" and more "practical".
1. They make sure info goes from one place to another with minimum delay. If the team needs tool X, they get them tool X as fast as possible.
2. They work on a lower level, closer to the team, to discover any issues the team has before it's too late.
3. They understand their team better than any seniors, and can give a good estimate of how much resources are needed and how much the team can output.
Managers also work out of the team. They work on it like it's a machine. If one part breaks, they don't simply fix the part, but tweak the process so it doesn't happen again.
1) He’s expecting from me directions on what to do. Take this statement with a grain of salt, of course the entire team still works together and with coherence, but what I want to say is that he’s empowering me to make real decisions.
2) He unblocks me, by connecting me with the right people, helping and escalating when necessary.
3) He’s a member of the team, we have lunch together, dm on slack, grab a beer... on a personal level it doesn’t feel he’s on a “higher” level.
Some additional ideas (though @amirathi has summarized it in an amazing manner)
* Make it so things roll the same if you're not here.
* Help them finding solutions but do not fix things for them.
* Get their respect not through fear and or forcing them, but by doing the boring things and showing them that you care about what they do.
* Do your best to make them shine, let them know how much value they create.
Once thing I experience at my current job and that I love is that I am both the 'manager' of the team and a developer inside the team.
I love this, even though it needs that you know exactly (and make known) when you wear which cap, is that you can achieve the above points easier.
I love being able to show them that I can design, code and work. That makes it easier for them to respect me.
Top-down direction (feedback) can only be effective when grounded in reality, and to do this you must be approachable to your direct reports, hence fairly hands-off during day to day operations so that your presence in a meeting impacts it minimally - only then can you gather accurate information to give effective direction and feedback.
Team directives are "here are our goals, what's the best way to make them happen?, alas at the individual level, "management style" doesn't fly. Your team will be full of people each of whom take feedback differently and must be approached differently if you want to be as effective as possible.
Your goals as a manager are almost always best met by enabling your team via reducing their stress levels and providing them with the tools they need.
Do this, and they will meet whatever (usually pointless) goals or KPI's the brass uses to evaluate your performance.
I'm only new to management, but I try to be fairly hands off unless someone needs something from me. My reasoning for this is, I'm the one who hired this person and if I did my job correctly in hiring the best person, they shouldn't need to be micromanaged.
I too am hands off with respect to managing. I am of the opinion that if you need to actively manage your directs, then you have not hired well. I am a point of escalation when there are incidents or when mediation is required; otherwise I trust individuals to make decisions and be accountable for them. They will mistakes and you should not protect them from it; they need those experiences to grow. For decisions that are irreversible (or really hard to undo), I encourage them to solicit input from me and peers outside the immediate team.
For individual career growth, I try to align interest with opportunities that arise. I give timely feedback, I recognize their successes with new challenges and increases in compensation.
As it concerns project planning, I help with ballpark estimates so as to inform resourcing decisions. I negotiate the scope of projects with product/business leaders.
- Shield the team from all the churn that happens from manager upwards. There can be so much shift in priorities, uncertainty in the upper management that it's mind boggling. "Shielding" team means - Providing a sense of stability, making sure the engineers are working on problems that are important for company now & will be important 6 months from now.
- Team succeeds: Attribute everything to people working for you. Publicly recognise folks who have gone above & beyond to achieve an impossible milestone/project.
- Team failed: Take the blame on you/process. Confront with engineers in private but at an organization level you bite the bullet
- Know everyone's interest & goals, like really know. On a longer horizon, try hard to align projects that matches individual's passion & challenges her skill level.