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.
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"
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?
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.
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.
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.
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.
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.
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.
Some personal introspective criticism I've been wrestling with.
- "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.
[1] https://www.inc.com/jeff-haden/8-signs-an-employee-is-except...
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.
- 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.
I am not sure he was right here, different people may have different ideas of happiness.
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.