Understanding that delegating tasks, instead of doing them myself, was of the utmost importance the more people I managed... especially, greenfield work. Literally: do not steal the fun. This also means inherently trusting people, and if you can't do that you shouldn't be working with them. two important notes about that:
1. If you just thought of someone you can't trust instead of thinking about how you can give more trust to people, you just had your ego stand in the way of mutual success. You are a shitty manager, and today is hopefully the first day of you recognizing that and learning to trust.
2. When people don't deliver what you expected, it's because you did a shitty job of communicating it to them. What seems obvious to you after 45 minutes in a meeting with three other people already prepared for the topic will most of the time seem obvious to no one else. If it does, I can almost promise, their vision of it is totally different than yours. Learning to work through the defining the problem (that includes asking "does this problem exist?") and then guiding solutions (we have x days, engineering hours, etc available) to ensure they meet the needs of the business. If no one but you delivers things correctly, you're a shitty manager, and today's hopefully the first day of you recognizing you need to learn to communicate and trust.
Not many people are lucky enough to be told so plainly it's their ego, but it's your ego that causes your team to fail. Maybe it's your boss's ego that's causing you to fail... I was told plainly to my face to not let my ego get in the way of the goal... and yeah it punched me in the gut too, so if you're hurting, or in denial know it's okay. We all have to grow, it's worth it.
> When people don't deliver what you expected, it's because you did a shitty job of communicating it to them.
Why is this necessarily the fault of the manager's communication skills?
Sometimes the person sucks beyond repair and needs to be fired.
If you have a competent person who didn't deliver what you expected, then yes, it's probably the fault of the manager's communication. Not so for the lower-end of that competence spectrum.
It might still be the manager's fault for hiring that person in the first place, but that's separate to it being their fault at not communicating properly.
The shitty job here is not firing that type of person quickly enough, and misdirecting the blame towards your communication skills.
If requirements were provided and person didn't fulfill them, they did a bad job. If requirements were fulfilled, but you aren't happy with the result, then you did a bad job.
> If requirements were fulfilled, but you aren't happy with the result, then your requirements were wrong.
Isn't it possible for a dev to fulfill requirements but still deliver a bad result as measured by subjective (but important) things such as code smells, bloat, crappy algorithmic logic, and so on? Or do you think managers need to spec things out in such strenuous detail that surprises (but also, to an extent, autonomy and ad hoc decision making) aren't possible?
There's also the case of R&D roles where it's hard to spec things out exactly in advance, and you're partly relying on the employee's ingenuity.
You're talking about completely different thing than what OP was talking about. It's about developer having a different vision than you.
You either need to accept that someone sees the problem differently than you and accept their solution, or if it is something important to you, you need to get better at explaining your vision.
Anyway, back to your requirements, as you pointed those requirements are subjective. If those are important things you should still outline what's expected. You don't have to do it for every project, and can be when person is being on-boarded.
Right, in that case I'm in agreement, if the employee didn't deliver what was expected because they didn't understand (or weren't convinced with) the manager's vision, then that's most likely the fault of the manager's communication.
This happened to me this past week. I built exactly what the spec said. They came back and said it all looks good, except we expected this to be that. Um, nothing about that was in the spec, nor was it ever mentioned verbally in a meeting. Making the change from this to that will require everything to be redone since it requires fundamental changes. I would have built it differently had it been communicated to me from the beginning. Apparently it didn’t occur to them to mention it. But they really want it. So I’ve started rebuilding it. Sigh.
A key skill of a senior developer is a sixth sense for this kind of unspoken requirements, and asking questions to flush them out. Not always possible, of course.
This is why it’s important for devs to understand the problem being solved with their code, not just blindly executing to a spec that everyone knows doesn’t spell out every last detail the customer is interested in. Stop treating devs as fungible spec builders and more as partners of the business so they can shift from building against specs to solving real problems. The devs who have this “sixth sense” are finding a mismatch between the spec and the underlying business problem problem they know they are trying to solve.
> A key skill of a senior developer is a sixth sense for this kind of unspoken requirements, and asking questions to flush them out. Not always possible, of course.
While true, a key requirement for even senior developers to function well is good management or a good team lead.
If effective management doesn't exist, the senior engineer should be made manager/team lead since he's doing that work anyway.
On the other hand, if management is micromanaging, then the responsibility of clarification is on the micromanagers.
Management of knowledge workers is a hard job. Most managers are incapable of understanding their reports and understanding their OWN standing among their reports.
I'm not trying to suggest that. I'm suggesting an accurate diagnosis of the mistake that was made by management.
In the case of my example above, it was a failure of management to hire a sufficiently competent person, or a failure to fire the person when their lack of competence became apparent. It wasn't (in my example) a failure to communicate requirements properly.
OK I get what you are saying, but if a manager is not able to communicate clearly enough that employee understands the directions given, then it is the fault of the manager.
If the employee understand the task given but does not have the skill to carry it out satisfactory, then it may be a question of the competency of the employee.
It doesn't matter who's fault it is. Communication failed. You can fix it by changing yourself or the other person, but only one of those solutions is within your power.
First of all, nobody "sucks beyond repair" -- everyone can grow and evolve although some people may start at a point where the company doesn't have adequate enough resources to make an ROI off of its investment.
The problem is, some people have a fixed mindset rather than a growth mindset because they've never seen anything different so they think it's impossible. When you say "Sometimes the person sucks beyond repair and needs to be fired" it ends up functioning as a red herring to deflect away from poor people leadership. It's a naive excuse made to hide a lack of understanding regarding how something really works.
To figure that out, let's ask this: how do you think the manager hired that "wrong" person in the first place, and how do you think that person ended up in a place to end up failing?
My point is not to be socratically pedantic here, but to point out that communication is /hard/ and often times an inadequate deployment of it is at the root cause of these kinds of failures. What kinds of communications could have gone wrong here?
1) Failure to adequately communicate with higher ups about headcount, business goals and necessity/capability to deploy extra headcount
2) Failure to adequately communicate requirements for the job before hiring
3) Failure to adequately communicate during the interview so as to properly assess candidates
4) Failure to adequately communicate expectations, progress, onboarding and plans after a candidate onboards
Guess what happens if anything about this chain of processes is broken internally? The candidate will fail, and due to circumstances out of their control. And then they will move to a more functional organization, and wonder why they ever wasted their time with this one.
Now, whose responsibility is it to make the right judgment call about that? Whose responsibility is it to have the right internal /communications/ to make sure the decision is well thought out and solid, to make sure it is brought through to fruition successfully? Who reaps the ultimate rewards, and who ultimately shoulders the greatest burden for mis-execution?
Not the IC. It is leadership. This isn't rocket science.
Eh, that describes exactly my last job (which wasn't bad, I liked my coworkers, but my last manager made it a horrible experience), worst job I had so far.
He wasn't bad as an engineer, but he had this crazy OCD to a point that even keys in YAML file should be ordered alphabetically.
He had his vision how things should be, and how he would implement them.
First, he was not happy that my solutions were done differently than what he would do.
Then, when I learned about that he wasn't happy and tried to do it the way he wanted by asking him question about it he told me that I required hand holding and as a senior should not need that. Yes I'm senior, but not a mind reader.
I would think that someone who majored in psychology would be better at something like that, but I guess the only thing he learned in psychology class was Socratic method, which he constantly overused when talking to others.
He though he was being clever but only made me think (because I couldn't say it to his face): "just fucking tell me what the fuck you want me to do"
Ugh, I'm so glad I don't have to deal anymore with this BS.
> He wasn't bad as an engineer, but he had this crazy OCD to a point that even keys in YAML file should be ordered alphabetically.
Eh, I am guilty of that (for myself, I don't run around other people's code).
I don't know if it's OCD but I clearly remember the moment I decided to order keys (in yaml, json, etc.): after a debugging session where I lost time because I was scanning whole lists with my eyes, looking for a particular key and thought "it'd be easier if it was ordered according to alphabet and not domains of concern".
Wasn't there a debate/online conversation about `girly code` a decade ago ? About tabs, alignment, etc ? Thank you prettier :).
IMHO having this as a rule that keys in dictionaries are sorted alphabetically can be a valid rule.
But this should be enforced in tooling, not "rules", and not through micromanagement.
Much like using opinionated code formatters - like `prettier` you mention. It makes lives of everyone easier down the line.
Sometimes this comes from years of experience (mostly pain ;)). Some leaders, while coming from a good place - I want to help you, and others, avoid pain in the future - communicate it very badly - do it like that... because I say so!
I had a look at prettier's github issues in the mean time and
> No, prettier tries not to change the semantics (specifically, the AST) of the program, and sorting imports/keys could break that guarantee. See here for more details and context, as well as links to similar/duplicate issues: #1684 (comment)
I think another option is to just let it go and you can "fix" it later if you want and have the chance. Just put it in a "cleanup" commit or something. Don't be passive agressive about it, make it a team practice. Sometimes people will change the style of your code, that's ok, it's not a slight against you.
However, if you get in a situation where people are changing styles back and forth then you need to talk it out. E.g. Alice inserts a blank line, Bob removes the blank line, Alice inserts the blank line again - time to talk about blank lines and code style.
In this case, if Alice sorts the dictionary keys and Bob couldn't care less, it seems both can have what they want by simply letting Alice sort the keys. And if it becomes a common thing instead of a one-off, maybe talk about it.
Thanks for posting the context for such a bizarre description. I can assure you that it's not worth continuing that train of thought.
However, if you want a positive, constructive frame the goal is self-documenting code. In that vein, here is a set of ideas I made a major contribution to amongst many other serious-minded software engineers.
Why? Does something being "girly" strike some kind of negative emotion? I don't think it is bad to associate organized and elegant code as feminine. You probably should read the article
> And there you have it. I think "girl code" is quite a compliment. Because caring about things like beauty makes us better programmers and engineers. We make better things. Things that aren't just functional, but easy to read, elegantly maintainable, easier--and more joyful--to use, and sometimes flat-out sexy.
Whether you see a trait as a positive or a negative does not mean it is useful to anyone to ascribe gendered terms to it.
A female software engineer who does not strive for beauty in code, is she less feminine? A male software engineer who strives for code beauty more feminine than the female one?
It is a useless argument to get into, when the actual way to describe the type of code would be a choice of "beautiful, sorted, structured, consistent" instead.
Not at all, I'm just wary of reinforcing gender stereotypes.
Even in the conclusion quoted here, the author says "I think it's quite a compliment". As if when you first hear the term "girl code", you're supposed to think "ew", and the author is there to convince you otherwise.
Why not just call it neat or organised instead? Using a gendered term does nothing but appeal to stereotypes and solidify them.
It's a prejudice about the human doing the work. It's not complicated to understand what the problem is. You should judge the work on the intrinsic merits of the work, not the worker. Every human has the right to work and be evaluated on the work, independent of the nature of their birth.
I feel like this is more common among insecure managers than with secure managers. The insecurity shows up in micromanagement. Micromanagement takes many forms, all the way from verbal status updates to toxic code reviews to lack of coherence in project plans or career plans.
Until this recent manager, I never truly understood what micromanagement and insecure management meant. Maybe I was lucky to have good experienced managers in the past. Insecure micromanagement truly crushes my motivation to work.
As someone who suffers from the same neuroses, I would push back on some of this a bit.
If you haven't built trust with every person on your team, that doesn't make you a shitty manager. The more people you can work with and trust, the more effective you may be as a manager, but don't let a counterexample serve as proof positive that you suck. Trust is a two way street.
Sometimes people underperform for other reasons that have nothing to do with you. They may have a different perspective, or they may just be having a bad day. Or they may have family or health problems affecting them. Or, they may actually just no longer care or not be good at their job.
For the first point -- I believe that OP wants the manager to extend trust as a mechanism and path toward both a trusting relationship and short-term performance.
For the second -- it is on the manager to know enough about the reasons affecting their report's performance to be able to adapt before the team underperforms. (and it is on the report to surface that information quickly so that the team isn't compromised)
How can this be accomplished? I take great pains not to get involved in my employees' personal lives. When they call out sick, I never ask why. While I do ask if "they need anything", they never have to tell me what they are sick with, or if they are even not sick and just need a day. I assume they are adults who are competent to manage their own time.
I once worked with a manager who would always ask for details like "oh you have a headache? Do you have a fever?" While I think his intentions were good, and that he just wanted to show concern and even offer support or advice, I always found the questions incredibly invasive and a violation of my privacy.
My team knows that I will always listen if an employee wants to share details of their personal lives (upto anything that crosses the line of appropriatness for work), but I would never pry.
So, in this example, I would never know an employee is struggling with a personal issue, unless they broached the subject with me.
Personally, if I'm sick, the last think I want to do is communicate with my manager - it means you have to be careful, you never know if they're digging, or 'professional but not exactly sincere empathy' etc..
'Adult Professionals' shouldn't need to be coddled. If you're sick you're sick and that's that.
If you have something that's a 'big deal' then you have that in a conversation in which the managers emotional response one would expect is empathy but beyond that it's a matter of 'how to work around it'.
'Trust' is a multifaceted thing, I generally do not trust that people will do their jobs well at the outset, until I've seen evidence of that, but as far as those kinds of workplace issues I definitely 'trust by default'. People get sick and that's that.
And then have a lot of tolerance because we are all a little odd in our own ways and it's just easier not to get caught up in stuff.
I trust my manager to not be a dick when I'm sick. I also believe he is an empathetic person who cares about me and wants to know what's up. I understand he has a list of tasks that need to be completed by his small team. So I'm happy to let him know whether I expect to be out for a day or a week.
If I didn't have such a relation with my manager I'd be looking for a job. If he doesn't look out for me when I'm sick he will probably not look out for me professionally either.
I understand the first point, but I disagree that is always going to be possible or the correct path. If you blindly trust every employee, you will eventually end up hurting the company, the employee, and yourself.
Second point, sure. That's the ideal. But it's not always going to happen, and you need to be able to deal with that situation to be a well rounded manager and leader. IMO.
And I'm saying there are points where it doesn't make sense too do that. I believe that's the most effective path 90% of the time, but you are not a complete manager if you can't deal with the 10% edge cases effectively.
> Sometimes people underperform for other reasons that have nothing to do with you.
You can still try to find out what causes their behavior (by showing interests into their perspective) and may be able to help them and therefore the team.
- If they have a different perspective, it should be helpful to listen to their perspective.
- If they have a bad day, it will go away.
- If they have family or health problems, you might not want know the details, but simply knowing that a person is going through a difficult time might give you enough information to know how to improve the situation.
Even if you are not the cause of the situation, you might still be able to improve it as a manager.
This is the quality I learnt to look for in a leader (I am not a leader but worked under few good ones).
I also noticed how good leaders never take things personally. They quickly move on and not hold grudge. I am amazed how good leaders are able to do that and in doing so inspire me to do the same.
You can work on it. Trust people with small things (or at least bite your tongue while they do it their way). Observe that nothing goes wrong. Trust more.
"Hire slow and fire fast". I've never seen a company that had not made several bad hires. The difference was the speed at which they were willing and able to identify them and remove them. You shouldn't trust someone the moment you bring them on, but I do believe that should be able to imagine yourself trusting them.
A general rule for me is that you should know within the first 2-4 weeks whether you've made a bad hire. This is a bold statement, but my experience is that this time frame will give you enough time to get a gut check (super vague, but there are too many different patterns for me to articulate here). If your gut says no, that will stick with you, and your gut will likely become a self-fulfilling prophecy anyways.
Understanding that delegating tasks, instead of doing them myself, was of the utmost importance the more people I managed... especially, greenfield work. Literally: do not steal the fun. This also means inherently trusting people, and if you can't do that you shouldn't be working with them. two important notes about that:
1. If you just thought of someone you can't trust instead of thinking about how you can give more trust to people, you just had your ego stand in the way of mutual success. You are a shitty manager, and today is hopefully the first day of you recognizing that and learning to trust.
2. When people don't deliver what you expected, it's because you did a shitty job of communicating it to them. What seems obvious to you after 45 minutes in a meeting with three other people already prepared for the topic will most of the time seem obvious to no one else. If it does, I can almost promise, their vision of it is totally different than yours. Learning to work through the defining the problem (that includes asking "does this problem exist?") and then guiding solutions (we have x days, engineering hours, etc available) to ensure they meet the needs of the business. If no one but you delivers things correctly, you're a shitty manager, and today's hopefully the first day of you recognizing you need to learn to communicate and trust.
Not many people are lucky enough to be told so plainly it's their ego, but it's your ego that causes your team to fail. Maybe it's your boss's ego that's causing you to fail... I was told plainly to my face to not let my ego get in the way of the goal... and yeah it punched me in the gut too, so if you're hurting, or in denial know it's okay. We all have to grow, it's worth it.