[mharroun]

In the past 13 years have gone from dev -> tech lead -> manager -> director -> VP/CTO at startups (50-250 people).

Here are my tips:

- Your job is to provide effective technical solutions to business problems via managing a team(s) of engineers, everything else is an extension to that.

- Managing is nothing like coding and requires a completely different mindset and skill set.

- Authority comes through respect and understanding, not rank/title.

- When you are pressured or stress reverting to what you know (coding) is almost always the wrong answer.

- You should take all the blame but distribute all the credit to those under you.

- Code quality in itself is meaningless, you must learn to balance quality and hitting deliverables.

- Say no / only agree to what you know your team can deliver on... and always double your estimate. In the long-term reliability is valued over agreeableness.

- Culture above all, a team that likes working together and takes pride in the product they work on can overcome most obstacles/issues/failures.

- At least once in your career, you will face a direct who is very smart and very productive... but is a complete toxic asshole to everyone around him. Fire them... by the time you have seen the true damage they have done its too late.

- Managing people is hard, each person is unique and you need to tailor your approach in a case by case situation. You will get a lot more out of people if you understand them and they trust/respect you.

- You should always allow your team(s) to grow/learn/try new things. However, engineers are always looking to learn the latest fad/tech to grow their resume. Building things with tools your team does not understand is a risk, attempt to minimize that risk.

[chiefalchemist]

"- Say no / only agree to what you know your team can deliver on... and always double your estimate. In the long-term reliability is valued over agreeableness."

Early in my career I read that X (almost) __always__ takes twice as long and cost twice as much as you typically estimate.

I can't count the number of times that's been true. It's also universally true. e.g. Wanna hang a picture. Piece of cake, right? Until you have to find the stud. Likely get a tape measure to get the height right, etc.

Perhaps an over-implied example, but once you start to keep track in your head of your estimate vs actual, the 2x Rule pans out quite a bit.

[fencepost]

That sounds like a good example when getting pushback on estimates: "Here's a 24x36 picture in a wooden frame, how long will it take you to hang it on that wall over there?"

After getting an estimate ("15 minutes?") come back with "OK, let's plan it out. Does the picture have hanging hardware on the back or are you going to need to get some screw eyes and wire and install some? That's a pretty heavy frame, do you have good enough wall anchors? Are you going to need to drill to put them in? Do you need to be going into studs, and do you have a stud finder? How high are we going to put this? What if I decide I want it 4 inches higher? If I come back in 15 minutes and ask why it's not up are you going to want to punch me?"

"That's why an off-the-cuff estimate isn't reliable and why we need to do some review before giving a good one. Even with that review, there's a good chance we're going to miss something at first (like the steel support beam that runs down the interior of that wall)."

See also Yak Shaving and the intro of Malcolm in the Middle Season 3 Episode 6 "Health Scare"

[mharroun]

My suggestion is when asked off the cuff always toss an estimate that is astronomically bigger then what you expect it to be. Then come back a day or 2 later and claim after further research we can do it in (2x your real estimate).

[chiefalchemist]

Agree. __Always__ start high and then you've "reserved the right" to adjust down. Else, most people will think you're trying to rip them off.

One of my TODOs for 2019 is to come up with a checklist (for building websites / basic web-based applications). There's no sense assuming the client is thinking of all the things I'm thinking of, and vice versa.

The little things always add up. For example, does the client expect 1 hour or 3 hours of edu on using the CMS?

[balaji1]

Great answer. I transitioned to a lead role recently, on a small but growing engineering team. Agree about being conservative on estimates, trading off code quality. I did jump in and code during a stressful situation, not ideal. Any tips about how to report to higher management? And how to tell if things are going well/bad on the team, esp in a startup?

[mharroun]

This is hard... like your directs you need to manage your manager as well and try to understand them.

For your manager, you should have (or try to force) at least meetings every 2-4 weeks where you can ask what you can improve on or what they feel is missing/lacking in your team/department. Always come back next meeting with ways you have improved or reacted to their comments. If they are a decent boss they will always be honest with you.

As for how to tell if things are going well internally...

- does your team(s) feel happy/proud on what they delivered? - does your team(s) seem happy and enjoy working with each other? - do they focus on deliverables/value and not get caught up on petty issues?

are some questions to ask.

[shadowwolf007]

To be honest a lot of your suggestions are probably very solid but come off like the "Find a mechanic you can trust" solution.

By that I mean the advice of "find a mechanic you can trust" only is applicable to someone already familiar enough to know how to determine if a mechanic is trustworthy.

A lot of your advice is probably 100% valuable, but as someone working through a lot of these same concerns I'm stuck wondering "Well, how do I know I'm actually doing that?" It leads me to wonder if I'm actually successful at any of this or just Dunning–Kruger-ing my way through it.

[mikekchar]

Our mechanic was ripping us off. There's this scam where they overtighten the screws on the oil pan and crack the gasket. Oil leaks out very slowly and in some cars ends up on the leads to the battery. This corrodes the leads. They then charge you for a new battery and tell you that there is a electrical problem in your car that will cost thousands of dollars, etc, etc. Luckily I knew about this scam and when our car started losing oil directly after an oil change and the mechanics refused to do anything about it, I was able to tell my wife what was about to happen. This convinced her that the mechanics were scamming us.

So the question became, who do we send the car to. There was a young guy down the street. He was taking apart cars and putting them back together again. His friends were all into racing and while he had previously worked at a dealership, he quit to live the dream of repairing racing cars. Of course he was broke. I told my wife to wander over and see if he wouldn't mind looking after our car. Great mechanic and saved us thousands compared to what the swindlers were doing. Previously the car was breaking down all the time. After we switched it never had a problem. When we replaced our car recently, we gave him our old car as a thank you. Good mechanics are worth keeping happy :-)

It's not really a science for finding people who are good at what they do. There is not a thing that you can pinpoint and say, "That person is definitely good and that person is not". But I think if you start with the proxy of, "That person loves what they do and sacrifices a lot in order to do it", I think you are more likely to find someone good. Not 100%, but you've got a much better shot at it.

Edit: I misinterpreted your post and assumed you meant that you were looking for a good lieutenant to help you. I need more sleep! But either way, work at being that good mechanic in the same way -- love what you do and work hard at it. You'll definitely make progress, so don't worry about it.

[shadowwolf007]

I'm really glad you were able to avoid that scam. That's super scummy.

I built this premise because I do read a lot of car forums and, quite frequently, people would ask "Hey my car is doing XYZ" and a lot of responses would be "Take your car to a mechanic you can trust." To me this is basically telling them "Already know the answer to your question."

One time a guy answered basically saying "Hey, go find a guy who has a car in his driveway he works on every weekend, bring a 6 pack, and ask him for an opinion." It totally opened my eyes to how different types of advice really change people's perspective.

I believe that the value is in explaining what a person who loves what they do actually looks like.

[softfalcon]

I was recently recommended a couple books called "Extreme Ownership" and "The Dichotomy of Leadership". They tackle the idea of how to be a leader and what that means in the day to day.

They break down the communication with your team into a principle you want to strive for. Then you're shown an example of how that happens in the real world.

Once you've seen the patterns, you notice them everywhere, and you begin to unravel the issues, one hurdle at a time. It's like seeing a great design pattern, seeing where it fits and how to apply it, except now you're doing it with communication instead of code.

I think this might help you "find a mechanic you can trust" and get to the heart of what it takes to lead your team.

[mharroun]

That is a fair criticism, my tips were just a list of the top notes I could think of to help. I could dive extensively into each and every bullet.

I will say if you constantly questioning whether you are doing a good job and if you can do better... you are probably above average at least.

[shadowwolf007]

A struggle I've had is I'm used to casing performance in terms of errors or negative feedback. So far the feedback I've had is almost all positive (team is far above previous performance, flight risk is far lower than other departments, etc) but I don't feel like that's helping me improve cuz I don't know how to actually deal with positive feedback.

Some personal introspective criticism I've been wrestling with.

[MichaelMoser123]

How do you define 'toxic'? How often do you fire workers for being 'toxic'?

[mharroun]

Toxic examples:

- "This is stupid" or other negative comments in code reviews (aka non-constructive criticism)

- Yelling or cursing at people because they question you and your decisions.

- talking bad about the company or other teammates to people behind their back.

- throwing a "temper tantrum" when you don't get your way when it comes to some architectural decision.

- refusing to work with certain people or only willing to work with certain people.

- Making large-scale decisions and changes without documentation, discussion, and buy-in from engineering leadership and your peers.

[MichaelMoser123]

I agree with these points, however some level of quirkiness is defined as a hallmark of very effective workers here [1] I wonder if it might be possible to misconstrue behavior and label off such an individual as toxic.

[1] https://www.inc.com/jeff-haden/8-signs-an-employee-is-except...

[MichaelMoser123]

Thanks for the answer. I hope all firms have a formal HR process where they state expectations and confront the individual before he is labelled as toxic. I think everyone should have a chance!

[laurentl]

Well, for truly toxic individuals, warnings or confrontations are useless (I’ve learned this the hard way, and not for lack of trying). It is impossible to get them to understand that they have a problem; anything you say, no matter how clearly articulated, fact-based, and objective, will be rationalized away. These individuals cannot accept that they may be wrong.

[idreyn]

Since no one else has answered this I, a lowly developer IC, will give it a shot.

Start by writing up a detailed employee handbook and code of conduct. Have a conversation with new reports about how these inevitably jargon-laden documents translate to expectations in human terms. You don't need to use the word "toxic", but talk about assuming good intent, communicating respectfully and clearly with others, and sharing credit and responsibility with teammates.

Create a sense that serious feedback about teammates' behavior given to you, the manager, about teammates' behavior will be taken seriously and kept confidential. Do this by handling the smaller stuff competently.

Give feedback to employees who are creating bad team dynamics early and often. Allow them opportunities to reflect and improve. Emphasize if necessary that their behavior is not just problematic at an interpersonal level, but it's (presumably) disrupting the company at a business level as well.

Work with HR to keep a paper trail and document conversations so that when the time comes to fire an employee who is irredeemably "toxic", there is a rich timeline of unpleasant behavior, feedback and warnings, and a failure to sufficiently improve over time. Ideally only someone with their head all the way up their ass wouldn't see how the patterns of behavior relate to documented expectations and to termination, but unfortunately that's who you're dealing with.

I suppose all of this only works to immunize against "toxicity" in a work environment that isn't already toxic.

[MichaelMoser123]

I think these are very good ideas, actually I don't recall to have seen an employee handbook that states expectations explicitly, even while working for very big firms. Well, at IBM they probably have something like that, I may be wrong about that.

[aerophilic]

There is a quote I once heard “Good teams are usually great for the same reasons, bad teams are almost always bad for different reasons”. This is the much the same for people. Generally speaking, the best people you have worked with are very similar in terms of what they provided that made you really happy to be with them. Example “good” traits:

- honestly - dependability - integrity - intelligence - humility - excellence - generosity - proactivity

Toxicity happens when people exhibit the opposite of any of those. A favorite example is folks who constantly bad mouth other people on the team. Well, if you work with that person, you just know they are complaining about you behind your back as well.

[MichaelMoser123]

I think that quote comes from Tolstoy when he was writing about families in Anna Karenina. " All happy families are alike; each unhappy family is unhappy in its own way"

I am not sure he was right here, different people may have different ideas of happiness.