Ask HN: How do I deal with my engineering team and motivate myself?

So they have to learn their own stuff PLUS what you learn? That doesn't seem very fair. Why do you get to do less?

This is likely a big part of the issue. You can't make them learn.

> Just to let you know I constantly keep asking for feedback from my Reporting managers and my team and keep on improving.

Wow. Chill out. No need to harangue people to get your job done.

I'd say to adopt the role of team "anthropologist" and spend some time with them just observing. Take notes on how they behave, communicate, work together, etc. After a few weeks (or months) of this you'll have a very different view.

Chances are, your keen observational skills are better than your winning personality.

Its a good bet that you're taking a paternalistic approach to managing your team, based on your feeling that you're taking care of them and teaching them. This never goes over well. Like, ever. Recognize that your team probably would rather write some code than be taught by someone they may not respect all that much. They're almost certainly capable of determining for themselves what they need to learn in order to do their job. If they can't do their job, thats where you get involved.

I had a manager once, this guy who was incredibly invested in this picture of himself playing this this role as fearless leader, cool startup guy, and all around genius. He went so far as to write down some speeches he later read to us in what I presume were "leadership moments" in his head. He very nearly killed the company, and every single member of the tech team left before it was done. Don't be this guy.

There's a book by Dale Carnegie called "How to Win Friends and Influence People". Recommended.

That doesn't sound like a pleasant work environment.

>teaching them engineering aspect

Did they willingly sign up for the teacher-student relationship with you?

> I FEEL THEY DON'T LIKE ME and think I am jerk.

You're probably correct.

> wondering if I am really that bad.

Not bad, but improperly initialized. Or there's a syntax error somewhere, an improperly synched function. There are piles of soft skills to be had.

Engineer, debug thyself. It is the golden age of self help books. As a triage measure you want to stop this behaviour cold and instead listen for a few weeks as you absorb the wisdom in whatever self-help-soft-skill-communication-management book you find speaks to you.

Your post is almost entirely about you. Do you only talk about you at work? It might explain a bit.

What are your team members actually like? Their personalities, interpersonal conflicts, aspirations, successes, strengths, weaknesses?

I don't know either you or them, but the fact that you have asked us all for help and told us almost nothing about them suggests (to me - I may well be wrong or biased) that you are not spending enough time getting know them. I expected you to tell us specific situations that would lead them to not like you, but you seem not to know any. I doubt they would be short of reasons if we asked them. It's rare to find anyone who dislikes people for no reason.

For me, a team lead's role is not coding. You are there to assemble, manage and grow the team that will do the coding. Maybe that involves doing some of the code (more likely the code reviews) yourself, but maybe not. Your real role is the people management and that involves a deep understanding of who these people are and what motivates them. If you are trying to stuff engineering knowledge down their throats when what they really want is autonomy (for example), then it's unlikely they will warm to you.

I would recommend approaching this as a completely new skill, which is as hard to learn as coding was. Some people build their careers entirely on being able to manage and grow teams. It's worth noting that these people tend to get paid more than the developers they manage :)

Sorry I can offer much more insight, but there's not a lot to go on. I hope things improve for you.

Might I suggest that what your role now is not to be the best engineer, but to act as their manager, primarily. Put down the engineering books and pick up some management ones (e.g. "Behind Closed Doors" or "Manage It!", both from Prag Prog), because you are likely the one failing to learn or improve in ways appropriate to your job.

That emotional filter is going to make it really hard to get your head on straight about both how you're really doing and what you can do to improve.

The most important thing you can do is try to improve your own self-understanding and get yourself mentally prepared for doing a really hard job. Unless you have a strong ethical/religious/psychological/mindfulness type thing in your life, you also are probably somewhat out of touch with the unintended but real impact that your words and actions have on other people. The worst managers I've ever had were well intentioned and smart but completely lacked self-awareness of their social impact.

I would start with trying to take stock and get your own feelings and perceptions under control. Once you can look straight at the situation, without fear or shame, but also with a critical eye, you can orient yourself and get better.

So how do you do that? Well, it depends on your background and what kind of thing is going to call you out of yourself and into a different way of thinking.

- Belong to a Western religion? Go look for something about contemplative prayer or discernment in your tradition. (Catholic or open to it? "The Discernment of Spirits: An Ignatian Guide for Everyday Living" is great)

- Into new age, yoga, or Buddhism? The book "Mindfulness in Plain English" is really helpful.

- Like agile, or at least the idea of self-directed teams that are coached rather than managed? Lyssa Adkin's "Coaching Agile Teams" has a lot of great content on removing your emotion from a situation, helping people succeed on their own, etc.

- Do you find yourself in difficult conversations, where you either are too harsh and people don't listen to you or too soft and you can't make your point? The books "Difficult conversations" and "Non-violent communication" have awesome advice on thinking about the way you talk with people and reframing issues in a productive way.

There are tons of other places to start, but I hope you embrace my core point. Start with yourself, get to where you understand your own bias, emotion, impact. Then worry about helping other people and getting better in your day to day.

One of the best attributes I've found in good managers is facilitating success, rather than participating in it. In one-on-one meetings with your team, listen closely to them. Ask them what they'd like out of you, what their goals are at the company, and how you can help them achieve those goals. You are no longer writing the code, and while you should have final say on high-level technical debates, let your team work out organically what the best architecture / pattern / technologies are for the project at hand.

If learning is something you want to encourage (bravo for that, all teams should be actively learning), use whatever power or influence you have to make resources available to them. Paid time to read books, paid time to attend conferences (and budgets to pay for conference entrance / travel), etc. And instead of you dictating the points of learning, ask them what they think they need to focus on learning for their own improvement.

Lastly, do everything you can to limit their distractions. Instruct coworkers in non-technical disciplines to direct all questions to you, be the development team's "shield" against pesky interruptions. Managers who have done this for me have won my respect much quicker than those who have not.

This is slightly embarrassing to talk about, but when I was younger I was not actually hugely popular with the opposite sex. I always prided myself on being a "nice guy" and I was incredulous as girls went out with "jerks", ignoring me. I convinced myself it was because I wasn't good looking enough, so I got into body building and got into great shape. Strangely this did not help.

I won't bore you with the details of my self-discovery, but eventually I did figure out the reason for my lack of popularity: I was self absorbed, arrogant, oblivious to the needs of others, etc, etc, etc. From the perspective of others, I was the jerk. My evaluation of the "jerks" was based on my set of values, which other people did not share. I eventually discovered that I needed to understand what other people valued and give it to them (if I wanted to be a "nice guy").

It's hard to know exactly what problems you are running into without meeting you. It is very common, however, to have the same kind of problem that I had -- you are judging everything through your own criteria and ignoring the criteria of others. Rather than trying to further your own goals, forcing others to fit your mould, you may have to spend considerable effort trying to understand what your team mates value and try to help them achieve it.

The tricky bit is that sometimes what your team mates want appears to be at odds with what the company needs. Often you will have to make the hard choice -- do I help someone get what they want individually, or do I help the team achieve the goals as stated by the company? To make it even worse, very often your idea of how to achieve the company's goals may be incorrect. My experience is that at 7 years of experience you are just starting to discover ways that will work, but there is still quite a lot to learn. You are likely to make many mistakes along the way.

You can imagine that if you chose to help the company against the desires of your team mates, if you fail (in their eyes) they will be extremely upset with you.

One last piece of advice. There is nothing wrong with choosing the side of team success, even at the cost of pissing off your team mates. The personal cost can be high, though -- especially if you make mistakes (as you undoubtedly will). I would favour a mixed approach where you help your team mates meet their own personal goals and only stray from that path when you are absolutely sure that you will be successful. YMMV.

Architect = lead engineer

Manager = career/growth + interface with upper management

What are you?

Personally my philosophy towards management is all about humility and logistics. Get the right people in the right roles, and supply them with the right tools. Combine that with the humble approach towards things like credit for accomplishments and project ownership. Then suddenly you don't have to push any more. You don't run around telling everyone what they need to learn, instead they all teach you in their area of expertise. You give them the cover they need to go out and learn more in their own way. Instead of running around teaching, let them ask you (or each other).

Managing engineering teams is hard, and it can sometimes be very UN-fun, especially if you want to code, or if you manager expects you to remain technically productive.

You feel like people don't like you, but didn't mention what they actually say or how your performance reviews have gone. If you're being left in charge of a team, and given adequate raises and/or promotions, chances are your manager(s) feel you're doing a reasonably good job.

If you're getting negative feedback, then of course, listen to it carefully, work hard to not get offended, and plan how to address it.

If you're not getting feedback, and assuming that means people don't like you, keep in mind that it's natural for lack of information to turn into fear. Remember that everyone is the protagonist in their own story, not you. Your direct reports have their own fears and may simply not be worrying or thinking about you. If your reports are worried about their jobs, or if they feel continually unproductive, then they might not like anyone at your company.

You might want to think about how your team could be feeling the very same way you are. You might need to considering doling out a lot of the kind of positive feedback you're hoping to receive.

Tech managers, and all middle managers, have a hard problem with conflicting forces. Your team wants more time to think, they wants to solve interesting problems, and they probably do want to learn. Your managers want a reproducible process that delivers bug free work and continuous improvement on a tight schedule. You're stuck in the middle.

Good luck. There are tons of great resources out there, so keep reading and learning, keep your chin up and stay positive and hopeful, and remember you have a people problem, not a code problem, and remember your performance is no longer individual; you only succeed if your team succeeds, so you need to help them succeed at the expense of your own interests.

There's also a certain amount of displeasure from purely technical folks on reporting to or being managed by trained managers; those with MBA's and whatnot - irrespective of your previous experience as a developer yourself. Obviously not by all, but a few here and there. Agile / Scrum etc fare much better with devs, not tradional PMO etc.

Both these things count against you, and the worst thing you can do then is to enforce the things you've learnt from your management training - as there will always be a certain amount of pushback, especially if you try and make them aware of the business case behind it - some devs like to know the bigger picture, others don't care; they don't want that pressure.

It comes down to paying attention to each person, not the collective, and figuring out their needs. Software or core skills make up very little of how they would see you; some of the most talented Scrum masters I've met have never touched a line of code, and I respect them more so for it.

As a manager / leader, some of the best ones I worked with and now try to emulate are the ones that trusted me to get the job done, and made it possible for me to do so. They sheltered the team from the flack coming from higher up, fought for various privileges, always took the fall for any shortcomings and essentially made an excellent environment for us to work and communicate, not to mention they never let you feel the pressure and allowed you to continuously fail and learn from it.

Instead of thinking of your role as trying to educate and lead, try thinking more in terms of "what can I do to help my team succeed?" and then ask them that exact question - every day, every week. You're not their teacher, nor are you their guardian. You are there primarily to make sure that your team can go about its business unhindered from all the bureaucracy and whatnot that gets thrown at them.

Once a team knows you'll go out on a limb for them, they'll trust you and then reciprocate with their work and actions.

Do you perceive yourself as liked in general, and these latest jobs are the exception? What's the concrete evidence, if any, of this attitude?

By all means be friendly with your team but don't compel them into a one-sided conversation for the sake of improving them (or yourself). I'm sure they can manage their lives just fine.

#1 - He bridged the personal/professional gap well.

I've worked at good places and shitty places, but the thing all my previous managers always lacked was being able to talk with me at the level of... how my behavior might not only affect me at my current job, but at future jobs. Call it sort of the.. "one man's opinion" approach. Nothing ever felt like I was walking into a room to be fired, but if I was doing something stupid, he explained how choosing to stick to that approach might limit my growth there, how it might limit me elsewhere if I wanted to switch tracks. Every problem felt like it was getting advice from a mentor, not a manager.

#2 - He looked out for my career.

This sort of follows from #1, but he was always receptive to my input about where I wanted my career to go, how to help me get there, and what steps I could take within the confines of that job.

It was a PHP shop with limited upward mobility - it wasn't ever going to be Google-scale problems, and he knew that. He worked with me to try and help me find interesting avenues of work to pursue to keep me interested and to fit with the way I worked. You'll have people that prefer working by themselves, others who mesh with teams, people who enjoy both, and other sorts of combinations. He gave me choices. He asked me what I wanted. That mattered, to me, a lot.

#3 - He never tried to be an individual contributor.

This is probably the reason why I don't see myself being a manager in the future: I enjoy actually doing things too much. From chatting with him at a personal level, I know he liked to have input and do things as well. Despite that, he stuck to being a manager. If there was spare time, or something he wanted done that maybe would take a hour... he'd do it. He had the technical chops to come up with ideas, and debug things with the rest of the team while shit was on fire... but he was never trying to be an architect, or refactor large swathes of code. He was our manager; he had the background to understand exactly what we were doing.. but it was us doing it, not him.

Maybe the concepts/terminology are weird where you work, but it sounds like you're in a managerial position when you really want to be an individual contributor. As others have mentioned, you focused a lot on yourself in your post, and reading between the lines, it sounds like you'd rather be writing code than managing people.

Just food for thought. I hope you get some good feedback and can get your current situation pointed in the right direction.

Consider this: most people will like working for a lead who gives them a lot of value. This isn't necessarily an "education" -- that's not a really tangible thing that directly improves their situation, and it feels bad.

What a team lead can do, that does improve their situation, is allocate work that gives people the opportunity to grow. Work allocation is one of best ways to mentor a junior engineer, if you give them the right work. Andy Grove touches on this a little, when he describes "task-relevant maturity." Beyond that, engineers need projects they can point to, that show off the upper ranges of their abilities, in order to experience career growth.

Beyond that, the usual team-lead skillset applies: providing cover to do good work (redirecting bullshit), long-range vision and planning, and reducing uncertainty. Hope this helps.

This will only be an issue in the way you relate to them when they fail. Failure must be treated as a learning experience.