Likewise, there probably isn't such a thing as a 10X developer, but I totally believe 10X managers exist (they provide cover, they have empathy, they are able to lead people who otherwise aren't very manageable). I've only met very few of them in my career, most managers are 1X or even negative.
What traits did you find in them. How do those traits convert with experience. Say, for example what would, according to you, make a 3-5 year experienced web developer 10x?
It's not magic; it's vast amounts of experience; writing more code than, and twisting brains in ways that, normal people can't even imagine; and sticking with it for decades. I have no idea if I'm 5x or 10x or whatever, what I do know is that it's extremely rare to come across people who are more dedicated to the craft and/or have invested more in their skills.
That's because management is one of those fields that most people think they're qualified for. If you got arms, legs and are literate, many think they're cut out for it.
Same goes for teaching or education in general. So many wannabe educators writing or producing programming lessons that clearly have never studied education theory. A notorious one or two out there as well. Art or professional grade creative endeavors are probably the same way for the vast majority.
Unless you're some sort of savant, no one gets away with shortcutting the learning involved with anything. It's just kind of blissful ignorance.
You don't know what you don't know and it becomes a strength since most are too unmotivated to ever do things the right way, in a well-informed, disciplined manner regardless. To those who are in those fields though, it's painfully obvious.
It seems obvious that coding and managing are different jobs, and being good at one is not associated with being good at the other.
Good software team management is a superset of coding skill. Not only does the manager need to have reasonable - not necessarily outstanding - developer skills, but also needs to have good people skills, good political skills, a feel for context and strategy, and an ability to improvise creative solutions across all these domains.
The idea that someone who is good at coding should be promoted to management automatically seems bizarre. It's like expecting someone who is good at mountain biking to be good at driving a tank.
So is the idea that management can be measured with "objective" metrics, such as locs, time on/off, bugs killed, and so on.
In fact it's horrifically difficult to quantify the business ROI of software teams or of individual developers. ROI often depends on decisions made higher up the food chain, and it's even harder to get upper management to take responsibility for the consequences of bad decisions and bad attitudes.
On the contrary: One of the long-standing problems in engineering, technology, and indeed many other businesses (from nursing to Nickelodeon) has been what to do, when the traditional career progression was seen to be "next, you are promoted into management", with the large number of people who did not want to go into management.
Lots of people have been considering themselves unsuitable for management for decades. This is a problem that people were talking about in the "systems" world back in the 1970s and 1980s, and that is neither the only area that it was a problem in nor the earliest time that it was mentioned. Have a snippet from the Journal of Systems Management from 1980:
> The systems professional who wants to remain within his job, i.e., does not care if he is promoted, is one who sees his main purpose as contributing to the profession. But many professionals and many organizations feel that one must get promoted to a management position, for if one does not want to be a manager he is not ambitious. This reflects itself in many organizations when the annual review time rolls round, or when one wants to change jobs.
If your company today has an organization structure where entering management is not the only promotion path, decades of mulling and lots of people not seeing themselves as management is the cause.
I agree with you that 10X managers exist, but it's utter nonsense to claim that 10X developers don't exist. I've met people who are possibly at the 100X level; it's worth remembering that some tasks cannot be done by an average developer with any amount of time.
I imagine that there are probably tasks that don't allow the 10X or 100X to show through; anything basic and repetitive enough (or so heavily specified that the developer's job is essentially "typing").
100X developers can straightforwardly - sometimes - find solutions to problems that are simple, elegant and fast. This often means that the things that they do are not only cleaner than the solutions produced by weak(er) engineers, but also require less complexity to implement them whether at the organizational level (e.g. because the task is being done by 1 person in 2 hours, rather than 4 people in 200+ person hours, there isn't any time spent on meetings) or at the technical level (e.g. because the task now runs better on a single computer, rather than a cluster or threaded machine, it no longer requires parallelization and a distributed system).
Sometimes this also comes about by a deep knowledge of available algorithms and systems, so while a naive programmer might start flailing around like a dog with their head stuck in a bucket, an experienced person might recognize the problem as an Integer Linear Programming case, etc.
There are plenty of cases where no-one is 100x, of course.
I really don't like the concept of a 10X developer - it implies linear scaling.
If you keep writing very similar implementations of very similar things (without actively damaging the code-base) you may very well be an O(n) developer. You keep working at the same pace regardless.
If you are a developer of some calibar, the work that you've already done will feed back into the work that you're doing - making you an O(log(n)) developer, until the work levels out and you slip back toward o(n).
Then there's the other end of the stick, the idiot who has no business writing code, but who management keeps around because he's cheap in the short term.
Everything he touches turn to shit, each change corrupts the code base just a little more, and each change to the corrupted code takes an amount of time proportional to the level of corruption.
This is the O(k^n) developer, and he needs to be stopped.
How do I know if I am an O(k^n) developer? My first "software engineer" job I did absolutely nothing but write update scripts, incredibly minute fixes to 10k+ line stored procedures and then helped watch deployments. I left that one for a new one, and I feel very slow compared to my coworker and I know that most of the time my designs for new features are extremely lacking. Should I leave my position since I fear I am impacting his ability to have high quality code?
In my experience the worst developers never ask if if they are doing things wrong and what that might be.
Look at the chages you're making to the code - are they of a quality comparable to what was already there, do they integrate cleanly, are you coding with a style that fits in with the surrounding code?
If not, what could you be doing better and why aren't you already doing it?
It may take longer in the short term, but give consideration to your development practices. Eventually you'll find yourself more quickly writing a higher quality of code that's more maintainable with fewer defects.
Agreed completely. I've had a manager who was able to really leverage persons to create whole new verticals (that were actually profitable), but they hinged on single person's continued interest and commitment. He was borderline psychopathic (in the sense of being extremely manipulative on a personal level), though, and while the work I've done has been the most interesting in my career, the atmosphere was emotionally draining on a very personal level for most of us who worked for him.
However, I'm not sure that there exist 10x managers that are not manipulators / psychological exploiters.
You don't just leave a bad manager. You escape! Emotionally it is deflating, defeating, a real grind that affects your whole life if your work situation sucks.
I've definitely left companies and not managers before. To be fair it's usually because my manager's manager's manager was an asshole who thought 1% and an attaboy would be enough to keep people when our rent had gone up 7% and neighboring companies we're offering 50% more. Also to be fair, my managers were good enough that I stayed 6 months longer than I would have with even a neutral manager
I left my first job because the company(Yahoo) was burning. My manager was great, I'd love to work for her again. I left a few months earlier than I needed to though, because her new manager was an asshole.
It's probably easier for managers to overrate their skills and performance because the problems they cause are often not overt; if parts of their team are underperforming, the knee-jerk assessment is that "there's something wrong with Joe" rather than "there's something wrong with our process" or "there's something wrong with what I'm doing."
Some of my worst experiences with management involved cases of serious micromanagement. I'd say if you're micromanaging, there's a 99.9 percent chance that you're a bozo and you don't belong in the position you're in even if you had initially earned it. You have trust issues with your employees and you've failed to build a team and environment that allows people to effectively manage themselves.
The best mangers I've known are the ones who are minimally involved. People who are given the space to make choices, be creative, and fail every so often, will often figure out how to manage themselves.
I'd argue that people usually leave both managers and companies because companies too often fail to recognize the broken patterns of managers. This is anecdotal, but I worked at one place where more than half of the development team(those with the most talent) quit within a span of 2 weeks, and somehow upper management decided it was not the fault of our tyrannical manager and instead replaced those positions with junior developers they could underpay and abuse. It's all the more insulting when you can point out the problems and provide actual solutions, and the aloof men in suits on Mount Olympus allow the problem to fester. I might have stayed for another year had they booted out our manager.
The fact that most people have stories of terrible management is astounding, and it doesn't say very much for whatever training managers receive(if any?).
The trust and minimal involvement are really key here, the best managers I've ever worked with have been enablers rather than taskmasters. Managers that remove roadblocks, provide you with exactly the tools you need, insulate you from unnecessary cross-chatter, and just let you kill it with as few distractions as possible.
Those sorts of enablers are how you not only maintain, but increase the output of your developers.
> The best mangers I've known are the ones who are minimally involved. People who are given the space to make choices, be creative, and fail every so often, will often figure out how to manage themselves.
In those cases, did you feel you shared values with those managers? Or were they indifferent to your values, and just left you alone?
I've experienced both kinds of low involvement, but I was definitely referring to cases where we shared values.
A case of indifference is still preferable to tyranny, though it obviously comes with its own set of problems. The biggest issue I have with uninvolved managers is the conflict between knowing what's expected versus the level of autonomy I should have. This problem is not isolated, of course. But an uninvolved manager may grant a lot of autonomy while failing to make it clear to their employees what sort of decisions they cannot male autonomously. As an employee, I will only ask so many questions before deciding the system is ridiculous and then overriding it. That's just my nature. If something is so important to a process, like communicating with a bunch of anonymous suits on Mount Olympus before a major release of one particular product, that information should be handed down to me. I shouldn't have to pry every detail out of management to get my job done, and occasionally they'll be punished when I make an arbitrary decision.
A good manager should be able to provide relevant information and facilitate the product process while staying out of the way. If they're always too busy attending meetings outside the team, then they'll reap what they sow and have no one to blame but themselves.
By the way, I do not make character judgments on most managers. Most of the people who've managed me are great people outside the office setting.
I'd agree that micromanaging is a bad sign. Too often I get micromanaging about style critiques like "turn this into one if statement instead of nested ones and it's more clear", but absolutely no comments on the meat of a significant refactor. To be clear, I think style rules are important, but this is the same guy who writes 150+ character lines with ternaries like they're going out of style.
You often have micromanagement and abandonment at the same time. They are so busy micromanagement their people while they neglect making the decisions that they need to make. If somebody steps up, they push back. Everybody avoids moving and are just waiting until the micromanager has time.
people who have natural leadership qualities can facilitate without thinking it harms their worth.
too often, unsuitable people will be thrust into a management/leadership type role just because there is a (sudden, genuine) void that needs feeling(sudden growth /sudden departure).
For self organizing teams, and teams with motivated people, servitude leadership style works really well. Ensure the teams goals and direction is clearly set, and just remove roadblocks as needed.
But there are other types of teams, and other situations where other styles are more effective.
There is an important distinction that hasn't been discussed much:
- The reason people decide to resign.
- The reason people begin to consider resigning.
In my experience, bad management is what usually kicks off the whole thought process, but other factors are what cement the decision (like an offer with higher pay, better title, higher prestige company etc.)
Last company I left went bankrupt and got bought by a VC who replaced the whole management.
The new managers were running around telling people how to do things because of the "company spirit".
A few people, including me, were in the company for over 7 years and we knew the company spirit, because well, we lived and formed it.
Now some newly hired MBAs try to tell me that I'm wrong?
The bankruptcy lead many people to leave. The rest left because of the new management. Now the company has the old name and product, but noone of the people that created or formed it remained.
Yes, that's a phenomenon I've experienced twice now. Great small company getting acquired by large company. Managers / execs of large company commence dismantling whatever made the small company efficient / competent.
I have some theories as to why this pattern occurs. Perhaps it's because the managers get paid a lot and feel the need to do something to prove they're worth it. Maybe managers are trying to cut costs, product be damned, to get bonuses. It could be because big companies typically have a lower grade of developers on average than small companies that are good enough to get acquired, and lower grade developers need to be babysat more. I dunno. It sucks though.
One of the issues I've had that isn't mentioned here is the value of mutual trust. Communication and trust are the two cornerstones of a really solid manager <-> managee relationship in my experience. Whether that lack of trust manifests itself as micro-management, constant check-ins, or a constant threat of surveillance it can easily turn an above average performer into an apathetic and demoralized employee.
I used to work remotely for a company that spanned more than a few timezones, with a wonderful daily team manager and a not-so-great weekly department manager. Learning that my minutes and output were constantly monitored completely destroyed my trust with the latter, and had me searching within the week. My reaction to that was so strong I actually considered it a fortune when I was laid off for unrelated reasons rather than having to quit.
I would be reprimanded for signing on five minutes later than usual despite being on a team of individuals that spanned multiple countries, and would get a questioning ping if I was offline for more than 10 minutes (especially problematic if you're the type of programmer to write or plan code on the whiteboard / paper first). Extremely draining to deal with that sort of nonsense and mistrust.
Please, managers of the world, trust your employees! You have performance metrics for a reason!
IME this kind of experience comes when you have a manager who has no fundamental understanding of what it is that they are managing and has no particular reason to trust you.
A manager who can monitor your output by reading your pull requests simply won't engage in this type of behavior whereas a manager who can't will usually instinctively gravitate to terrible metrics like "does he show dedication by being in at 9am rather than 9:05am"?
Managers should form a very deep understanding of whom to trust and why or understand on a very deep level what it is that they are managing.
Managers who cannot do either of those things should be terminated with prejudice.
>You have performance metrics for a reason!
As far as developing software goes, every single performance metric is terrible.
OK, I'll give an example. My team leader in a previous job used to regularly turn up at 11am (officially we were supposed to be in by 9.30, but it was academia and no one complained too much). I was usually in before 9.15 - like the majority of the staff.
So sometimes I would need to ask him something, and he wasn't around - that would hold me up.
Sometimes other people would need to ask him something. He wasn't around, so they asked me instead - usually when I was trying to get in the zone.
I am all for giving staff flexibility but it should not come at an expense to productivity.
Remote, timezone-distributed teams deal with this all the time. We always ensure everyone has a bunch of work they can do, and we use email/chat to handle the asynchronous communication issue. What you described isn't a scheduling issue, it's a communication issue. Not on your part, either, BTW.
In software engineering, many companies prioritise "getting your work done" (which is admittedly a subjective, hard-to-quantify metric) and consider any metric that contradicts it to be suspect.
A person who believes this would say that if according to policy my best employee should work 9am-5pm, but he prefers to work from 7am-3pm and is my best employee, it is the policy not the employee that needs changing.
Personally, I always try to get to the bottom of this stuff during job interviews - nobody wins if the employee assumes there will be flex-time and the company doesn't allow it!
This. I've literally never held a job that wasn't okay flex time, and I've worked at 4 radically different types of companies as a software engineer over the last 7 years.
I'll be honest, I was surprised to read this sorry if environment still existed for programmers
I think the criteria should be turn up on time when it matters. If there is a staff meeting scheduled at 9.30, don't show up at 9.45. Otherwise I agree that day to day most places shouldn't care
At one workplace, the manager instituted a daily all-hands meeting starting at 8:45 AM. But of course you still have flexible working hours; you just have to show up for this one meeting whose start time can't be changed because there definitely are reasons.
Yes, I was already interviewing at other places when that happened.
If you are in Germany, yes there is. I had horrendous experiences in different companies. 5 Mins late was a real offender.
Until I got hang of a manager and I asked what is this nonsense. He told me, he used to work as a manager in real industry and really really cannot comprehend why programmers "whine" so much about this. All his workers started the work at exact 8am so that the parts quota of the day would be achieved. I got no comment and after two weeks I just resigned...
Flex time shouldn't mean that you show up sometime between 8 and 11. You should be at work within some sort of reasonably consistent window barring unforeseen circumstances.
When you let people run wild, you end up with angry people anyway as gold-brickers will always take advantage of the system. Communications and accountability break down as you can never have all parties involved in a matter in the same place or same phone call at the same time. I've worked in places where people get wacky because the guy who supposedly works 6-2 really is around from 8-1.
I disagree. I trust my people. We all understand the idea that you get your work done. This gives them the flexibility to do what they need to do for their life. I have one guy that signs off a couple of hours a week during the fall to tend to his home/farm. I have another that takes time to make sure his girlfriend can make it to her Dr. appointment. These are also the people that I see working at midnight or such finishing things, because they realize at 8 p.m. they know how to fix something.
The key for us is communication. We make sure that each of us knows what the other is doing. Sure we have meetings every once in a while that we know we need to all meet, but for the most part we center our communication around ways to make sure that we can leave a message and they can get back to us when they can.
Showing up sometime between 8 and 11 is unreasonable, because it prevents people to come sooner then at 8. It should have been "sometime between 6 and 11" to be proper.
Also since people know the guy in your story is not working enough, it should be easy to check on him couple of times and then fire him.
Our practice is that you can pick your own consistent start time between 7-9. You can also do things like compress your week to 4 10 hour days or add an hour to get a day every two weeks. We don't want you in the office after 6 on anything approaching a regular basis. You can vary the time by day, which is common for childcare or other outside demands on your time.
If your habit is a 5 hour start window for an 8 hour workday, you're not going to work out.
At every company, my own managers have exorcised far more blatant use of flex time than I've ever needed. If I'd ever received any guff (which I haven't) for my own needs, they would have gotten a deserved ear-full.
>"getting your work done" (which is admittedly a subjective, hard-to-quantify metric)
Getting "work done" is fairly easy to recognize - you can tell when bugs are getting fixed and features are being delivered and when they are not.
Getting work done to a high standard and delivered at an appropriate speed is, I think, only recognizable by another developer who is as good or better than you.
>Personally, I always try to get to the bottom of this stuff during job interviews - nobody wins if the employee assumes there will be flex-time and the company doesn't allow it!
Yeah, that's one of my red flags during interviews. Companies that are strict on this type of stuff are essentially advertising the fact that management is clueless about what development does and rely upon intrinsically meaningless social cues to build trust. Like suits.
This seems like it would be subjective but it actually tells a story. Most likely tickets aren't being broken down enough, one employee could be snagging easy bug tickets in the morning and another employee could be working on a epic feature.
On the other side of things I have a guy at work who rocks out 20 tickets and a guy at work who tries to go into super plan mode and take his time and make sure every semicolon is perfect 20 times. This is ok, it's what management is for I need to make sure the fast guy is a little more careful sometimes and I need to check on mr planner and make sure he speeds it up sometimes.
Alice works with both of them, and knows that the one ticket Dave is working on requires a lot of refactoring work to solve it nicely.
Or knows that Bob is just that good. Or Dave's having a bad week because of X.
Direct superiors tend to have at least a vague idea of what is happening, along with a certain level of trust. These two make it less likely for the answer to your question to be as ambiguous. At least for ballpark estimates of whether one should be worried.
One time I got laid off for not closing enough stories. Meanwhile the guy that was kept on was the source of a lot of bugs. So what is that if you generate your own problems and "solve" them?
That's a different problem from the one Planning Poker addresses.
But to answer your question, the original story should have acceptance criteria such that the ticket can't be closed if there are bugs. Failing that, the bug ticket should be linked to the original ticket.
Continual feedback is also important. If the manager who laid you off valued velocity over bug-free code, that should have been communicated way earlier.
Metrics should always be supplemented with communication. If Dave's performance is under question, talk to him and find out his progress on the one ticket he's been working on.
EDIT: realized after posting that multiple people made this point. Just goes to show that it should be common sense.
>Is turning up on time for your job a terrible metric?
The worst metric.
That is, unless the "turning up on time" is actually causing a serious and recognizable problem. Then it's the problem that's a problem.
>As the initial commenter said: trust goes both ways.
No it doesn't. If you put the onus on the developer and say "not only do you have to deliver high quality code you have to make me trust that you've delivered high quality code by adhering to these arbitrary metrics I've come up which bear no intrinsic relationship to how you do your job" you're admitting incompetence as a manager.
It's a manager's job to know whom to trust and a manager that trusts the useless developer who turns up at 9am sharp over the excellent developer who turns up at 9:05am requires termination.
>Actually, turning up on time may not make your manager trust you more, but turning up late will definitely make them trust you less.
It will definitely make a bad manager trust you less.
A good manager will either recognize that you're delivering or not.
> A good manager will either recognize that you're delivering or not.
And a great manager will evaluate the wider effects of your behavior on the whole team and over a long timescale. If you being late to your job causes others to start doing the same, and if your manager cuts you slack because you are a "high performer" then social dynamics come into play that must be...well...managed! Performance also slips over time. People get spoiled, sometimes depressed, sometimes lazy.
Managers look at whole teams and long-term trends. Stop focusing on yourself and the immediate moment. Success is a marathon, not a sprint, and requires careful, regular progress.
> If you being late to your job causes others to start doing the same
You're missing the point entirely: Who cares if they're also late?
Short of them being late to something important like a meeting, it seriously couldn't matter less than any of the thousand other things you should focus on as a manager.
Unless you work in something with external time pressures (e.g. I used to work in equities and US market hours dictated our need to be available) there's no reason it should matter whether someone shows up at 9 or 9:45. If you're really worried about people missing each other, set core hours (11-3 say) where everyone's expected to be available.
>If you being late to your job causes others to start doing the same
If they also are producing and not causing other people problems then I see no problem.
However, if they are not producing then that is a problem. However, if they are coming in on time and not producing that is exactly the same problem.
The point is that one problem is unrelated to the other.
>social dynamics come into play
Social dynamics always come into play but in this instance, they really don't matter. If a manager knows how well everybody is performing and is communicating that then these other intra-team dynamics you are talking about simply don't happen.
It seems to me that you're coming at this from the perspective of a manager who fundamentally does not understand what they are managing and isn't cognizant of who is performing and obviously isn't communicating that because they don't know.
Because that's exactly when you would see the intra-team dynamics which you're describing will happen. That is what happens on most software teams, sadly :(
>Success is a marathon, not a sprint
I never said or implied that it was anything else.
>Stop focusing on yourself and the immediate moment.
I am focusing on neither.
I am beginning to suspect that you are exactly the kind of manager I'm talking about here. Hi.
That's kind of what I meant when I wrote "unless the "turning up on time" is actually causing a serious and recognizable problem. Then it's that problem that's a problem".
Yes, for IT support type roles I think measuring online availability as one aspect of job performance is legitimate.
There are lots of 'Professionals' who turn up on time, but turn theire head off while on the time, so you get nothing from mere body presence but billable hours.
The argument made is that being a "good employee" and following the rules is a signal to your employer that you're willing to make personal sacrifices to be dependable - the implication being that someone who follows the rules almost all the time is by necessity sacrificing some part of their personal interest.
It's just that, though - managers want dependability as much as they want competence, sometimes more so. This may or may not be good for the company depending on the company. If the leverage of each employee (in terms of their ability to affect the bottom line) is small, then dependability is far more important. If the leverage is high, then the employee's results dominate - the employee can come in whenever they want wearing whatever they want and say anything they want, as long as they make it rain.
Thank you for that. I think the takeaway for some of the other commentators here is that if you are getting flack for coming in late, it means you are not the type of employee who can really effect the bottom line.
That is not a judgement, not everyone can effect the bottom line and it is not guaranteed that everyone finds themselves in that position over the course of their career.
But, if you have a manager who keeps telling you what a big effect you're having (perhaps to justify a lower salary or discourage a move to a new role) but also gives you flack for coming in late, it should shine a light on the truth as to how they see your role.
> The argument made is that being a "good employee" [...] is a signal to your employer that you're willing to make personal sacrifices to be dependable
It would be nice if the employer was giving symmetric signal to be
a dependable party that will not throw you under the bus for a mildly
controversial statement nor lay off at first financial bump.
> Is turning up on time for your job a terrible metric?
Most devs are "round the clock" employees even though their job doesn't explicitly say so. If a serious production crisis happens at 3:00AM, all hands are on deck.
Only at dysfunctional companies. If you need round the clock coverage, you need to set up an on-call rotation. Expecting employees to be available 24/7 is completely unreasonable.
I wrote the parent post. Here are my reflections on the responses (which were insightful as always).
Regarding turning up on time and professionalism - For me the main component of professionalism isn't trust but respect.
Demanding an employee arrive by a certain time may or may not be a good way to run a business (up for discussion), but, once you as the employee have agreed to do so then consistently being late is a sign of disrespect. Part of how I would define professionalism is doing what you have agreed to do (or making a good faith attempt, even if not possible). If you still think it's unreasonable, consider if your employer paid you a couple of days late - is this still ok?
A lot of the comments mentioned what they consider to be attributes of a good manager, but only from their perspective as someone being managed. To me a bad manager would be someone who allows a centralization of knowledge in one person, so much so that that person can start to behave in a disrespectful manner (YMMV).
Some programmers have the attitude that they are indispensable and can behave anyway they like. There is a certain irony in the fact that we optimize/destroy other peoples jobs for a living but don't consider the possibility that it will end up happening to us - other professions are not as forgiving of some of the behaviours we might consider normal or fair.
Please let me know what you think (lessons on grammar also welcome).
What I'm reading here is that you're perceiving it (perhaps accurately, perhaps not) as a threat to one's dominance as manager.
I think you may be using the word respect as, say, a capo would - as in, "respect the chain of command" or as cartman would say "respect mah authoritah"!
If true, then that signals a certain level of insecurity over one's position which I think may be an unfortunate signal to send. As an employee I would see that as weakness, especially if combined with technical incompetence.
>If you still think it's unreasonable, consider if your employer paid you a couple of days late - is this still ok?
It's funny, an employer actually asked me that in my first job and I shrugged my shoulders and I said I probably wouldn't notice, which was an answer that clearly infuriated him.
He later fired me (a real blessing in disguise), and the last chunk of pay actually did come in about 4 days late - something I was keeping a close eye on because I was concerned he may not pay me at all. I am absolutely convinced it was him being spiteful - he did payroll himself and there was no other reason I could see for it being late.
I had a good chuckle over that one.
>Some programmers have the attitude that they are indispensable and can behave anyway they like.
Often it's because they are and they can. I mean, nobody's indispensable of course, but the nature of what they do means that they can create (or destroy) a lot of value and don't have much of a reason to fear termination. This tension between that and managerial refusal to recognize it because it signals a threat to their dominance has, I think, been the result of a lot of self destructive behavior in this industry. A lot of people would rather feel powerful than keep a healthy bottom line. Their prerogative, I suppose. It's good to recognize this and point it out when it happens though, because, for instance, as a shareholder I wouldn't want to be bullshitted about what went down.
I can certainly see how you could interpret my remarks on disrespect as "perceiving it (...) as a threat to one's dominance", but this was certainly not my intention.
My context is of never having had a 'bad' manager, they have always been agreeable and pleasant with a good technical understanding and (I can only assume) high self-esteem.
I think I have used the word respect in two slightly different ways: one when describing employer/employee relationship and one where describing manager/managed.
When I talk about disrespect in the context of a manager I mean it on more of an interpersonal relationship level, not as a struggle for dominance in some sort of power structure.
> "...As an employee I would see that as weakness, especially if combined with technical incompetence."
Adding the bit about "technical incompetence" sound to me like you are projecting certain other attributes on the hypothetical manager that we are discussing. What has been your experience with managers?
> "It's funny, an employer actually asked me that in my first job and I shrugged my shoulders and I said I probably wouldn't notice, which was an answer that clearly infuriated him."
When you have few bills to pay and/or other obligations then this attitude is fine, but I think for a large group of people (e.g. with families to support) this would be a real problem.
The point I was trying to make in the paragraph about "programmers acting any way they like" was that this may be an accept/successful strategy in the short term, but it may not be optimal long term. However indispensable you are now there is someone somewhere out there looking to optimize your job or make your skill set irrelevant. It's certainly possible that you are the exception and that no one will be able to do this to you, but I don't think that it applies to the majority of people reading this thread (I know it doesn't apply to me).
It seems like you view the employer/employee relationship in a very adversarial way, rather than an optimal way for both parties to get something they want. I have had jobs in the past (mainly part time service worker type jobs) where I feel that this attitude is valid. However, most companies I have worked for as a programmer have been small/medium level and started/funded by the same people (no VC money, no faceless career CEO or public shareholders). In these situations I have found that there is no calculated malice or attempt to 'enslave' you, just a few motivated people putting their own money and future on the line to try and make something of value and better themselves.
> "By his definition, you think programmers are "too free", no?"
No, I think a lot of programmers think that they are "too free", but are in-fact only "short term too free"
>When I talk about disrespect in the context of a manager I mean it on more of an interpersonal relationship level, not as a struggle for dominance in some sort of power structure.
Except the manager/employee relationship is fundamentally about dominance in a power structure so I don't see how you can separate the two.
Think about it this way: absent any kind of inconvenience (like an interrupted meeting), would a manager ever apologize to an employee for coming in at 9:05am?
If the answer is yes, this may be about mutual respect. Since the answer is no, this is intrinsically about respecting the chain of command.
>Adding the bit about "technical incompetence" sound to me like you are projecting certain other attributes on the hypothetical manager that we are discussing. What has been your experience with managers?
Yes, I am. Because, in my experience, there has always been a strong correlation between one attribute and the other. As in, mild technical competence usually means that they care, but not hugely and deep technical incompetence means they end up caring a ton.
>When you have few bills to pay and/or other obligations then this attitude is fine
I'm aware others can not afford this attitude because they are up against the wall with credit card debt, mortgages and kids and whatnot but as far as I see it the point you and my previous boss were making was a rhetorical one. Point being that it doesn't work as a rhetorical question because I really didn't mind.
I think there may have been some sort of implied threat there - i.e. "you fulfill your end of the bargain by coming in before 9:05am and I'll fulfill mine by not paying you a day late". And I was like, ok, pay me a day late then.
>The point I was trying to make in the paragraph about "programmers acting any way they like" was that this may be an accept/successful strategy in the short term, but it may not be optimal long term. However indispensable you are now there is someone somewhere out there looking to optimize your job or make your skill set irrelevant.
Ok, so now you've branched on to a different topic. I agree that this is the case, but they will keep trying to do that however servile you act and behaving like a slave isn't going to stop it from happening. While they are trying to optimize your job and make your skill set irrelevant, you should instead be trying to optimize your performance and make your skill set more and more relevant while maintaining a healthy savings buffer that protects against unemployment.
As far as I can tell the biggest threats are actually directed at those with the least relative power.
>It seems like you view the employer/employee relationship in a very adversarial way
Yes. The largest military uprising in the United States since the civil war (battle of blair mountain) was fundamentally an employee/employer conflict. The relationship is a naturally adversarial and naturally parasitic. That doesn't mean it has to be all about that in every instance, but that is still its natural tendency.
>I have had jobs in the past (mainly part time service worker type jobs) where I feel that this attitude is valid. However, most companies I have worked for as a programmer have been small/medium level and started/funded by the same people (no VC money, no faceless career CEO or public shareholders). In these situations I have found that there is no calculated malice or attempt to 'enslave' you
I think that is in and of itself an artefact of the difference in power disparity. As a programmer you had more power so they didn't feel like they could fuck with you with impunity. As a part time service worker they could so they did.
I think some of those nice people you worked with might have changed their tune had they seen your relative power slipping. I have definitely seen this happen.
An old co-worker of mine used to work for a company that made flight simulators. He said his manager would stand in the front foyer on the 2nd floor and make notes of who arrived after 9:00am.
I would have fun trolling such a boss. When I was younger, I would stress about job security; work OT whenever asked, say yes to every request, etc.
Now that I'm in my late 30s... I'm finding I have more self-confidence than I've ever had in my life. Couple that with a general sense of professional ennui that's been steadily building over the last few years, and you get someone who just doesn't care if you fire him and acts accordingly.
This is very true in india. Almost most of the managers go in to management because they can't code and to evalulate an employee they take every metric other than looking in to the commits.
But also for teams to be successful, employees have to be able to trust their managers. I just quit a job after a month because, within that short time, my manager twice misrepresented the scope of a task so he could either leave early or have the day off.
I knew after those incidents that there was no point in continuing. It would be foolish to trust someone in any larger way who would casually treat a new employee in that fashion.
I have only ever left good managers. I've had bad managers, but it was only under good managers that I was fully enabled to do my best work - work that would give me the confidence (and the resume fodder) to pitch myself to a new company for better pay.
That may seem disloyal to those good managers, but I never left on a whim. It was always an agonizing process. But it was also always necessary. My former managers have never held it against me, and I now have connections with a number of great managers who would hire me without question if I was ever looking again (and they know I would work for them in a heartbeat).
What always happened was that it became evident that my interests and my company's interest had diverged, whether it was a lack of opportunity for advancement, the company was going under, the product was a non-starter, or upper-management was bent on self-sabotage.
At my previous job, I left due to the company, not the management.
My direct supervisor was great. He was a good manager on most levels.
I left because the company had no future, they weren't going bankrupt, but they weren't growing either. I never got a pay rise, probably never would. My benefits actually shrunk as time went on, staff social functions were cut (e.g. team lunches), use of networking funds became more restricted, and my work environment became less flexible.
In fact, the only reason I considered staying was my manager and coworkers.
People leave poor working environments, whether it's a company or a manager causing that poor environment.
Yea, its too easy to say people leave managers, but it was never in my case. I think it varies between industry. With the software companies, the churn is mostly due to folks looking out for better opportunities..
Me personally almost always looked outside due to availability of better opportunities. The argument that people leave managers makes sense only if you are in the best possible job/company you can get with your skill set (which is a very small %) and you somehow got a rift with the manager big enough to leave.
But it could be different in other domains/industries where people stick with the same company till their retirement..
As somberi commented awhile ago, people leave due to managers -> company -> cause, in roughly that order. So even good managers will lose people if the company has traction issues or the cause is unclear or there is no future. So it absolutely can happen and it is fair to say that a single manager's performance, in isolation, is not the only reason for retention.
I have been managing large teams (Anywhere from 100 to 300 people) and in my experience I would phrase it differently.
1. In a going concern, which has found traction, a manager is often the _reason_ for people to leave the company.
2. In a company that is not finding traction, or the larger view of its direction is obfuscated, managers are the reason people _stay_ back to work.
This manager being the end-all of association comes from military knowledge that you fight because of allegiance to your battalion, cause and the country - in that order.
In an knowledge enterprise, these constructs exist, but with almost equal weightage.
The best manager cannot make an employee stay back if the company is not going anywhere, or if the cause is not evident.
The worst manager will lose employees even if the company is going bonkers.
Totally agree. If the company has enough traction and I have a decent shares/options package with a clear exit strategy in sight then I'd stay even if my boss was a wild baboon and my job mostly involved shoveling monkey shit.
If you're a manager in a high traction company and you're losing employees regularly, you should seriously consider finding another career.
I didn't interpret their comment that way. It's common to have a handful of managers under you, but reference to their reports as your managees as well. That easily reaches 100-200 people.
I think it's the "large teams" bit that makes the OP appear to be saying the "team" is up to 300 people. Team suggests a group of equally ranked members to me.
You can't really have a team of 300, sounds more like a management speak version of team.
Of course only the poster knows for sure their intended meaning.
flat hierarchies are amazing in certain type of companies, I had one line manager who had additional 80 devs under him (he was purely line manager, projects were handled by PMs).
Much better and healthy org than any other I ever worked for. Especially over-layered corporations, ie banks are pretty horrible place to be. This breeds all kinds of politics, managers play their games to look good to upper management without any good work being done etc.
But if this would be some classic department where line+project management blends into 1 hierarchy, this would be too much. Smaller teams, max +-10 people most efficient.
This is a really insightful comment. I came here to say I'm the counter-example to the article, in that I left a pretty good manager at a company that was clearly failing.
This article feels like one of these things where someone's trying to fit something messy and human into a simple, clean narrative.
There's a lot of talk about full stack developers lately, I'm still waiting to find the first full stack manager. Someone who's visionary, yet realistic; confident, yet empathic; powerful, yet humble. I feel like there's some truth to the saying that the best leaders are those who don't consider themselves fit to lead.
I've seen a variety of managers doing bad jobs, and it never makes me think I could do it better. It makes me think about managerial problems, and how they are inherently difficult because of conflicts of interest.
On the other hand, I got tired of technical problems, because the real problems always seemed to be managerial where I worked.
The manager is your interface to management. It's their job to tell you what you need to know and what to do. To an employee, they're the face of the business.
But at the end of the day, if it's the people that make up a business, then I'd question if they are not the same thing.
I asked a new acquaintance of mine about something bothering me.
I asked him, "so, how often do you fire people? How do find the right people for your businesses?"
"I hardly ever have to fire anyone," he said. "I ask them questions, and they leave."
Damn.
And the thing is, this pressure isn't faked or manufactured. This isn't anyone trying to fire someone. This is just someone needing work done, and answers.
No business wants anyone incompetent, yet, it happens, because of interviewees lying through their teeth and not knowing any better.
So they walk in and fail to do the exact job they won for themselves, then come the questions.
Now they lose their place and have to leave, knowing they got the job by accident.
There is plenty of real pressure to go around in a real business, and we avoid managerial roles because we know the stakes are higher. We know that having a manager is "safer" than being one, because having a manager is having someone responsible for you, and for your well being. It's how America figured out how to hire from the abundant talent pool of those who can't handle tough responsibilities and stay happy on their own, and those who'd rather have it easier. It's the luxury of being managed.
But above that, it gets even worse. Fewer luxuries, just higher pay. Just think of all the bullets the CEO has to catch with their teeth every day. And wen they fail, it's news.
Being a manager is about being loyal to the company and not individuals. It pays more precisely because it causes pain to peoples' consciences to put an abstraction above fellow employees.
Talking about a CEO catching bullets in their teeth is ridiculously inflated language. Why use such imagery? Because the mission of a typical company does not sufficiently compensate for the guilt produced by putting the organization ahead of individuals.
I usually think of the managerial responsibilities to be in this order:
- Company, because without it there's no employees
- The team you're managing, because teams are more than just a single person
- The individuals in the team, since they're the one's that can make a team better
It seriously sucks to have to think of things in that order sometimes. I've never been involved in firing a person I didn't like.
Though, when it comes down to it it's not fair for the team to suffer because of an individual, no matter how much they are liked, and it's not fair for all of the teams to suffer because one of them can't cut it.
That's not to say there's no wiggle room though. I'll fight tooth and nail for an employee or team if I think it's a management fault that they've not performed (especially if I'm the manager screwing up) and will try to take a long term view of their value, not just the next quarter.
Of course, all of this could be making me a bad manager. I've been put into managing people by virtue of being technically strong, not being a great people herder. I really do wish companies would spend as much time mentoring and helping managers get better at hands on managing as they do other tasks.
I don't see why you disagree. Beyond asserting that my statement isn't true, you seem to be merely paraphrasing what I wrote in a more euphemistic way.
My former boss was laid off because he didn't "correctly" handle the conflict we're talking about. I think we're in agreement about what correctly means - being loyal to the company, or people who have power over you, rather than your subordinates.
Putting the organization ahead of individuals isn't what's happening. The individuals ARE the organization.
So if you put yourself ahead of the organization, you're putting everyone else behind you, including your boss. This is a challenge for millennials especially, who are used to always being put first, and having their emotions managed.
A good manager doesn't put themselves before their boss or anyone else. How often do you hear of programmers who enter management to hardly touch code again? A good manager puts the organization first, both above and below their pay grade.
But their performance also depends on the people they manage. If a worker is incompetent, they have every right to be hard on those mistakes. And the worker is fully responsible for setting things right. Work is not homework that gets handed back to you after its graded. It's something needed by someone else that needs it for something important. And nothing is redundant in a tightly run business.
When I think of Melissa Mayers, I think of bullets. Despite whether anyone agrees with "her" moves (which were clearly backed by her counsel), she was doing everything she could to increase market share and rebuild a failing business. She took on all the risk, and becomes target practice for those who despise her failures. When was the last time you were bashed on HN? And she does this so that everyone at Yahoo has a job. She is fighting for YOU.
Regardless of my word choice, to borrow your words, the CEO is a ridiculously inflated position.
You assert that "a good manager puts the organization first", but first does not mean "ahead of individuals". So what is it ahead of, if not individual interests?
Tellingly, when I interviewed with Intercom their "culture fit" manager was extremely rude and condescending, and constantly interrupted. Everyone else was polite, but if this is the person who gets to decide "yeah, they'd fit in here" that's a pretty huge problem.
People turn you down because of managers, not companies, too.
Intercom does a fantastic job with content marketing. I'm not sure how much it reflects reality, though. Again, most of the people I talked to were polite; it was just one extremely off-putting interviewer. I nearly thought it must be some kind of perverse test to see how I handle jerks.
People leave the environment, not just the manager, though the manager is a big piece of the puzzle.
I quit my last employer because the manager was an abusive bully with severe trust issues who would constantly threaten, abuse and demoralize people, but HR was also to blame since they did not lift a finger to address the issue even though this manager's behavior was widely known throughout the company for decades.
I've also left a great manager in the past since the business was going nowhere. I've left a good manager and good team because I was very underpaid in another company.
#1. People get hired for what they are good, their skills and then get promoted (to management) for same technical/IC skills not for the MGMT skills. No MGMT ramp-up. No MGMT tools. No MGMT framework. You are now tasked to lead a team. it's surely will fail.
#2. Next the mindset. Typical mindset when you move from technical (or any IC) role to MGMT and the higher you go in MGMT should completely change.... unfortunately its not so easy to give up the control. MGMT is about making others successful... giving up your control to others is very frightening and often causes identity issues... moving from do it all (as an IC) to ask_and_inspire is not easy...
#3. Assuming you overcome these two... typical problem of MGMT/leadership is they try to find, "What's the matter?" where as the focus should always be on "What matters to you (an individual/ICs in team)"
I'm the blog author, Rich Archbold from Intercom. Just to clarify …
I wrote this blog, with the exaggerated / cliched title, to try to speak to the large cohort of over-confident, under-skilled and often lacking-enough-self-awareness, managers out there. I was (and often still am) a member of this cohort. Being a great manager all the time is really hard and almost impossible IMHO.
The goal was to hopefully try and generate some more self-awareness and introspection and thus make life a little fairer, more pleasant, more growth-oriented and hopefully more successful for all concerned.
I wasn't trying to deny or downplay that people also leave their jobs for all of the other reasons highlighted by folks here.
#1. People get hired for what they are good, their skills and then get promoted (to management) for same technical/IC skills not for the MGMT skills. No MGMT ramp-up. No MGMT tools. No MGMT framework. You are now tasked to lead a team. it's surely will fail.
#2. Next the mindset. Typical mindset when you move from technical (or any IC) role to MGMT and the higher you go in MGMT should completely change.... unfortunately its not so easy to give up the control. MGMT is about making others successful... giving up your control to others is very frightening and often causes identity issues... moving from do it all (as an IC) to ask_and_inspire is not easy...
#3. Assuming you overcome these two... typical problem of MGMT/leadership is they try to find, "What's the matter?" where as the focus should always be on "What matters to you (an individual/ICs in team)"
I can't help feeling that sometimes saying "People leave managers, not companies" is something senior company management tell themselves to absolve themselves of blame for staff turnover.
I could be managed by the best manager in the world, but if I'm paid 20% below market rate I'm going to leave for a better paid job.
185 comments
[ 5.5 ms ] story [ 228 ms ] threadAlso many people are not even able to finish more complex projects. I am just not sure if they are 1X developers or 0.1X developers.
Same goes for teaching or education in general. So many wannabe educators writing or producing programming lessons that clearly have never studied education theory. A notorious one or two out there as well. Art or professional grade creative endeavors are probably the same way for the vast majority.
Unless you're some sort of savant, no one gets away with shortcutting the learning involved with anything. It's just kind of blissful ignorance.
You don't know what you don't know and it becomes a strength since most are too unmotivated to ever do things the right way, in a well-informed, disciplined manner regardless. To those who are in those fields though, it's painfully obvious.
I am totally happy leaving that job to someone who is better suited for it.
However, it seems plausible to me that of the people who think they are qualified to be a manager, most are not.
Good software team management is a superset of coding skill. Not only does the manager need to have reasonable - not necessarily outstanding - developer skills, but also needs to have good people skills, good political skills, a feel for context and strategy, and an ability to improvise creative solutions across all these domains.
The idea that someone who is good at coding should be promoted to management automatically seems bizarre. It's like expecting someone who is good at mountain biking to be good at driving a tank.
So is the idea that management can be measured with "objective" metrics, such as locs, time on/off, bugs killed, and so on.
In fact it's horrifically difficult to quantify the business ROI of software teams or of individual developers. ROI often depends on decisions made higher up the food chain, and it's even harder to get upper management to take responsibility for the consequences of bad decisions and bad attitudes.
Lots of people have been considering themselves unsuitable for management for decades. This is a problem that people were talking about in the "systems" world back in the 1970s and 1980s, and that is neither the only area that it was a problem in nor the earliest time that it was mentioned. Have a snippet from the Journal of Systems Management from 1980:
> The systems professional who wants to remain within his job, i.e., does not care if he is promoted, is one who sees his main purpose as contributing to the profession. But many professionals and many organizations feel that one must get promoted to a management position, for if one does not want to be a manager he is not ambitious. This reflects itself in many organizations when the annual review time rolls round, or when one wants to change jobs.
If your company today has an organization structure where entering management is not the only promotion path, decades of mulling and lots of people not seeing themselves as management is the cause.
I imagine that there are probably tasks that don't allow the 10X or 100X to show through; anything basic and repetitive enough (or so heavily specified that the developer's job is essentially "typing").
Sometimes this also comes about by a deep knowledge of available algorithms and systems, so while a naive programmer might start flailing around like a dog with their head stuck in a bucket, an experienced person might recognize the problem as an Integer Linear Programming case, etc.
There are plenty of cases where no-one is 100x, of course.
If you keep writing very similar implementations of very similar things (without actively damaging the code-base) you may very well be an O(n) developer. You keep working at the same pace regardless.
If you are a developer of some calibar, the work that you've already done will feed back into the work that you're doing - making you an O(log(n)) developer, until the work levels out and you slip back toward o(n).
Then there's the other end of the stick, the idiot who has no business writing code, but who management keeps around because he's cheap in the short term. Everything he touches turn to shit, each change corrupts the code base just a little more, and each change to the corrupted code takes an amount of time proportional to the level of corruption. This is the O(k^n) developer, and he needs to be stopped.
Look at the chages you're making to the code - are they of a quality comparable to what was already there, do they integrate cleanly, are you coding with a style that fits in with the surrounding code?
If not, what could you be doing better and why aren't you already doing it? It may take longer in the short term, but give consideration to your development practices. Eventually you'll find yourself more quickly writing a higher quality of code that's more maintainable with fewer defects.
> Everything he touches turn to shit
> he needs to be stopped.
You'll never take me alive.
However, I'm not sure that there exist 10x managers that are not manipulators / psychological exploiters.
Some of my worst experiences with management involved cases of serious micromanagement. I'd say if you're micromanaging, there's a 99.9 percent chance that you're a bozo and you don't belong in the position you're in even if you had initially earned it. You have trust issues with your employees and you've failed to build a team and environment that allows people to effectively manage themselves.
The best mangers I've known are the ones who are minimally involved. People who are given the space to make choices, be creative, and fail every so often, will often figure out how to manage themselves.
I'd argue that people usually leave both managers and companies because companies too often fail to recognize the broken patterns of managers. This is anecdotal, but I worked at one place where more than half of the development team(those with the most talent) quit within a span of 2 weeks, and somehow upper management decided it was not the fault of our tyrannical manager and instead replaced those positions with junior developers they could underpay and abuse. It's all the more insulting when you can point out the problems and provide actual solutions, and the aloof men in suits on Mount Olympus allow the problem to fester. I might have stayed for another year had they booted out our manager.
The fact that most people have stories of terrible management is astounding, and it doesn't say very much for whatever training managers receive(if any?).
Those sorts of enablers are how you not only maintain, but increase the output of your developers.
In those cases, did you feel you shared values with those managers? Or were they indifferent to your values, and just left you alone?
A case of indifference is still preferable to tyranny, though it obviously comes with its own set of problems. The biggest issue I have with uninvolved managers is the conflict between knowing what's expected versus the level of autonomy I should have. This problem is not isolated, of course. But an uninvolved manager may grant a lot of autonomy while failing to make it clear to their employees what sort of decisions they cannot male autonomously. As an employee, I will only ask so many questions before deciding the system is ridiculous and then overriding it. That's just my nature. If something is so important to a process, like communicating with a bunch of anonymous suits on Mount Olympus before a major release of one particular product, that information should be handed down to me. I shouldn't have to pry every detail out of management to get my job done, and occasionally they'll be punished when I make an arbitrary decision.
A good manager should be able to provide relevant information and facilitate the product process while staying out of the way. If they're always too busy attending meetings outside the team, then they'll reap what they sow and have no one to blame but themselves.
By the way, I do not make character judgments on most managers. Most of the people who've managed me are great people outside the office setting.
people who have natural leadership qualities can facilitate without thinking it harms their worth. too often, unsuitable people will be thrust into a management/leadership type role just because there is a (sudden, genuine) void that needs feeling(sudden growth /sudden departure).
But there are other types of teams, and other situations where other styles are more effective.
- The reason people decide to resign.
- The reason people begin to consider resigning.
In my experience, bad management is what usually kicks off the whole thought process, but other factors are what cement the decision (like an offer with higher pay, better title, higher prestige company etc.)
Last company I left went bankrupt and got bought by a VC who replaced the whole management.
The new managers were running around telling people how to do things because of the "company spirit".
A few people, including me, were in the company for over 7 years and we knew the company spirit, because well, we lived and formed it.
Now some newly hired MBAs try to tell me that I'm wrong?
The bankruptcy lead many people to leave. The rest left because of the new management. Now the company has the old name and product, but noone of the people that created or formed it remained.
I have some theories as to why this pattern occurs. Perhaps it's because the managers get paid a lot and feel the need to do something to prove they're worth it. Maybe managers are trying to cut costs, product be damned, to get bonuses. It could be because big companies typically have a lower grade of developers on average than small companies that are good enough to get acquired, and lower grade developers need to be babysat more. I dunno. It sucks though.
That's probably by design.
Just because people do things intentionally doesn't make it any better...
I used to work remotely for a company that spanned more than a few timezones, with a wonderful daily team manager and a not-so-great weekly department manager. Learning that my minutes and output were constantly monitored completely destroyed my trust with the latter, and had me searching within the week. My reaction to that was so strong I actually considered it a fortune when I was laid off for unrelated reasons rather than having to quit.
I would be reprimanded for signing on five minutes later than usual despite being on a team of individuals that spanned multiple countries, and would get a questioning ping if I was offline for more than 10 minutes (especially problematic if you're the type of programmer to write or plan code on the whiteboard / paper first). Extremely draining to deal with that sort of nonsense and mistrust.
Please, managers of the world, trust your employees! You have performance metrics for a reason!
A manager who can monitor your output by reading your pull requests simply won't engage in this type of behavior whereas a manager who can't will usually instinctively gravitate to terrible metrics like "does he show dedication by being in at 9am rather than 9:05am"?
Managers should form a very deep understanding of whom to trust and why or understand on a very deep level what it is that they are managing.
Managers who cannot do either of those things should be terminated with prejudice.
>You have performance metrics for a reason!
As far as developing software goes, every single performance metric is terrible.
To me being on time is just a very basic low level requirement of being a professional.
As the initial commenter said: trust goes both ways. Turning up on time is a good way to show your manager that you can be trusted.
Edit: Actually, turning up on time may not make your manager trust you more, but turning up late will definitely make them trust you less.
What is on time? On time for what exactly?
Is he missing any meetings? Is he working fewer hours? Is he doing less work? Is he impacting a colleague?
Why do you consider something that has no relationship to the posters job to be a basic requirement to being a professional?
So sometimes I would need to ask him something, and he wasn't around - that would hold me up. Sometimes other people would need to ask him something. He wasn't around, so they asked me instead - usually when I was trying to get in the zone.
I am all for giving staff flexibility but it should not come at an expense to productivity.
A person who believes this would say that if according to policy my best employee should work 9am-5pm, but he prefers to work from 7am-3pm and is my best employee, it is the policy not the employee that needs changing.
Personally, I always try to get to the bottom of this stuff during job interviews - nobody wins if the employee assumes there will be flex-time and the company doesn't allow it!
I'll be honest, I was surprised to read this sorry if environment still existed for programmers
Yes, I was already interviewing at other places when that happened.
Until I got hang of a manager and I asked what is this nonsense. He told me, he used to work as a manager in real industry and really really cannot comprehend why programmers "whine" so much about this. All his workers started the work at exact 8am so that the parts quota of the day would be achieved. I got no comment and after two weeks I just resigned...
now tends to only exist in mismanaged large teams
When you let people run wild, you end up with angry people anyway as gold-brickers will always take advantage of the system. Communications and accountability break down as you can never have all parties involved in a matter in the same place or same phone call at the same time. I've worked in places where people get wacky because the guy who supposedly works 6-2 really is around from 8-1.
The key for us is communication. We make sure that each of us knows what the other is doing. Sure we have meetings every once in a while that we know we need to all meet, but for the most part we center our communication around ways to make sure that we can leave a message and they can get back to us when they can.
Also since people know the guy in your story is not working enough, it should be easy to check on him couple of times and then fire him.
If your habit is a 5 hour start window for an 8 hour workday, you're not going to work out.
Getting "work done" is fairly easy to recognize - you can tell when bugs are getting fixed and features are being delivered and when they are not.
Getting work done to a high standard and delivered at an appropriate speed is, I think, only recognizable by another developer who is as good or better than you.
>Personally, I always try to get to the bottom of this stuff during job interviews - nobody wins if the employee assumes there will be flex-time and the company doesn't allow it!
Yeah, that's one of my red flags during interviews. Companies that are strict on this type of stuff are essentially advertising the fact that management is clueless about what development does and rely upon intrinsically meaningless social cues to build trust. Like suits.
Bob closed 20 tickets this week, and Dave is still working on that one ticket from last week. Who got most work done this week?
On the other side of things I have a guy at work who rocks out 20 tickets and a guy at work who tries to go into super plan mode and take his time and make sure every semicolon is perfect 20 times. This is ok, it's what management is for I need to make sure the fast guy is a little more careful sometimes and I need to check on mr planner and make sure he speeds it up sometimes.
Or knows that Bob is just that good. Or Dave's having a bad week because of X.
Direct superiors tend to have at least a vague idea of what is happening, along with a certain level of trust. These two make it less likely for the answer to your question to be as ambiguous. At least for ballpark estimates of whether one should be worried.
To be clear, though, "Who got most work done this week?" is not a useful question.
But to answer your question, the original story should have acceptance criteria such that the ticket can't be closed if there are bugs. Failing that, the bug ticket should be linked to the original ticket.
Continual feedback is also important. If the manager who laid you off valued velocity over bug-free code, that should have been communicated way earlier.
You get an equally or more skilled developer than Bob and Dave to monitor their output and ask them that question. That's the only way.
Was that not obvious from my answer? C'mon.
EDIT: realized after posting that multiple people made this point. Just goes to show that it should be common sense.
The worst metric.
That is, unless the "turning up on time" is actually causing a serious and recognizable problem. Then it's the problem that's a problem.
>As the initial commenter said: trust goes both ways.
No it doesn't. If you put the onus on the developer and say "not only do you have to deliver high quality code you have to make me trust that you've delivered high quality code by adhering to these arbitrary metrics I've come up which bear no intrinsic relationship to how you do your job" you're admitting incompetence as a manager.
It's a manager's job to know whom to trust and a manager that trusts the useless developer who turns up at 9am sharp over the excellent developer who turns up at 9:05am requires termination.
>Actually, turning up on time may not make your manager trust you more, but turning up late will definitely make them trust you less.
It will definitely make a bad manager trust you less.
A good manager will either recognize that you're delivering or not.
And a great manager will evaluate the wider effects of your behavior on the whole team and over a long timescale. If you being late to your job causes others to start doing the same, and if your manager cuts you slack because you are a "high performer" then social dynamics come into play that must be...well...managed! Performance also slips over time. People get spoiled, sometimes depressed, sometimes lazy.
Managers look at whole teams and long-term trends. Stop focusing on yourself and the immediate moment. Success is a marathon, not a sprint, and requires careful, regular progress.
You're missing the point entirely: Who cares if they're also late?
Short of them being late to something important like a meeting, it seriously couldn't matter less than any of the thousand other things you should focus on as a manager.
Unless you work in something with external time pressures (e.g. I used to work in equities and US market hours dictated our need to be available) there's no reason it should matter whether someone shows up at 9 or 9:45. If you're really worried about people missing each other, set core hours (11-3 say) where everyone's expected to be available.
If they also are producing and not causing other people problems then I see no problem.
However, if they are not producing then that is a problem. However, if they are coming in on time and not producing that is exactly the same problem.
The point is that one problem is unrelated to the other.
>social dynamics come into play
Social dynamics always come into play but in this instance, they really don't matter. If a manager knows how well everybody is performing and is communicating that then these other intra-team dynamics you are talking about simply don't happen.
It seems to me that you're coming at this from the perspective of a manager who fundamentally does not understand what they are managing and isn't cognizant of who is performing and obviously isn't communicating that because they don't know.
Because that's exactly when you would see the intra-team dynamics which you're describing will happen. That is what happens on most software teams, sadly :(
>Success is a marathon, not a sprint
I never said or implied that it was anything else.
>Stop focusing on yourself and the immediate moment.
I am focusing on neither.
I am beginning to suspect that you are exactly the kind of manager I'm talking about here. Hi.
> The worst metric.
Not really. If your job is to be available to others (IT support is a good example), turning up on time is an adequate metric.
Yes, for IT support type roles I think measuring online availability as one aspect of job performance is legitimate.
While manager slept.
https://medium.com/incerto/how-to-legally-own-another-person...
The argument made is that being a "good employee" and following the rules is a signal to your employer that you're willing to make personal sacrifices to be dependable - the implication being that someone who follows the rules almost all the time is by necessity sacrificing some part of their personal interest.
It's just that, though - managers want dependability as much as they want competence, sometimes more so. This may or may not be good for the company depending on the company. If the leverage of each employee (in terms of their ability to affect the bottom line) is small, then dependability is far more important. If the leverage is high, then the employee's results dominate - the employee can come in whenever they want wearing whatever they want and say anything they want, as long as they make it rain.
That is not a judgement, not everyone can effect the bottom line and it is not guaranteed that everyone finds themselves in that position over the course of their career.
But, if you have a manager who keeps telling you what a big effect you're having (perhaps to justify a lower salary or discourage a move to a new role) but also gives you flack for coming in late, it should shine a light on the truth as to how they see your role.
It would be nice if the employer was giving symmetric signal to be a dependable party that will not throw you under the bus for a mildly controversial statement nor lay off at first financial bump.
Most devs are "round the clock" employees even though their job doesn't explicitly say so. If a serious production crisis happens at 3:00AM, all hands are on deck.
Regarding turning up on time and professionalism - For me the main component of professionalism isn't trust but respect.
Demanding an employee arrive by a certain time may or may not be a good way to run a business (up for discussion), but, once you as the employee have agreed to do so then consistently being late is a sign of disrespect. Part of how I would define professionalism is doing what you have agreed to do (or making a good faith attempt, even if not possible). If you still think it's unreasonable, consider if your employer paid you a couple of days late - is this still ok?
A lot of the comments mentioned what they consider to be attributes of a good manager, but only from their perspective as someone being managed. To me a bad manager would be someone who allows a centralization of knowledge in one person, so much so that that person can start to behave in a disrespectful manner (YMMV).
Some programmers have the attitude that they are indispensable and can behave anyway they like. There is a certain irony in the fact that we optimize/destroy other peoples jobs for a living but don't consider the possibility that it will end up happening to us - other professions are not as forgiving of some of the behaviours we might consider normal or fair.
Please let me know what you think (lessons on grammar also welcome).
What I'm reading here is that you're perceiving it (perhaps accurately, perhaps not) as a threat to one's dominance as manager.
I think you may be using the word respect as, say, a capo would - as in, "respect the chain of command" or as cartman would say "respect mah authoritah"!
If true, then that signals a certain level of insecurity over one's position which I think may be an unfortunate signal to send. As an employee I would see that as weakness, especially if combined with technical incompetence.
>If you still think it's unreasonable, consider if your employer paid you a couple of days late - is this still ok?
It's funny, an employer actually asked me that in my first job and I shrugged my shoulders and I said I probably wouldn't notice, which was an answer that clearly infuriated him.
He later fired me (a real blessing in disguise), and the last chunk of pay actually did come in about 4 days late - something I was keeping a close eye on because I was concerned he may not pay me at all. I am absolutely convinced it was him being spiteful - he did payroll himself and there was no other reason I could see for it being late.
I had a good chuckle over that one.
>Some programmers have the attitude that they are indispensable and can behave anyway they like.
Often it's because they are and they can. I mean, nobody's indispensable of course, but the nature of what they do means that they can create (or destroy) a lot of value and don't have much of a reason to fear termination. This tension between that and managerial refusal to recognize it because it signals a threat to their dominance has, I think, been the result of a lot of self destructive behavior in this industry. A lot of people would rather feel powerful than keep a healthy bottom line. Their prerogative, I suppose. It's good to recognize this and point it out when it happens though, because, for instance, as a shareholder I wouldn't want to be bullshitted about what went down.
I think you should read this:
https://medium.com/incerto/how-to-legally-own-another-person...
By his definition, you think programmers are "too free", no?
I can certainly see how you could interpret my remarks on disrespect as "perceiving it (...) as a threat to one's dominance", but this was certainly not my intention.
My context is of never having had a 'bad' manager, they have always been agreeable and pleasant with a good technical understanding and (I can only assume) high self-esteem.
I think I have used the word respect in two slightly different ways: one when describing employer/employee relationship and one where describing manager/managed.
When I talk about disrespect in the context of a manager I mean it on more of an interpersonal relationship level, not as a struggle for dominance in some sort of power structure.
> "...As an employee I would see that as weakness, especially if combined with technical incompetence."
Adding the bit about "technical incompetence" sound to me like you are projecting certain other attributes on the hypothetical manager that we are discussing. What has been your experience with managers?
> "It's funny, an employer actually asked me that in my first job and I shrugged my shoulders and I said I probably wouldn't notice, which was an answer that clearly infuriated him."
When you have few bills to pay and/or other obligations then this attitude is fine, but I think for a large group of people (e.g. with families to support) this would be a real problem.
The point I was trying to make in the paragraph about "programmers acting any way they like" was that this may be an accept/successful strategy in the short term, but it may not be optimal long term. However indispensable you are now there is someone somewhere out there looking to optimize your job or make your skill set irrelevant. It's certainly possible that you are the exception and that no one will be able to do this to you, but I don't think that it applies to the majority of people reading this thread (I know it doesn't apply to me).
It seems like you view the employer/employee relationship in a very adversarial way, rather than an optimal way for both parties to get something they want. I have had jobs in the past (mainly part time service worker type jobs) where I feel that this attitude is valid. However, most companies I have worked for as a programmer have been small/medium level and started/funded by the same people (no VC money, no faceless career CEO or public shareholders). In these situations I have found that there is no calculated malice or attempt to 'enslave' you, just a few motivated people putting their own money and future on the line to try and make something of value and better themselves.
> "By his definition, you think programmers are "too free", no?"
No, I think a lot of programmers think that they are "too free", but are in-fact only "short term too free"
Except the manager/employee relationship is fundamentally about dominance in a power structure so I don't see how you can separate the two.
Think about it this way: absent any kind of inconvenience (like an interrupted meeting), would a manager ever apologize to an employee for coming in at 9:05am?
If the answer is yes, this may be about mutual respect. Since the answer is no, this is intrinsically about respecting the chain of command.
>Adding the bit about "technical incompetence" sound to me like you are projecting certain other attributes on the hypothetical manager that we are discussing. What has been your experience with managers?
Yes, I am. Because, in my experience, there has always been a strong correlation between one attribute and the other. As in, mild technical competence usually means that they care, but not hugely and deep technical incompetence means they end up caring a ton.
>When you have few bills to pay and/or other obligations then this attitude is fine
I'm aware others can not afford this attitude because they are up against the wall with credit card debt, mortgages and kids and whatnot but as far as I see it the point you and my previous boss were making was a rhetorical one. Point being that it doesn't work as a rhetorical question because I really didn't mind.
I think there may have been some sort of implied threat there - i.e. "you fulfill your end of the bargain by coming in before 9:05am and I'll fulfill mine by not paying you a day late". And I was like, ok, pay me a day late then.
>The point I was trying to make in the paragraph about "programmers acting any way they like" was that this may be an accept/successful strategy in the short term, but it may not be optimal long term. However indispensable you are now there is someone somewhere out there looking to optimize your job or make your skill set irrelevant.
Ok, so now you've branched on to a different topic. I agree that this is the case, but they will keep trying to do that however servile you act and behaving like a slave isn't going to stop it from happening. While they are trying to optimize your job and make your skill set irrelevant, you should instead be trying to optimize your performance and make your skill set more and more relevant while maintaining a healthy savings buffer that protects against unemployment.
As far as I can tell the biggest threats are actually directed at those with the least relative power.
>It seems like you view the employer/employee relationship in a very adversarial way
Yes. The largest military uprising in the United States since the civil war (battle of blair mountain) was fundamentally an employee/employer conflict. The relationship is a naturally adversarial and naturally parasitic. That doesn't mean it has to be all about that in every instance, but that is still its natural tendency.
>I have had jobs in the past (mainly part time service worker type jobs) where I feel that this attitude is valid. However, most companies I have worked for as a programmer have been small/medium level and started/funded by the same people (no VC money, no faceless career CEO or public shareholders). In these situations I have found that there is no calculated malice or attempt to 'enslave' you
I think that is in and of itself an artefact of the difference in power disparity. As a programmer you had more power so they didn't feel like they could fuck with you with impunity. As a part time service worker they could so they did.
I think some of those nice people you worked with might have changed their tune had they seen your relative power slipping. I have definitely seen this happen.
Now that I'm in my late 30s... I'm finding I have more self-confidence than I've ever had in my life. Couple that with a general sense of professional ennui that's been steadily building over the last few years, and you get someone who just doesn't care if you fire him and acts accordingly.
https://hbr.org/1998/03/the-set-up-to-fail-syndrome
https://sites.insead.edu/facultyresearch/research/doc.cfm?di...
Previous discussion: https://news.ycombinator.com/item?id=8166701
I knew after those incidents that there was no point in continuing. It would be foolish to trust someone in any larger way who would casually treat a new employee in that fashion.
That may seem disloyal to those good managers, but I never left on a whim. It was always an agonizing process. But it was also always necessary. My former managers have never held it against me, and I now have connections with a number of great managers who would hire me without question if I was ever looking again (and they know I would work for them in a heartbeat).
What always happened was that it became evident that my interests and my company's interest had diverged, whether it was a lack of opportunity for advancement, the company was going under, the product was a non-starter, or upper-management was bent on self-sabotage.
EDIT: Added missing words
My direct supervisor was great. He was a good manager on most levels.
I left because the company had no future, they weren't going bankrupt, but they weren't growing either. I never got a pay rise, probably never would. My benefits actually shrunk as time went on, staff social functions were cut (e.g. team lunches), use of networking funds became more restricted, and my work environment became less flexible.
In fact, the only reason I considered staying was my manager and coworkers.
People leave poor working environments, whether it's a company or a manager causing that poor environment.
Me personally almost always looked outside due to availability of better opportunities. The argument that people leave managers makes sense only if you are in the best possible job/company you can get with your skill set (which is a very small %) and you somehow got a rift with the manager big enough to leave.
But it could be different in other domains/industries where people stick with the same company till their retirement..
1. In a going concern, which has found traction, a manager is often the _reason_ for people to leave the company.
2. In a company that is not finding traction, or the larger view of its direction is obfuscated, managers are the reason people _stay_ back to work.
This manager being the end-all of association comes from military knowledge that you fight because of allegiance to your battalion, cause and the country - in that order.
In an knowledge enterprise, these constructs exist, but with almost equal weightage.
The best manager cannot make an employee stay back if the company is not going anywhere, or if the cause is not evident.
The worst manager will lose employees even if the company is going bonkers.
If you're a manager in a high traction company and you're losing employees regularly, you should seriously consider finding another career.
You can't really have a team of 300, sounds more like a management speak version of team.
Of course only the poster knows for sure their intended meaning.
Much better and healthy org than any other I ever worked for. Especially over-layered corporations, ie banks are pretty horrible place to be. This breeds all kinds of politics, managers play their games to look good to upper management without any good work being done etc.
But if this would be some classic department where line+project management blends into 1 hierarchy, this would be too much. Smaller teams, max +-10 people most efficient.
This article feels like one of these things where someone's trying to fit something messy and human into a simple, clean narrative.
On the other hand, I got tired of technical problems, because the real problems always seemed to be managerial where I worked.
But at the end of the day, if it's the people that make up a business, then I'd question if they are not the same thing.
I asked a new acquaintance of mine about something bothering me.
I asked him, "so, how often do you fire people? How do find the right people for your businesses?"
"I hardly ever have to fire anyone," he said. "I ask them questions, and they leave."
Damn.
And the thing is, this pressure isn't faked or manufactured. This isn't anyone trying to fire someone. This is just someone needing work done, and answers.
No business wants anyone incompetent, yet, it happens, because of interviewees lying through their teeth and not knowing any better.
So they walk in and fail to do the exact job they won for themselves, then come the questions.
Now they lose their place and have to leave, knowing they got the job by accident.
There is plenty of real pressure to go around in a real business, and we avoid managerial roles because we know the stakes are higher. We know that having a manager is "safer" than being one, because having a manager is having someone responsible for you, and for your well being. It's how America figured out how to hire from the abundant talent pool of those who can't handle tough responsibilities and stay happy on their own, and those who'd rather have it easier. It's the luxury of being managed.
But above that, it gets even worse. Fewer luxuries, just higher pay. Just think of all the bullets the CEO has to catch with their teeth every day. And wen they fail, it's news.
Talking about a CEO catching bullets in their teeth is ridiculously inflated language. Why use such imagery? Because the mission of a typical company does not sufficiently compensate for the guilt produced by putting the organization ahead of individuals.
- Company, because without it there's no employees - The team you're managing, because teams are more than just a single person - The individuals in the team, since they're the one's that can make a team better
It seriously sucks to have to think of things in that order sometimes. I've never been involved in firing a person I didn't like.
Though, when it comes down to it it's not fair for the team to suffer because of an individual, no matter how much they are liked, and it's not fair for all of the teams to suffer because one of them can't cut it.
That's not to say there's no wiggle room though. I'll fight tooth and nail for an employee or team if I think it's a management fault that they've not performed (especially if I'm the manager screwing up) and will try to take a long term view of their value, not just the next quarter.
Of course, all of this could be making me a bad manager. I've been put into managing people by virtue of being technically strong, not being a great people herder. I really do wish companies would spend as much time mentoring and helping managers get better at hands on managing as they do other tasks.
That's not true at all.
Being a manager requires you to balance both the needs of individuals with the needs of the company.
Being a good manager means you can correctly handle when those two needs come into conflict.
My former boss was laid off because he didn't "correctly" handle the conflict we're talking about. I think we're in agreement about what correctly means - being loyal to the company, or people who have power over you, rather than your subordinates.
Putting the organization ahead of individuals isn't what's happening. The individuals ARE the organization.
So if you put yourself ahead of the organization, you're putting everyone else behind you, including your boss. This is a challenge for millennials especially, who are used to always being put first, and having their emotions managed.
A good manager doesn't put themselves before their boss or anyone else. How often do you hear of programmers who enter management to hardly touch code again? A good manager puts the organization first, both above and below their pay grade.
But their performance also depends on the people they manage. If a worker is incompetent, they have every right to be hard on those mistakes. And the worker is fully responsible for setting things right. Work is not homework that gets handed back to you after its graded. It's something needed by someone else that needs it for something important. And nothing is redundant in a tightly run business.
When I think of Melissa Mayers, I think of bullets. Despite whether anyone agrees with "her" moves (which were clearly backed by her counsel), she was doing everything she could to increase market share and rebuild a failing business. She took on all the risk, and becomes target practice for those who despise her failures. When was the last time you were bashed on HN? And she does this so that everyone at Yahoo has a job. She is fighting for YOU.
Regardless of my word choice, to borrow your words, the CEO is a ridiculously inflated position.
People turn you down because of managers, not companies, too.
Interviewed by a precocious child who didn't have interview skills.
I quit my last employer because the manager was an abusive bully with severe trust issues who would constantly threaten, abuse and demoralize people, but HR was also to blame since they did not lift a finger to address the issue even though this manager's behavior was widely known throughout the company for decades.
I've also left a great manager in the past since the business was going nowhere. I've left a good manager and good team because I was very underpaid in another company.
#2. Next the mindset. Typical mindset when you move from technical (or any IC) role to MGMT and the higher you go in MGMT should completely change.... unfortunately its not so easy to give up the control. MGMT is about making others successful... giving up your control to others is very frightening and often causes identity issues... moving from do it all (as an IC) to ask_and_inspire is not easy...
#3. Assuming you overcome these two... typical problem of MGMT/leadership is they try to find, "What's the matter?" where as the focus should always be on "What matters to you (an individual/ICs in team)"
I'm the blog author, Rich Archbold from Intercom. Just to clarify …
I wrote this blog, with the exaggerated / cliched title, to try to speak to the large cohort of over-confident, under-skilled and often lacking-enough-self-awareness, managers out there. I was (and often still am) a member of this cohort. Being a great manager all the time is really hard and almost impossible IMHO.
The goal was to hopefully try and generate some more self-awareness and introspection and thus make life a little fairer, more pleasant, more growth-oriented and hopefully more successful for all concerned.
I wasn't trying to deny or downplay that people also leave their jobs for all of the other reasons highlighted by folks here.
Thanks, Rich.
#1. People get hired for what they are good, their skills and then get promoted (to management) for same technical/IC skills not for the MGMT skills. No MGMT ramp-up. No MGMT tools. No MGMT framework. You are now tasked to lead a team. it's surely will fail.
#2. Next the mindset. Typical mindset when you move from technical (or any IC) role to MGMT and the higher you go in MGMT should completely change.... unfortunately its not so easy to give up the control. MGMT is about making others successful... giving up your control to others is very frightening and often causes identity issues... moving from do it all (as an IC) to ask_and_inspire is not easy...
#3. Assuming you overcome these two... typical problem of MGMT/leadership is they try to find, "What's the matter?" where as the focus should always be on "What matters to you (an individual/ICs in team)"
I enjoyed the article and IMHO it did well in encouraging self-awareness and introspection. I hope it goes far.
I could be managed by the best manager in the world, but if I'm paid 20% below market rate I'm going to leave for a better paid job.