I’ll be frank. I’ve worked for some real dumb assholes (in the past) as have many I’m sure.
And several of these managers or leads fallen into one of these categories:
a) Dumb but very nice (should never be in a management or lead position). Got there from kissing ass or got lucky.
b) Dumb, overly nice 99% of the time, but blows up suddenly when things do not go well turning into dumb assholes
c) Dumb & Complete Assholes all the time
d) Smart and Complete Assholes all the time
However, there are some very very rare managers or leads in IT these days that qualify as a decent or even great managers in IT. I have worked with good managers in addition to bad but they are very rare in my experience.
Disclaimer: First before I dive into the list below, let me state that I am not saying that the lead must empower or to motivate leeching. If you think that this post somehow promotes leeching, then stop and take a breather and then read on. Get off your high horse. That’s definitely not what this is about.
Characteristics / attitudes / process of good management & leadership:
1) Have a passion about technology but care more about ensuring that their underlying team succeeds
This does NOT mean whipping your team and being an ass to your underlying team members to hit those deadlines. If that’s your style, I feel sorry for you and your team. That de-motivates a team faster than anything. Sure, you can emphasize that hey, we need to get this out the door, but sending flame emails or emails of failure or telling your team that “they failed last time” or scolding a person in your office is not cool. There’s a lot of truth when you say failure has partly to do with the manager in many cases.
I once had a lousy team lead who sent us all an email after we were doing some very bleeding edge code (MVC Preview 2/3 to be specific) saying to the entire team that “we all better not have missed deadlines like this again”. This was after we all busted our asses night and day including weekends getting a portal project company-wide out the door. This is in addition to this lead and attempt to be a manager sending emails several Fridays unexpectedly at 5pm stating that they MUST work the entire weekend when the team was already gone & left for the day! Just not cool and shows the inability to communicate and manage a team effectively. And this was coming from a Lead who refused to do points 2, & 3 & 4 & 5 & 6 & 8 below. A total Fail as an attempt to be some kind of Lead/Manager. You know who I am talking about if you end up reading this post.
You want a motivated happy team as much as possible, even when those timelines are not being met….especially when they have busted their ass. Everyone has different level of expertise, and you have to take this into account when each and everyone looks to be working hard.
2) Motivates his/her team on a regular basis
That means you give POSITIVE feedback more than negative and doing this in a consistent manor. Often times a manager will give positive feedback only once or twice to their new subordinates and then that manager never really dishes out any positive feedback thereafter. What’s the point? Why give any if you are not going to try to motivate your team members individually in a consistent manor?
Also, be sure to do this individually. Sure, you can tell your entire team they are great. But what does that mean to me as a developer individually? Let each of them know on a regular basis where it makes sense.
3) Passion to teach or help younger members learn
This is a trait of a great leader. This means yes, getting off your ass and having a couple of short developer meetings every so often to maybe go over some technical concepts that your younger members may be struggling with. You cannot expect all your subordinates to always “just figure it out” and say “that’s why we pay you” type of attitude. Sure, some of that is true but do not present that kind of attitude or your team will definitely struggle because of this naive and lame approach to management. There are many developers who work their ass off and just have struggles at times just like you and that’s how team can help each other in those hit your head against the wall” situations.
4) Ability for the lead to handle their big titles & responsibilities without constantly using a lame response such as “I’m too busy for your problems because I’m a manager and I am very busy myself” which presents a very negative type of attitude back to your developer.
Obviously your developers probably sense that you are super busy all the time and I would have think many developers try their best NOT to bug you. But that’s not a free ticket to give a lame response such as this. It can be worded differently is what I’m saying here. If you are busy, tell them, but make an effort to address their problems when you have time and tell them this. Revisit it, don’t just wave that kind of lame response every single time.
5) Openness to share their expertise & insight to team members
Hey, if you’ve figured something out, send your team an email if you think they may benefit from it. Do not think that it may never be of use to them. Oftentimes, if it obviously was something significant you figured out for yourself, it’s going to trickle down to developers that come across that same concept or issue. I have had team members share stuff and usually half the team was glad, half did not care. But ultimately some people benefit from your advice, knowledge, or findings. Put it on a wiki/team forum or something or mention it in the team meeting. Sharing empowers a team and ultimately can save time as well.
6) Ability to Humble oneself
Don’t try to always act like you do no wrong, and you can figure out almost anything. Don’t give off a cocky vibe.
7) Checks often to see how team members are doing not because that manager wants to push his team, but sincerely wants to see if there are any issues or struggles
Hold a daily SCRUM meetings. And for those of you who think that’s a joke, it is a hell of a lot more efficient than NOT meeting at all (no communication), or meeting for hours at a time (inefficient & too much communication)
8) Ability to communicate the requirements & expectations effectively to team members
a) expected time to deliver or if you ask them how long, compromise and agree on some sort of tentative date.
Tell them YOUR realistic expectations as a manager on how long you think it would take them given THEIR expertise, not YOURS (give some dates or # of days). Ask them for their estimate but also tell them what you would expect and compromise. However do not don’t dictate every estimate to them,meaning don’t short your developer every single time due to pressure. Be a bit more realistic, don’t be a slave driver is what I’m saying here.
b) how you as the architect lead or manager expects it to be implemented
(let them know of any existing patterns, concepts, or example code where it has been implemented in the past that may help to ensure this happens)
What I cannot stand is an architect lead who tells a developer a one line sentence describing the task and then expects that developer to dig in and finish it. And then expects that developer not to ask questions. Then when the developer comes up with the solution, the lead hacks it all apart and literally wastes the developer’s time because of this. This is not a code-review session obviously, this is a bashing. I’m talking about situations when that lead is just being a smart ass about it or giving you just a bad vibe when looking at your solution, or doing this just to show his shit does not stink and yours does. Often there are times you have assholes who are in positions of power, who cannot communicate the task for the life of them initially, and then when the developer completes it, the lead turns on his ego trip and tears it apart saying “this is not exactly how I would have implemented that” with some kind of attitude. This is NOT a good team lead.
If you’re going to go over code, be fair and have a constructive code review with your developer(s). Ensure that your developer knows why you would change his code, and that the developer is learning from the review. Oh, and I love this one. When an architect lead changes team member code because their code did not suit their expectations but does not tell them. I’ve had this happen as well as a couple of team members at a past job and it really pisses you off. That lead never told several of the developers (excuse was because of “time”) that the code was changed. That’s just unacceptable.
c) communicate all the requirements if you are the actual PM so that your developer can get a rock solid start which includes understanding the problem domain and "parts” to be implemented.
Do not give a one line sentence such as “Implement the virtual product page in the CMS system”. Ok, what the hell does that entail? Tell them in decent detail. Also, don’t just ramble when you do…make it clear.
9) Treat everyone as equals
In other words, through your actions do not play favorites or gossip about other members of your team. Keep it professional and treat everyone as valuable members of the team
10) Do not micro manage. This will make your developer absolutely despise you.
It’s ok to check status if you really need to, but do not constantly go to the developer’s desk and bug them daily. That will screw up their motivation, concentration, and ultimately your project is going to fail if you keep interrupting them with “is it done?, is it done?, is it done?”. Give them some breathing room so that they can think and code. Pace those follow-up checks very carefully and don’t come across as a nag.
Furthermore, lets say you agreed that the developer has till x day to get it done. Give them till the end of that day. Do not come in at 9am after they just came into work asking “are you done? are you done? how’s it going with that, yada yada”. Take a breather as a manager and just chill. You agreed to this date, so give them that day. Maybe ask them at the end of that agreed day how it is going, otherwise scat.
11) If a subordinate is struggling, lift them up
Do not make them feel as though they are slow or stupid. I’m sure that you have also struggled just as much in past positions but are afraid to admit it if you are one to do this. I once heard a manager tell a developer “there are stupid questions” and that “we pay you to know this stuff”. Right after that discussion, I see another developer ask the same exact question later in the day but that developer does not get called out. And then the weeks prior, several teammates were asking similar questions. This is unacceptable and clearly plays into favorites which causes friction in your development team.
12) Understand that there must be some time set aside for your developers to study/learn
Ideas:
a) You as a lead hold developer meetings on a topic. A short training session
b) Bring in an outside company for a one-day in-house training about some complex code topic that applies to the work your team is doing (e.g. unit testing, mocks, MVC, whatever)
c) Give them an hour or two each week just to read a book onsite. Sound crazy? I don’t think it is. It’s essentially the same as bringing in an in-house training session about a subject which many companies do.
13) I don’t care what the deadline is. Take the human aspect of work into perspective in regards to YOUR team.
There will be times that people on the team are:
a) sick
b) burned out (hopefully this won’t happen much if you know how to manage right)
c) emergency in the family
d) other
You have to take those unexpected “human” aspects into account and plan for that as they present themselves. If you do not, and just completely disregard the human aspect and say that “sorry there are no excuses that this is late” when that person has a significant life event , then you are not being humane and not managing a healthy team. You’re a slave driving ass and no it’s not amusing or productive. Yes, this means that you have to manage and maybe change up the plan, schedule, and change the tasks if you can and delegate and respect those people that have those human issues here and there. If you don’t, again, you will burn out your team and they will not enjoy their job, code, and ultimately your project will suffer more. Companies are missing the human aspect in corporate culture and I’m pretty much sick and tired of that type of management. They are just machines trying to keep the assembly line from burning up. And when one screw becomes loose (teammate is burned out or sick) they just keep plugging along until the assembly line fails. Not good. When that person comes back to work, do not be an ass. Don’t act as if they did you and the team a disfavor by being sick or whatever the heck the case may be by showing it indirectly in your actions…by being hard on them and being even more unrealistic about deadlines when they come back to “make up for the time”. Just chill and keep chugging like you were at the same tempo as before they left. Again, you want a happy team, not a resentful team. And if they are happy, they will work hard for you.
14) Stop saying “it’s easy” to your developers
One of the most annoying phrases you get form managers is “it should be pretty simple”. Boy what a dumb statement. In theory a lot of things are “simple” when you first think about them. But oftentimes these leads end up admitting later that it was not easy or they thought about it later when you started that “simple” task and figured out hey, it’s NOT that easy. Keep your mouth shut. Instead, tell the developer you think it should take around x days. Tell them it’s less complex. Don’t ever tell them it’s easy. That’s just a stupid stupid naive statement to make even if you are 99% sure it is easy and hey, maybe it is. But make sure you don’t communicate like that. A developer doesn’t want to hear that being the first thing out of your mouth when you assign that developer a task. And that developer has not even had the chance to really take a look at the task yet. Let them give you an estimate. Stop saying everything is “easy”. Easy is a relative term so basically you’re saying it’s easy for you but depending on the skill level of x developer on your team, it may take 1x or 2x as long. That’s ok, let them figure it out…bust their ass but let them figure it out. Don’t start the conversation on a new task like that. Word it different.
Now to conclude, I’m not saying the lead or manager is to spend all their time in meetings, talking to subordinates, training, etc. However at the same token, don’t present an attitude or run an environment which doesn’t at least do some of this above if not all in a measurable amount consistently. Figure out your way to incorporate this but don’t half ass it or enact it only for a short while then dump it. This is just as important as those deadlines to ensure success if you are to be a manager.
I am also not saying it’s ok for a team to slack or that the pace be a lazy pace. Not at all. I’m saying be realistic. If the engine is getting too hot, let it cool down. Be aware of your team and its needs and that engine will continue to produce well for you.
Management is not just about deadlines (business likes to think it’s 100% that but that’s why they often fail), it’s about people and communication and success with motivation and growing as a team together in order to facilitate meeting those deadlines. Do I think that any manager can take into account ALL points above along with their insanely busy schedule? Certainly. And if you feel that this is not possible please do comment.
Is that not why managers / leads get “paid the big bucks” after all? You bet it is.
