I am not a manager. But I will list down a few traits of one of the best manager I have had:<p>- 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.<p>- Team succeeds: Attribute everything to people working for you. Publicly recognise folks who have gone above & beyond to achieve an impossible milestone/project.<p>- Team failed: Take the blame on you/process. Confront with engineers in private but at an organization level you bite the bullet<p>- 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 think the depends a lot on big company vs small company.<p>At a small company, here are a few bullet points I find helpful/effective:<p>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.<p>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.<p>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)<p>4. Think before you speak.<p>5. Share the Why not just the What.<p>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.<p>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)<p>These are by no means the only items. But certainly some items I’ve found useful.<p>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".<p>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.<p>From there it gets less "philosophical" and more "practical".
Managers are basically information routers:<p>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.<p>2. They work on a lower level, closer to the team, to discover any issues the team has before it's too late.<p>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.<p>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.
I’m not a manager, but what I like about mine is:<p>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.<p>2) He unblocks me, by connecting me with the right people, helping and escalating when necessary.<p>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)<p>* Make it so things roll the same if you're not here.<p>* Help them finding solutions but do not fix things for them.<p>* 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.<p>* Do your best to make them shine, let them know how much value they create.<p>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.<p>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.<p>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.<p>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 was once asked what my philosophy was by a more senior manager. Didn't give him a good answer.<p>The interaction lead me to think about what I was doing as a manager. Over time I've been working on developing and explaining my own style.<p>Today I try to balance across 3 things: people, business, and technology.<p>I wrote about it here if you're curious: <a href="https://www.mrbluebear.com/triforce-of-engineering-management-a-developing-philosophy/" rel="nofollow">https://www.mrbluebear.com/triforce-of-engineering-managemen...</a>
Laid back, do your job and don't lye to me and you'll have glowing reviews...<p>Don't ask people to do stuff you won't do personally...<p>You can work from home, office, the other side of the world as long as it is legal and you are available during business hours/on call...<p>If you have my back, I'll have yours in front of upper management..<p>We work to play/live and not live to work in my team...